Monday

Write a Documentation Plan and Update a Documentation Maintenance Plan

Today I plan the next release of my documentation, which I must have ready when the product is ready. As technical writers in a growing company, we have the opportunity to create new documentation sets for new products, but most of our documentation effort goes into maintaining our thousands of pages of documentation for our existing products. As customer advocates, technical writers respond to customer issues and then improve the documentation on the customer's behalf every release. I always include the following details in my documentation plans:

• The intended audience.
• The new features we'll need to document.
• A list of all documents we'll have to revise or create from scratch.
• The content or subject matter experts who need to review the documents.
• A preliminary schedule that includes the projects for each technical writer working on the release. Only two technical writers are working on this release.
• A list of risks and plans for mitigating those risks. For example, does a deadline fall near a holiday that will make it difficult for us to get reviews from our subject matter experts? Are my subject matter experts located here in Austin or at one of our international development centers? Both of these issues can add time to our schedule.

For new documentation sets, I also research the intended audience, including existing knowledge, expectations based on similar products, and user scenarios. This information helps me understand the areas of the product to document the most thoroughly and how best to present the content.

For existing documentation sets like the one I'm planning today, I also include a list of the new features we need to document and my plans for improving the documentation set overall. Improvements include fixing bugs that customers have reported since our last release and evaluating top support issues to determine whether we need to revise content to clarify an existing concept or procedure. I think we'll do a lot of editing this release to address bugs. We'll also spend some time writing content for the new features we're adding to the product.

For the preliminary schedule, I also identify important synchronization dates, such as shipping beta* documentation, sending all documents to review and signoff in Document Production, and finalizing all content before our Localization department starts translating. I will meet with the managers in Document Production and Localization to make sure we agree on important milestones.

The Document Production group verifies that we use the most recent templates so all NI documents look the same inside and out. They also double-check our formatting and create or edit difficult pieces of art for technical writers.

The Localization group is made up of translators from around the world who translate the English software and documentation into their native languages. We have translators from France, Germany, Japan, China, and Korea.

After completing the documentation plan, I ask the technical writers involved in the project, the project manager, and the content experts to review the documentation plan and provide feedback to make sure we understand and agree on the work involved in completing the project.

* Software and hardware products have two important development milestones: alpha and beta. Alpha marks the date that the product contains all of the features and is ready for testing and bug fixing. Usually, testing is done internally during alpha. When the team is confident that the product operates as they intended, they often ask customers outside of the company to test the product and report feedback. Technical writers sometimes prepare special documents for beta periods to explain the new features and how to access them.