In projects with tight deadlines, many managers look to see if they can add more resources to help get more work done in parallel. Technical documentation just happens to be one of the few areas where this strategy works. Bringing a technical writer onboard to produce technical documentation for your product, is a great way to remove this burden from your development team. In this article we’ll take a look at some of the things you should do to prepare for this additional resource.
One of the first things you should identify is the timing and scope. Estimate how much work there is and how complex the information will be. As a general rule of thumb, a technical writer will spend is 60%-70% of their time gathering information and 30%-40% writing and formatting the final documentation. The more complex the information, the more time the writer will need to spend with members of your development team to gather and understand it.
With this in mind you should then identify subject matter experts (SME’s) who will assist the technical writer. You should ensure that time is built into their schedules to answer questions and disseminate information to the technical writer. You should also identify if any of the SME’s are under tight time constraints and if necessary, alternative SME’s who can provide the writer with information. What you want to do is prevent the technical writer from being stalled while at the same time not stalling your SME’s with the additional task of working with the technical writer. Those technical writers with a strong technical background like Essential Instructions, will minimize this overhead because they know what questions need to be asked.
Next, ensure that your product, code or whatever needs to be documented is mature enough for documentation. If there are many features yet to be implemented or undergoing numerous design changes, then attempting to document this can be a waste of everyone’s time. It’s better to bring the technical writer in a little later in the project then to have them document a moving target.
This leads to a more general question—when is a good time to add a technical writer to your project? This will depend on your project, but try to identify areas that have been or will be solidified to the point that they can be documented and work with your technical writer to put estimates against them. From this you might choose to have your technical writer assist through to the end of the project, or have them assist in multiple phases of smaller projects which coincide with other project milestones.
You will also need to identify early on, which tools you want to use for your documentation and what output formats you want to support. With set budgets for development tools, it can be easy to forget that tools for documentation should also be budgeted for. You will also want to consider who needs to be able to edit the documentation. If this includes every member of your team, then purchasing a help authoring tool license for each member may not be practical. Also, the overhead of having each person learn how to use the tool may not (and usually is not) practical.
You should also consider which output format(s) you want to support. If there are multiple formats to support, then this will dictate the use of a help authoring tool (we recommend Help and Manual for its ease of use and relatively low cost – see our article here).
Finally, you need to choose a technical writing resource who has flexibility. Unfortunately most technical writer contractors work on a temporary full time basis. However, a firm like Essential Instructions provides you with the flexibility you need to add this resource only when you need it (see our article on contractor’s vs conultants).
In summary, adding a technical writer to your project is a great way to take care of technical documentation in parallel with other project tasks. With a bit of planning you can make optimal use of this resource and get the best bang for your buck.