Search results

My documentation project plan template

by Tom Johnson on Jun 7, 2019
categories: technical-writing

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:
  • 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:


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

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.