My documentation project plan template
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 a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.