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
- 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.
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.