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: Software documentation on the critical path From:Marilynne Smith <marilyns -at- qualcomm -dot- com> To:Pierre Roberge <proberge -at- famictech -dot- com>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 19 Oct 1999 12:38:47 -0700
You're in a pretty common predictament. It seems logical to those who make up
the schedules that the documentation should be done at the same time as the
software release. It is also probably clear to you that this is not a
reasonable expectation. If you have never used the software, how can you write
a good document? A few ideas:
-Get your documentation put through QA at the same time as the software
- This will help you make your point that now the software is working, you need
time to find errors and finish your book.
Most of us have been there. Many of us have had to put out documentation that
is incomplete or incorrect. Most of us hate that.
You need to work to bring your management to reality. Tell them what you can
give them at their named due date, what resources you used to get there, how
much better your documentation will be if they let you finish up, and how much
better their customers will like the product with good documentation.
Good luck.
Marilynne
At 08:12 AM 10/19/99 , Pierre Roberge wrote:
>Hi everybody
><snip>
I just came out of a metting where I
>have been told that I am on the critical path for our release date of Dec.
>5th, 1999. This is no news to me, how can I document something that is not
>finished? I will complete my docs and helps at the same time the software
>comes out of QA. Can I do better than that?
<snip>
>All answers are appreciated
>
>Thanks
>
>Pierre Roberge
>Famic Technologies 2000 (soon obsolete)
>Montreal
>