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.
I too, have seen this at several clients. In one case, the developers don't
carefully review the manual and when it gets to QA, they edit not only for
accuracy but also for what they like to read. And refuse to sign off until
we used the words that QA liked. And I have been told that I will use the
words they want, my job is to check for grammar and spelling. (!)
Same client, different project, I would up in 2x weekly review of a manual
with the QA person and the lead programmer who started writing the manual. I
wound up typing the words they wanted. For 6 months - the doc was 150
pages - they wrote and then rewrote the manual. Major revisions each time,
reorgs, etc. It was amazing. And since there are no project managers, it
went on and on. And this was after everyone signed off on an outline and
project plan that specified 2 reviews.
I have also worked where the situation was so very different, it was like
night and day. Project plan, doc plans, review schedules and a too bad you
didn't find that earlier attitude. Programmers were fired in part because
they were not good about reviewing their parts of the manuals. The writers
opinions were sought out about the interface and our opinions were taken
seriously. If it was really hard to document, it was probably poorly
designed. What can we do about that? How can we redesign it to make it work
better?
The difference is fundamentally the value the company places on the
documentation. If the company values the abilities of the tech pubs people,
the process will occur in a rational and planned manner with the same level
of professional reviews that the software gets, even in a rapid application
development process. If the company values the docs, they will force
everyone involved to value the docs and hold to project plans and review
cycles. If the company thinks of the tech pubs people as overpaid typists,
the process is insane. Planning is for nothing, reviews are haphazard, and
the tech pubs people are publicly blamed for any delays in the release
cycle.
sharon
Sharon Burton
Anthrobytes Consulting
Home of RoboNEWS(tm), the award-winning unofficial RoboHELP Newsletter
www.anthrobytes.com
anthrobytes -at- anthrobytes -dot- com
Check out www.winhelp.net!
-----Original Message-----
From: Hutchings, Christa <cwhutchings -at- HOMEWIRELESS -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Thursday, 30 July, 1998 7:52 AM
Subject: Re: Concurrent writing and revision
>Tom Campbell wrote:
>
>>Unfortunately, in the company where I tried to make all this work, we
>had =
>>a very political environment. Some users would whine to their division
>=
>>vice president, who would whine to my division vice president, who then
>=
>>sheepishly cajole my boss into making me put other jobs on the back
>burner =
>>to get the whiner's ninth revision done. Of course, I took all the
>heat =
>>for any ensuing problems. =20
>
>And, again unfortunately, this is the way it seems to work at most
>companies. No matter how hard Tech Pubs puts its foot down about
>revisions, schedules, etc., it seems that the squeaky wheel gets the
>oil. There is always someone with more clout than the last guy who
>demands that his/her project be given higher priority or special
>handling, and if Tech Pubs tries to enforce its rules, it is accused of
>"not being a team player."
>
>And like Tom says, if Tech Comm misses a deadline or the quality suffers
>on a project that got bumped by one with a higher priority, or because
>the SMEs couldn't get their stuff in on time, Tech Comm is accused of
>incompetence. I've seen heads roll in Tech Comm groups because of this.
>It's not a fun situation, for either managers or writers.
>
>My guess is that this will probably continue to be a problem at many
>companies until we start seeing more senior managers who have *direct*
>experience managing tech pubs efforts (and I don't mean merely managing
>a tech pubs group, but actual "hands-on" tech pubs project management).
>I'm not holding my breath waiting for this to happen...
>
>
>Chris Welch-Hutchings
>Senior Technical Writer
>Home Wireless Networks, Inc.
>mailto:cwhutchings -at- homewireless -dot- com
>
>
>
