Do Technical Writing projects need a Documentation Plan?

Gordon McLean asks: Do you plan to review your plan?

This is in relation to the Documentation Plan (aka Information Development Plan) that most technical writers prepare in advance of starting a major project. Granted, on smaller projects you can get away with this if you know the product, have the resources and the deliverables are nailed down.

But, his point is that the plan itself should be reviewed/updated during the project lifecycle. Or, at least, that’s how I read it.

Why create a Documentation Plan?

Gordon outlines some valid reasons:

1. Planning drives a discussion about the content, audience and deliverables.
2. Not reviewing your progress to the plan throughout is a waste, but I guess you could get away with it.
3. Planning can provide more than just a set of deadlines.
4. Set the direction and make sure everyone knows what they need to do to get there.
5. Drive discussion around the deliverables and the audience of the information.
6. Revisiting your plan throughout the project will help keep you from losing sight of the woods for all those trees.

I have a slightly different take on this.

Hope I’m not splitting hairs here but, once the plan is published, I use it in the same way I use my Project Plans. For example, I send out status reports to the project stakeholders and flag issues as they arise.

But, I don’t review the plan once it has been signed off.

I would only do this if the deliverables changed. And, at that point, re-issue an updated Documentation Plan, asking for sign-offs etc.

Likewise, if someone left the team, it would be updated and circulated to the team, highlighting where this may impact the schedule and/or other risks.

I started to use Documentation Plans (in a more intentional way) when working in the US, partly as the PM demanded more visibility on deliverables and budgets.

At first, it was a pain. But, once I saw the value, it made sense and we (the technical writer team) scheduled meetings twice a week. It was project within a project, so to speak. They gave me their status reports, I collated them, and then passed it to the PM.

How to use a Documentation Plan

Klariti has some tips on using a documentation plan / information development plan:

1. Assign an individual for every data repository. Identify roles and responsibilities.
2. Create procedures for creating, updating and revising documents.
3. Create a Master Document Plan List. Capture each technical document your team writes, updates and archives.
4. Identify the software requirements for the project success; this includes specialized authoring software for creating online help or content for mobile devices.
5. Identify security issues such as access to building, swipe cards, access to secure data resources, and travel requirements for international projects.
6. Create procedures for identifying and removing invalid and/or obsolete documents; define procedures for transferring archived documents to storage facilities. 10 Things Your Documentation Plan Should Know
7. Establish procedures for reviewing and approving documents prior to issue.
8. Identify and retain documents for legal and/or contractual purposes, for example, to comply with Sarbanes Oxley requirements.
9. Maintains master documents in a secure environment.
10. Establish the writer’s requirements, which in addition to the hardware, software, and technical requirements, includes access to reviewers to provide feedback and commentary on the actual documents.

You also need to ensure that you have covered licensing costs and established access controls to networks, software, and offices locations where necessary.

Documentation Plan Template

You can download a Documentation Plan template here.