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:Software documentation on the critical path From:"MacLemale, Laura A." <Laura -dot- A -dot- MacLemale -at- bender -dot- com> To:"'techwr-l -at- lists -dot- raycomm -dot- com'" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 20 Oct 1999 15:30:20 -0400
Bonjour Pierre,
I just read your post on the 10/19 Techwr-L digest. Though I am fairly new
to the field of tech writing, I don't believe that your situation is too
uncommon. Due to the nature of software design in general, the possibility
for late changes (and potential bug fixes) always exists for us writers.
I agree with the others' advice to take a proactive approach to getting this
documentation completed. Currently, I am creating a user guide for an
internal application for our company. I haven't even used the actual
application as it is not fully coded at this point. Instead, I've been
working from the previous user guide and the specs. Not all sections of the
previous user guide are relevant to the new version, and the specs are not
updated constantly. However, I've kept the lines of communication open with
the developer by reviewing every detail of my new guide with the specs and
sending him questions with specific references. In turn, he provides me
with needed screen shots and meets with me periodically to discuss any
changes in the interface or functionality. (Luckily, I am working with a
personable programmer who is responsive to my approach, even though he is in
a crunch himself to finish the coding.)
To summarize, I have found that this approach is helpful in dealing with the
lack of tangible information for a documentation project, as well as for
remaining in synch with the ever-sliding deadline.
Also, I agree with the other posters that you might want to approach a QA
person (or two) and see if they will test your existing documentation and
help file. It is never too early to solicit feedback, and it may even help
to ease the pressure at the very end.
Best of luck with your project,
Laura A. MacLemale
Technical Communications and Training Specialist
Matthew Bender
1275 Broadway
Albany, NY 12204
Laura -dot- A -dot- MacLemale -at- bender -dot- com
