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.
-----Original Message-----
From: Colin Green [mailto:CGreen -at- illuminet -dot- com]
Sent: Thursday, March 22, 2001 11:52 AM
To: TECHWR-L
Subject: Content Moratorium
Colin Green asked: "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?"
This is a tough question to answer, Colin, especially given that the scope
of these projects was not stated. It sounds to me, though, as if your shop's
approach is the more traditional one of the developers hacking away at the
code for a while, then passing it off to you.
<tangent>I prefer my company's way of thinking; that the marketing, customer
support, and documentation departments are just as important to the overall
project as the developers themselves, and thus should be involved in the
process from the beginning and throughout all phases. The feature isn't
considered finished until each of the members is comfortable that he/she is
truly up to speed. Documentation is developed parallel to, not in response
to, changes in the code. Think about it this way; how many times have your
developers "finished" their work only to find out that what they did was not
even close to what the product line managers envisioned, customer support
can't begin to actually "support" it, and the writers haven't got a clue as
to how to explain it? </tangent>
Anyway, back in the real world most people face, if you have the privilege
of knowing basically what the developers plan to do at the beginning of the
project, through their requirements and such, then you should be able to
estimate how long it will take to create documentation. Your estimates
should be taken into account in the overall development process, with heavy
emphasis in the meetings where the time frame for the project is laid out.
When you craft your estimates, make sure you give yourself ample time for
drafts, peer or team reviews, and rework (one of our writers insists that
you should then double this estimate, but I think he just likes to see how
much free time he can possibly get). The point here being that if the team
has your estimates up front they will be less likely to push you to get the
documentation done sooner than you think you can (its not like they weren't
warned).
Ideally, you should be involved in the planning process from the outset,
even going as far as helping hammer out the requirements, test cases, etc.
(though I know this doesn't really happen in most people's offices). For
example, two of us writer types are currently working on the creation of use
cases, which will in turn be fed into the requirements for the features the
developers will be working on. While the team as a whole is contributing to
the use case preparation, the writers are actually deciding what does and
doesn't go in them and pretty much the direction they are taking. Well,
okay, ultimately the users' needs dictate this, but I sort of get to
interpret what the needs are. Not only will I know what my developers will
be doing for the next project phase, I will actually help shape it. You'd
better bet that my estimates will be pretty darned accurate this time out.
:-)
Before everyone starts throwing exceptions at me and calling me a dreamer,
please refer to the tangent above, and realize that I am working on a shop
where the walls between departments were literally and figuratively torn
down, and that I know I am in an ideal situation. Not everyone has the
luxury of being close enough to his/her developer to be able bean him with a
Nerf ball. My point, I think (kinda lost track), is that the more prepared
you are early on, the less you will have to deal with unrealistic deadlines
at the end.
Charles T. Rich
Technical Writer
Product Development
Follett Software Company
*** 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.
