As a writer, before you embark on your documentation project, create a proper plan and get it approved by key stake holders. This will establish your credibility in the event of any crisis. It is important for you to study the marketing/customer requirements document. Ideally the requirements document should state clearly the type of document needed by customers (e.g. Online Help, User Manual), features that need to be documented, and the depth of information be included in the documentation.
The next step should be to study the functional specification.
On the basis of MRD and functional specs, the documentation plan should include the following details:
- Product name, scope, and purpose
- Milestone dates
- List of documents that will be created and/or updated. If the project is about updating an existing product, list the features to be documented. If the project is about releasing a new product, additional planning is required. There can be multiple deliverable types needed, ranging from a single-paged addendum to a context-sensitive online help system.
- Features that will be documented
- Work estimate and committed schedule for documenting each feature or completing each document
- Committed documentation milestones
- Documentation Reviewers including review schedule. There are 2 ways to conduct a review, collect edits individually from each reviewer or hold a review meeting to review everyone’s comments. Multiple reviews may be required. You can also use Adobe’s Shared review process to collect feedback from multiple reviewers.
- Depending on the program, include any training material needed for the Launch.
- Risks, assumptions, and dependencies. Include the following: Main risks of the documentation project (e.g. last minute feature additions), probability of each risk, Impact of each risk, Risk mitigation plan, Owner of the mitigation plan)
- Doc approval process and approvers
- Documentation delivery and distribution plan.
Here are the components of a Documentation Plan:
- COVER PAGE summarizing the name of the project; organization, and copyright or confidentiality statements.
- Table of Contents – Proposed chapters and their tentative content.
- Introduction that covers: Purpose and Scope of the plan.
- HISTORY (or REVISION LOG) showing the revisions the plan went through, with dates, the names and titles of the persons who wrote different versions.
- RISK FACTORS. What are the dependencies to complete the documentation? Which critical factors may bring this project to a halt? What is the impact (H/M/L) and the probability (H/M/L)? What measures should be taken for such an eventuality and who are the mitigation owners.
- Reviewers and Review Process displays the names, titles, and contact information of the writer and all stakeholders involved with the documentation project.
- Product features: what are the features that will be documented.
- DOCUMENT SPECS. Is this going to be an online document, a printed document, or both? Will it be single sourced? If printed, will the project be using client template or the company’s one?
- Schedule What are the milestones in the development of the document? What effort is required? When should the review cycle(s) be finished? How many rounds of reviews should be allowed? What is the start/end date for the whole project?
A documentation Plan lays down a blueprint for the whole project. Just like architects should prepare a blueprint before building/house construction, writers should not start the project without creating a proper blueprint in the form of “Documentation Plan.” Kick start every technical writing project with a well-crafted and approved plan.
Email info@ThomasEcafe.com for a documentation plan template.