The Pros and Cons of 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.
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.

Resource Requirements:  Documentation Plan Template

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.
Some questions for you!
Do you use a Documentation Plan for your tech writing projects?
If not, how do you manage timelines, budgets, and deliverables?
If you do use them, what is the most important part to focus on?

Reblog this post [with Zemanta]

Top 50 Technical Writers on the Web

I’ve made a list of the top 50 technical writers with a web presence. Some of these you might know, such as Darren Barefoot and Tom Johnson. I have also added some other writers from India, Russia and Israel to reach out to a wider audience. I’m sure there are others that I’ve missed. Let me know and I’ll update the list.

I’ve made a list of the top 50 technical writers with a web presence. Some of these you might know, such as Darren Barefoot and Tom Johnson. I have also added some other writers from India, Russia and Israel to reach out to a wider audience. I’m sure there are others that I’ve missed. Let me know and I’ll update the list.
This week’s new additions include Alan Houser, Char James-Tanny, Cheryl Locket-Zubak , Colum McAndrew, Joe Welinske, Michael Hughes, and Paul Mueller.
Continue reading “Top 50 Technical Writers on the Web”

Twitter Updates for 2009-06-23

DITA specialization in Adobe FrameMaker 9

DITA Specialization lets you define new information classifications that can be structural or a new domain specification. Structural specialization in DITA lets you define new topic or map structures derived from base topics and maps, such as concept, task, or reference whereas domain specialization in DITA lets you define markup for a specific information domain or subject area, such as programming or hardware.

DITA Specialization lets you define new information classifications that can be structural or a new domain specification. Continue reading “DITA specialization in Adobe FrameMaker 9”

Follow Friday – News and Views June 3

Follow Friday – News and Views June 3rd 2009. Here’s a roundup of some of this week’s news. Next week, I’ll add more info on upcoming XML authoring software releases and the new Google Wave platform.

smileHere’s a roundup of some of this week’s news. Next week, I’ll add more info on upcoming XML authoring software releases and the new Google Wave platform. Continue reading “Follow Friday – News and Views June 3”