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: the document development process From:Bonni Graham <bonnig -at- IX -dot- NETCOM -dot- COM> Date:Wed, 27 Dec 1995 10:21:00 -0800
Tammy Hale asks:
>But before we get started discussing how to improve the process, I would be
>interested in hearing what the document development consists of for other
For me as an independent, it varies greatly by customer, or at least it HAS.
Lately I've become tired of my clients' lack of organization causing me to
produce documentation with which I am not satisfied, let alone happy.
So I picked up a copy of Joann Hackos' Managing Your Documentation Projects and
am beginning to implement her suggestions. Based on the suggestions and
templates in the book I have instituted a number of practices (independent of
the client manages their end of the project):
o We create at least one Project Notebook for each and every project. It
o a copy of the Information Plan (per Managing...)
o a copy of the contract
o if the contract does not contain them, a list of contact names, phone
numbers, and email addresses
o a printed set of screen shots, each with a header indicating the date taken
and the date of the executable. This gets updated as the screen change. I
also try to note how many times the screen has changed.
o an outline of the proposed doc set (my sketchier version of Joann Hackos'
Content Specification; we're still just beginning to use and understand the
o a milestone project plan showing deliverable dates
o (when the project is over) a copy of the Postmortem Project Review Minutes
o We create a plan to approach the doc set and always talk about any significant
changes to the plan.
o We follow the plan we create.
o We specify and deliver at least two review versions to the client, complete
with return deadlines and a checklist of items to review for. The client is
always free to add to the checklist, but they need to sign the list before
returning the review copy to us.
NOTE: I have one client where I'm supplementing an existing documentation
department (as opposed to BEING their doc department). I don't enforce the
checklist with them, because so far it has been unnecessary. I get quality
feedback without having to sit on them).
o We create a milestone project plan (currently using Microsoft Project).
o We track things like estimates and how close we are to them and our actual
hours per topic or page in a Microsoft Access database for future use.
So far client approval of this has been high. We always know if and why we're
going to be late (which is much rarer, so far). We always know exactly what's
coming up and what we're supposed to be doing.
I'd be interested in seeing how this matches up to other people's processes,
since one of our goals in continual process improvement.
bonnig -at- ix -dot- netcom -dot- com