Re: Managing Expectations

[Beth Agnew <bagnew -at- INSYSTEMS -dot- COM>]

I think managing expectations is a vital part of the technical
communicator's job, and can be of greater or lesser importance depending
upon the project.

Trying to meet or realistically address expectations can be tricky. Here's
an example. I've done quite a bit of multimedia development. When the
industry was new, a little sound, some animation and the occasional video
were enough to blow the socks off of a client. For people used to seeing
static screens, any movement gave a presentation a Wow! factor that was
very useful. However, once people began to realize that computers could do
multimedia, the expectations changed, and people expected to see the same
quality of sound, movement and resolution that they were accustomed to
seeing on televisions. Inevitably, they were disappointed. When we were
finally able to render 3D images, make polygons look like something, and
add lighting effects, crude as all this was a few years ago, those of us in
development were thrilled at what we could accomplish, but the customers
saw
cheesy figures, jerky movements, and odd textures. They didn't care that it
took 20 hours to render a figure -- it didn't look like
"real" claymation.

Now, the bar has been raised that much higher as far as expectations in the
multimedia or 3D graphics world. Showing a client Jurassic Park or Reboot
quality of images gets a "Yeah, we've seen that. What else can you do?".
That's what makes it such a challenge.

If you have a client whose expectations are too low for the project, they
will continually complain, or at least wonder, why they need a professional
in the first place, why it costs so much to have it printed when there's a
perfectly good photocopier down the hall, why they have to invest in a
high-end DTP tool, and so on. You're continually justifying yourself until
you can re-educate the client about quality, and raise those expectations.

As Eric said, it's a fine line that we have to walk sometimes. I try to
explain to clients that even though they have statistics that say customers
don't read documentation, they still need the documentation. They still
need quality web sites, and effective on-line help. I draw the parallel for
them that was evident to me during my stint as a journalist -- it's the
iceberg analogy. What you see is only the 10% or so above the waterline,
but the 90% you don't see, or that the customer doesn't use, still has to
be there for the thing to float. If you skimp on it, just as skimping on
research for a story made for a very thin story, the product won't be as
successful.

There's no one better to help manage expectations that technical writers
who have the responsibility of producing quality communications.
Communication is what we're all about.
--Beth

Beth Agnew
Senior Technical Writer, InSystems Technologies Inc.
65 Allstate Parkway, Suite 100  Tel: (905) 513-1400 ext. 280
Markham, Ontario, Canada L3R 9X1        Fax: (905) 513-1419
mailto:bagnew -at- insystems -dot- com    Visit us at: http://www.insystems.com

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html