As is the case with any kind of project, business managers want to know up front, how long a technical writing project will take before it can be called complete. What kind of resources are required for completing the technical writing project. In service organisations this desire to know the effort required becomes really strong. Let us look at some of the factors that need to be considered while coming up with an effort estimate.

Technical Writing Activities

Depending on who you talk to, some of the activities that a technical writer goes through during a technical writing project are:

1. Learning – the subject for which the documentation needs to be created (can be a software, a business process, or something else).
2. Interviewing – Subject Matter Experts (SMEs) to gather information.
3. Organising the Information – to be presented.
4. Prototyping – the final outcome to get all stakeholders to agree on the final output.
5. Creating the Content – that goes into the documentation being developed.
6. Producing – the documentation in its various output formats (html, PDF, ePub, etc.)
7. Proof Reading – the produced outputs for language and communication errors.
8. Getting Reviews – with SMEs to ensure accuracy of the technical content. Making corrections.
9. Testing – the outputs in their corresponding usage environments and making corrections if needed.
10. Producing Final Output – that is validated and fit for release.

Among the 10 activities mentioned above, most people think technical writing is all about activity number 5 which is Creating the Content. Not giving due importance to any of the activities listed above can lead effort estimates ending up being very far from the actual time it takes to complete the project.

The kind folks at Writing Assist have generously created A Guide to Estimating Writing Projects. This guide provides excellent information to estimate using “average” based thumb rules if you know the final size of your output, for example, total number of pages in your PDF user manual, or total number of web pages in your online html help.

My Project is NOT An Average Technical Writing Project

More often than not we do not know how big the final outcome is going to be. If it is not possible to know before hand if the user manual for the new CRM tool developed by your company is going to be 150 or 300 pages, then you need to use other techniques to come up with estimates.

In an article titled the The Black Art of Estimation, Gordon McLean provides an excellent way to plan a technical writing project. His plan of coming up with an estimate for technical writing projects is something like this:

Through interactions with the SMEs and by attending software development and specification meetings try to build a list of features and functionalities that need to be documented. Break down each of the functionality into smallest possible topics that are in a way complete by themselves.

It is assumed that it takes 5 hours to create, review, correct and produce this topic. Once the full list of topics to be created is compiled, you need to judge each of them based on 4 criteria. Each criteria is given a score of 1 to 5. The criteria used by Gordon are:

1. Complexity of the topic
2. Length of the topic
3. Ease of access to Information
4. Availability of an SME

The score of 3 means that for particular criteria, it will take 5 hours to create that topic. For a score of 2 you need to add 1 hour to the time, a score of 1 means you need to add 2 hours. A score of 4 means you reduce 30 minutes from the 5 hours and a score of 5 means you reduce 1 hours from the assumed 5 hours.

This scoring can thus help you to estimate if a topic is going to take 10 hours to create or just 1 hour to update/create. You have to then add all the estimates for individual topics and voila you get the final estimate for the documentation project.

Project Risk

The final but important step would be factor in Project Risk. A project risk percentage of 20% to 30% should be added to the estimate to account for the unknown events that might strike during the project execution.

Although it is not an exact science and I think estimation will never be an exact science, some method to madness can be introduced using the method described above or using any of the other well know estimation techniques that are commonly practiced by Project Managers.