Content complete: how much time before you ship?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Pam Mandel now has <<... tentative dates for our documentation schedule. The
docs schedule is now linked in to
the engineering schedule, and voila, we're scheduled.>>

Congratulations! That's better than most startups (and many more mature
companies) ever achieve.

<<I'm striving for a content complete date - when we're all done writing,
except to fix bugs. Currently the overall schedule shows us as content
complete one week before we burn the product to disk.  We've got about a
month between the code freeze and the docs freeze.>>

Without knowing how large the product is, it's hard to say whether this is
really adequate. On the assumption it's a relatively small product, with
matching docs: The 1 week part strikes me as cutting it too close, unless
the "burn" date is somewhat flexible; always plan to leave flexibility in
case of disasters, major or minor. But 1 month should be ample time to
complete and test your documentation, particularly if you plan the test
ahead of time. Among other things, some code will freeze long before other
code, and you can finish writing and testing the docs for that code while
the developers continue to tweak the rest of the product.

<<I'd like to mitigate where possible. I don't want my team to hate me when
this is over. >>

Teach them to hate the developers, and Bob's your uncle: "the enemy of my
enemy is my friend!" <g> Seriously, though, it sounds like you've already
got an excellent working relationship with the development team, and now
what you need to do is find a way to solidify and fine-tune that
relationship. Recognizing that some code will be done earlier than other
code, you can work with the developers to figure out how to document and
test that code first, leaving the unstable stuff for later. By the end of
the process, there'll be much less testing to do.

As this relationship grows and strengthens, you can take more time to
improve on it; for example, you may eventually be able to freeze the
interface early in the development process, with the developers working on
the plumbing. That's particularly true since you have a "test" phase built
into the documentation cycle (yay!), and may eventually be able to combine
this with usability testing of the interface and docs; once the users
approve your interface, the coders can design to that target rather than
shooting in the dark. You mostly document the interface, not the plumbing,
so this buys you considerable extra time to do your work. Don't forget to
start tracking time and "bugs" in your process. I'm not a strong believer in
overreliance on metrics, but if you get an idea of how fast your people are
at doing certain things, you can plan for the release of the next version
with much more confidence.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Take XML and Tech Writing courses online!  Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off!  http://www.online-learning.com/index.html.
---
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.