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:Managing Expectations From:"Eric J. Ray" <ejray -at- RAYCOMM -dot- COM> Date:Thu, 9 Oct 1997 10:37:19 -0600
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
Eric J. Ray ejray -at- raycomm -dot- com
TECHWR-L Listowner http://www.raycomm.com/