In this post I share my documentation project plan template. This is designed for project managers to complete. Having all these details present helps you scope projects and recall all needed details if you have to de-prioritize the project for a while.
In my previous post, How to avoid inefficiencies even with context switching, I mentioned that having a doc plan helps you maintain all the needed details for a project so you can re-familiarize yourself more quickly with the project as needed. For example, if you have to switch contexts from one project to another, you can return to the de-prioritized project and ramp back up more quickly with all the contextual details you need to be productive.
I’ve made this version of my project plan a bit more general (to avoid anything company-specific), but it’s mostly the same. The idea is that project managers complete this initially, not the tech writer.
Also note that this doc plan is more geared towards working in a large company where you might have incoming doc projects from many different groups, many of whom you might be interacting with for the first time.
Documentation Plan Template
This doc plan defines the scope and details of documentation for a project. Project managers should complete this information.
Person completing the doc plan:
Some basic details about the project:
Product code name:
Brief product description:
Project status page:
Business requirements doc:
Other product documents:
Where this project originates from:
Key contacts on the product team:
Who the target users are:
How the team tracks issues related to this product:
When the product is being released:
Product announce date:
Beta release date:
General launch date:
Project information sources
How information flows within your team. This helps us stay in the loop.
Team meetings related to this project:
Where the code is stored (if applicable):
How is the product tested:
Device pools for testing:
What localization is needed:
Translation to Japanese:
Translation to other languages:
If pre-release doc requires authentication, how will access will be managed:
Reviewers for docs
Who will review the docs:
Who supports the content post-launch:
Support ticket category:
Support manager contact:
Internal product wiki/resource pages
Important wiki pages for this product:
This section to be completed by the technical writer
Scope and complexity
How much doc work is involved:
Big project (4+ weeks of work):
Medium-sized project (1-3 weeks of work):
Small project (0-1 weeks of work):
Documentation deliverables that are needed:
[In this area, I keep a log of running notes after meetings and other contacts with the products.]
Overall, this project plan works fairly well. There’s a lot of info here that people need to make explicit. When we estimate the doc work for a project, it’s impossible to estimate the scope without this information. And without scope, we end up being pulled into projects that are more massive than they initially appear.
One thing I can’t quite figure out is the “Doc Deliverables Needed” section. People check all the formats by default (PDF, screencasts, sample apps, etc.) because presumably it’s all “free.” We don’t have a good mechanism to instill “buyers” of the docs with a sense of cost. I can’t just put “These item cost extra here” next to all of the deliverables beyond web pages. I’m curious whether you have strategies for this.
Overall, any feedback on my doc plan here? I didn’t want to make it more comprehensive because then project managers won’t have the bandwidth to complete it. But any less complete and it’s not as useful to our team.