How to Write a Documentation Plan
Documentation Plan is one of the key documents in technical writing.
When starting off a technical communication project, either as a freelancer or a payroll employee, you’d better start with a Documentation Plan to avoid any unnecessary complications and headaches down the road.
Here are the ideal stages of any documentation project:
1. Write the Documentation Plan (DP) and submit it to the (internal or external) client.
2. Get a feedback on DP.
3. Correct, edit, and submit a second draft of DP to the client.
4. Get written approval on DP.
5. Start the documentation project.
6. Correct and edit the DP if necessary, as the project rolls along. But each time you change the DP again get written approval of the client.
7. Finish the project as foreseen in the DP.
CAUTION: Since these are “ideal” stages, it’s rare for any documentation project to go through all these steps literally.
For example, in some case the approval would be oral and not written.
Or sometimes the project starts with a bang and DP comes later, in attempt to formalize the “facts on the ground,” so to speak.
It’s a dynamic process, open to all kinds of adjustments, depending on the context.
But at least as a technical writer you should always bring up the issue, insist on a written DP in order to protect yourself from post-facto potential complaints that you did not deliver what the client wanted.
Here are the components of an ideal Documentation Plan (DP):
COVER PAGE summarizing the name of the project; project (or part) number (if any); the name of the author and the organization; date of the project; any copyright or confidentiality statements.
HISTORY (or REVISION LOG) showing the revisions the DP went through, with dates, the names and titles of the persons who wrote different versions as well as those who approved it.
CONTACT INFORMATION displays the names, titles, and contact information of the principal technical writer and all stakeholders and managers involved with the documentation project.
SUMMARY of the project. What’s the system, product or the service that the proposed document is aiming to explain and document?
AUDIENCE that the document is intending to target.
PROPOSED TOC (Table of Contents). What are the proposed chapters and what would be their tentative content?
DOCUMENT SPECS. Is this going to be an online document, a printed document, or both? Will it be single sourced? If printed, what would be page dimensions? Would there be any special considerations regarding fonts, logos, color palette, images, media content?
STAFF. Will there be only one or more writers working on this document? If multiple writers, are they from the same office or do they work in different cities, states, or countries/continents? Who will review this document? How will the writing and review cycles be coordinated? What kind of regular and/or unscheduled meetings would be necessary?
TIME TABLE. What are the milestones in the development of the document? Which chapters need to be completed when? When should the review cycle(s) be finished? How many rounds of reviews should be allowed? What is the calendar and deadline for the whole project?
RISK FACTORS. What are the bottlenecks to this project? Which critical factors may bring this project to a halt? What measures should be taken for such an eventuality? Is there a backup plan to keep the project going even when such risks emerge?
As you can see a Documentation Plan is a comprehensive document that lays down a blueprint for the whole project. Just like an architect would not start building a house without such a blueprint, you also should not start working on a technical communication project without a similar blueprint of your own that we call a “Documentation Plan.”
Good luck in your efforts to do everything the right way and start every technical writing project with a well-crafted and client-approved DP.
