Re: Technical writing in the development process? (take II)

Subject: Re: Technical writing in the development process? (take II)
From: Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>
Date: Sun, 25 Jun 2006 16:53:01 -0400

Another key function of the doc plan is the signoff. State in your doc plan that you will interview SMEs for X hours, work with the product for user testing, review QA's database of bugs, or list any task involving other people, or items they must provide (such as a product prototype or build). Then when the managers responsible for those resources sign off on the doc plan as approving it, they are committing to providing you with those resources. I make it explicit in the doc plan by including a paragraph to that effect. I hold a review meeting for the doc plan, and make it crystal clear that once they approve my plan, I will stick to it and deliver as promised -- as long as I get the resources that I have asked for, and that have been agreed to by their approving the plan.

This does two valuable things: It puts management on the alert that those resources will have to be allocated to your project, and it shows that you cannot be held responsible for their failure to do so. Obviously, in execution you would do everything you could to complete with or without the requested resources, but having formalized it all in a doc plan can really save you when all that dreck starts to roll downhill.

Geoff Hart wrote:

Melissa Nelson: <<I have been adviced by another techwhirler to come up with a doc plan for each new project, which I think will help let everyone involved know when I need to be involved.>>

Good plan. Just don't forget to put in the good word about "design thrice, program once". There's lots of good stuff out there (most recently and most notably by Alan Cooper, a respected programmer) about how and why this works. Check out "The Inmates are Running the Asylum" for details. And spread the message that feature creep is bad for business because it prevents you from selling those features as an upgrade.

... You need to have the right to ask questions and receive answers, not just take what is handed to you.
Beth Agnew
Catch the Buzz:
STC Presentation archived at:

Professor, Technical Communication
Seneca College of Applied Arts & Technology
Toronto, ON 416.491.5050 x3133


WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content delivery. Try it today!.
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.


RE: Technical writing in the development process?: From: Melissa Nelson
Technical writing in the development process? (take II): From: Geoff Hart

Previous by Author: Re: Fwd: gaining control of a dysfunctional environment?
Next by Author: Re: Technical writing in the development process? (take II)
Previous by Thread: Technical writing in the development process? (take II)
Next by Thread: Re: Technical writing in the development process? (take II)

What this post helpful? Share it with friends and colleagues:

Sponsored Ads