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: Content Moratorium From:"Jeanne A. E. DeVoto" <jaed -at- jaedworks -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 22 Mar 2001 14:02:34 -0800
At 9:51 AM -0800 3/22/2001, Colin Green wrote:
>Question: Given the flux of software applications in development, and my
>inability to affect that schedule, what is a reasonable demand for a tech
>writer on content moratorium? That is, what can I reasonably demand for
>number of days/weeks that the product be stable in order to compose a final
>draft?
I've found that the key here is to reverse this dynamic. Instead of trying
to set a date for feature or interface freeze (which will likely be ignored
unless you have major buy-in from clueful management, and which will be
resented if it's enforced), or working yourself to a frazzle trying to hit
a constantly moving target, set your own deadlines in terms of product
freezes. Never give a hard date for a documentation milestone. Instead,
give your dates in terms of development milestones.
For example, you might release a documentation schedule that says something
like "The first draft of the documentation is due three weeks after feature
freeze." This ties your schedule directly to the product schedule, in a way
that's difficult to argue with since it's reasonable on its face (you can
hardly be expected to document major features the moment they're added). It
puts everyone involved on notice that the documentation can be expected to
slip by X days if features are added late.
Instead of you being the bad guy, trying to enforce and demand freeze dates
you come up with, you're simply describing the consequences that will ensue
if features or interface changes are added late. In this scenario, it's
management that tells the development team "You can't change that, because
the docs will slip."
And if management doesn't tell the developers that, and the docs slip,
you've given everyone ample notification of how that affects your schedule.
If someone gives you the "We're shocked...SHOCKED...that the documentation
is late!" routine, hand them your published schedule, with the relevant
date of the last feature change or interface change.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at http://www.devahelp.com or info -at- devahelp -dot- com
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
