Latest posts by techwriter (see all)
- BOOK REVIEW: “Design for How People Learn” by Julie Dirksen - July 10, 2017
- 12 Top Characteristics of a Good Technical Writer - July 3, 2017
- What Are the Qualities of a Good Technical Writer? - June 28, 2017
Most technical writers, especially in the high-tech sector, work as a part of a project team. When the product is already finished and the technical writer is called in to provide the documentation after the fact, this may not be the case. But for those products that are still in development, a technical writer should try to become as much a part of the overall team as possible and participate in the project team meetings.
Sometimes these meetings will take place physically, in a meeting room and with all participants present; and sometimes over the Internet, either in the form of a tele-conference or a webinar. In either case, there are many benefits of your participation in such meetings both for you as a writer and also for the team as a whole.
For example, it is crucial for you to understand where the project is in terms of its development status. This will help you pace and schedule your work and include a meaningful document completion timetable into your Documentation Plan.
A high-tech product project usually starts with “scoping” the project, and with the articulation of a “vision” and a “mission.” This will be supported by input from the marketing department through a Marketing Requirements Document (MRD).
After deciding on the “architecture” of the product, i.e., how its major system components would be related to one another, comes the functional specs. Once a consensus is reached on such specs the production phase (physical component production, or coding, or a combination thereof) begins.
Your documentation input may start at this production stage (if not earlier) by getting hold of the mock-up production model and start writing an installation manual (for example) on the basis of available specs. Or you may have to wait until the testing stage when the product is put through its paces before it is released to the market. The specific type of documentation you’ll end of writing (user manual, system admin manual, quick reference guide, etc.) will totally depend on the preference of the project management.
The last stage, market release, may require you to write release notes and other required documentation that is delivered to the customers along with the product itself.
The specific form of your contribution will all depend on the project management’s decision on when the documentation comes into the picture. But in any case, it pays to know where you stand in the general time-line and what and when you are expected to contribute your piece to the overall effort.
If you are not initially included in the team meetings it wouldn’t hurt to ask to sit in. The chances are, the project manager will actually be pleased by your willingness to be a more integral part of the team.
The more you become a regular part of your team’s meetings the more the team members will be willing to share their expert information with you and the smoother your documentation process will go. It’s always a win-win situation.