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.
Whenever I have the opportunity, I prefer to start a documentation project
from the Business or Functional specs phase. The following explains my
view of the effects of documentation, when started in different phases:
Functional Specifications phase- documentation can clarify procedures and
pollicies, identify unreliable elements and increase chances for user
satisfaction.
Product Design/Coding phase - documentation can expose bugs and errors,
suggest more efficient design, get designers to make early decisions.
Distribution and Use phase - documentor is more or less stuck with the
system. Documentation can help users adapt and accept, warn against bugs
and disclaim liability.
When I was contracting, this was the rationale presented to clients in my
original proposal. In my current job (new tech writing position) I
presented this rationale to my company, and we have developed a process for
including documentation on the project team at the very beginning, with
efforts starting at the Functional Specs phase. A bit tricky the first
time a tech writer starts here, but oh so much opportunity to document it
right, and to influence the development of the system.
Just my opinion.
Suzette Seveny
Markham, Ontario, Canada
sseveny -at- petvalu -dot- com or suzette -at- yesic -dot- com
