TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Managing Expectations From:Stephen Forrest <techwriter -at- IBM -dot- NET> Date:Thu, 9 Oct 1997 17:25:05 GMT
With any change, especially change to established procedures, you have to
deal with momentum. Altering momentum requires the application of energy. In
this case that might mean presenting the changes with a certain amount of
hype. In other words, present the new material as highly significant, big
new developments, whether they are or not.
At 10:37 AM 10/9/97 -0600, Eric wrote:
>In light of Doreen's comments about customer expectations,
>an ongoing offline exchange with a subscriber, and our current contract
>gig, I'd like to toss out Managing Expectations as a broad
>topic for discussion.
>
>It seems that we're often so caught up in the minutae of the
>day-to-day getting Winhelp files to compile and avoiding
>Word crashes that we lose sight of some of the larger
>concerns that effectively drive our jobs.
>
>What role do you actively play in managing either customer
>or management expectations for web sites, doc sets, help,
>or whatever? Do you tell management that,
>despite a million dollar investment in documentation,
>many people won't read it and they'll still have to pay
>customer support people to read the documentation on the
>phone. Or, how do you explain to customers that, although
>the new documentation, Web site, and product are pretty
>darn good, nobody will really be 1000% more productive
>than they were with the old stuff.
>
>For example, a couple of years ago I worked on a documentation
>and training project with user expectations as the primary
>focus. The project (part of a larger one), designed and implemented
>unilaterally by the IS group for use by the Customer Service personnel,
>was technically not difficult to use, but required a complete
>change in workflow for the CS people. The only payoff was a
>hypothetically easier (but unfamilar) process in a couple of
>years, after the bigger project was to be complete.
>Toeing the line between brutal honesty, supporting our
>department, and commiserating with the poor people who
>had to deal with this was quite a technical communications
>challenge.
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
