My documentation project plan template
- Documentation Plan Template
- Project overview
- Business group
- Product team
- Target users
- Issue tracking
- Release timelines
- Project information sources
- Code repositories
- Testing
- Localization needs
- Restricted access
- Reviewers for docs
- Support post-launch
- Internal product wiki/resource pages
- Scope and complexity
- Doc deliverables
- Doc tickets
- Running notes
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:
- Date completed:
Project overview
Some basic details about the project:
- Product name:
- Product code name:
- Brief product description:
- Project status page:
- Business requirements doc:
- Other product documents:
Business group
Where this project originates from:
- Organization:
- Business group:
- Team:
Product team
Key contacts on the product team:
- Product manager:
- Project manager:
- Software developers:
- Quality assurance:
- Marketing:
- Developer Outreach:
- Legal:
Target users
Who the target users are:
- Managed developers:
- Unmanaged developers:
- End-users:
- Other:
Issue tracking
How the team tracks issues related to this product:
- Ticketing systems:
Release timelines
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:
- Team sprints:
- Scrum master:
- Email lists:
Code repositories
Where the code is stored (if applicable):
- Git repo:
- Other storage:
Testing
How is the product tested:
- Test environment:
- Test scripts:
- Device pools for testing:
Localization needs
What localization is needed:
- Translation to Japanese:
- Translation to other languages:
Restricted access
If pre-release doc requires authentication, how will access will be managed:
- Authentication required:
- Authentication manager:
Reviewers for docs
Who will review the docs:
- Doc reviewers:
Support post-launch
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):
Doc deliverables
Documentation deliverables that are needed:
- Web pages:
- Tutorials:
- PDF:
- UX microcopy:
- Screencasts:
- Sample apps:
Doc tickets
- Ticket folder:
Running notes
[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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.