Technical Writing Projects: How to Create Doc Plan

How long will it take to write those documents? How many writers will you need to get it completed? How much will it cost? What’s the delay?


Any of this sound familiar? If you’re new to managing a tech doc dept, you’ll need to find ways to estimate the amount of time, effort, cost, and contingencies that need to be factored into your projects.

  1. Specifications – are the specifications complete? Identify who can confirm if the specifications are complete, signed off, and whether they are likely to change. Working on incomplete specifications is like trying to document a moving target.
  2. Style Guide and Reformatting – what amount of your time will be spent updating the content to align with your style guide, if you have one? This has to be considered if you plan to peer review or update text from another colleague. Re-writing text to align with guidelines and standards is very time-consuming.
  3. Writing – the actual writing may only take 20-30% of your time. The rest is consumed in gathering information, communication with team leads, getting clarifications, and other tasks related to the subject matter.
  4. Peer Review – ideally, everything you write should be reviewed by another team member. If not, get a business analyst or developer to check the accuracy of your material.
  5. Content Delivery – it’s not unusual for writers to write in, for example, MS Word and then copy/paste it into wikis, RoboHelp, or FrameMaker. Why? Two reasons: One, because it may be necessary to deliver the same content as a PDF, on a wiki, or Online. Two, because there may not be a simple way to export the content from one authoring tool to the next, eg FrameMaker to RoboHelp, without tinkering with styles, formats, layout and so on. Many writers prefer to write the raw text in Word and then format in their respective authoring tools. Choose whatever approach is most productive.
  6. Document Impacts – when you update a piece of content, is there an impact of other documents, for example, other installation guides or releases? Does conditional text need to be applied for specific releases?
  7. Access to working software – sometimes you have to get started without having working software in front of you. While this is far from ideal, it’s not unusual to have to write with the understanding that the GUI may change, for example, new fields may be added, and to allow for these in your estimates. However, this stopping and starting will eat up your time as you’ll need to check each release if and where they are new changes and document these.
  8. Access to developers and subject matter experts – while you may be able to understand some parts of the software, for example, how the GUI works, if you need to document aspects of the system that occur ‘under the hood’, such as Java classes, servers, databases etc, you may need to clarify things with the developers or domain experts. Factor this into your workload as getting demos, answers to questions, and reviews all need to be considered. If these people are not in the same office, allow for scheduling meetings and the extra time this may take.

Remember, there is a risk if you start to document too early in the development process, and the specifications and requirements change due to changes in the budget, timelines and scheduling, your estimates will be affected. Allow for this when preparing estimates and give yourself some bandwidth for known unknowns.

Have you got these templates?