Geetha Haridas, Qualcomm
April 15, 2023
Estimation is often an overlooked aspect of the documentation development lifecycle, particularly in environments that require authors to work reactively and meet multiple deadlines in short timescales. Though some amount of project uncertainty is inevitable, failure to estimate documents can have a major impact on the quality of documentation produced. For example, authors might absorb too much last-minute work and might not have time to self-check their documentation, which consequently impacts the quality of work they produce.
Therefore, before agreeing to deadlines, it is extremely important to assess the time and effort required to complete a project and then plan the work schedule. It is also essential to ensure that the projects are not estimated based on individual experience and the estimates are relevant for all authors involved, especially if a project involves multiple authors.
This article provides a framework for estimating projects, especially in the context of product documentation. The article describes the T-shirt sizing method (quick estimation method) and the three-point estimation method, and summarises the pros and cons of using these methods. Finally, the article provides a checklist that highlights some regular issues to consider when estimating a project.
Quick Estimation Method
The Quick estimation method can be used to provide a quick estimate depending on the ‘size’ of a project. This model suggests that projects can be classified depending on their size and estimated accordingly. Each size corresponds to a specific number of days, as shown in the following example.
Figure 1: Quick Estimation Method
Sizes to Use
The definitions of the sizes such as small and medium depend entirely on the nature and size of the projects at your organization. You could potentially arrive at example estimates based on how long it took you to complete similar projects in the past. The following table provides an example.
| Size | Days | Example Projects |
| Small | 2-15 | Quick Start Guide. |
| Medium | 15-25 | Application Note. |
| Large | 25-35 | Software Installation Guide, written from scratch. |
| X-Large | 35-55 | Configuration Guide, written from scratch. |
| XX-Large | 55+ | Implementation Guides covering installation and configuration, written from scratch. |
Benefits
- You can provide a quick estimate without doing a detailed work breakdown or task analysis. This method therefore saves time.
- The use of historic data to classify projects can result in reasonable estimates.
Drawbacks
This method does not consider the uncertainty or complexity of a project. However, because this method involves estimating a range rather than an absolute value, this method can account for any differences in the complexity of projects and/or varying product knowledge of authors.
Three-point Estimation Method
The three-point estimation method involves arriving at a set of three estimates to identify the effort involved in completing a project in different scenarios:
- The most optimistic estimate (O), which is likely if everything goes according to the plan and there is no uncertainty in terms of the project or resourcing.
- The medium estimate (M), which is likely if there is some project or resource related uncertainty, for example lack of agreement on the functionality to be developed or lack of dedicated resources for technical reviews.
- The pessimistic estimate (P), which is likely if there is a lot of project and/or resource related uncertainty, for example if the scope of the project is likely to change completely and/or you have authors who are completely new to your organisation.
The average estimate is then calculated using the formula: (O+4M+P)/6, as shown in the following example.
| Task | Effort (in days) | ||
| Optimistic (O) | Medium (M) | Pessimistic (P) | |
| Write eight procedures | 6 | 7.5 | 8 |
| Write two overviews | 4 | 5 | 5.5 |
| Write an introduction | 2 | 2.5 | 3 |
| Create a flow diagram | 0.5 | 0.75 | 1 |
| Total | 12.5 (13) | 15.75 (16) | 17.5 (18) |
Estimate = [13 + (4 X 16) + 18] / 6 = 15.8333 (16 days)
To make it easier for authors in your team to estimate consistently, you can define base values that are relevant for everyone, depending on the tools you use and the type of information you produce. The following table shows example effort estimates (in days) for various documentation tasks.
| Task | Easy | Moderately Complex | Highly Complex |
| Introduction | 1 | 2 | 3 |
| Overview | 0.5 | 1 | 2 |
| Procedure | 0.5 | 1 | 2 |
| Graphic | 0.25 | 0.5 | 1 |
| Glossary | 1 | 2 | 3 |
Benefits
- The method takes the complexity of projects and product knowledge of individual authors into account.
- The estimate is formula-based and therefore easy to calculate. The formula can also be built into a spreadsheet that can make it easier for authors to use.
- Authors can produce a range of estimates that hold good for different projects and scenarios.
- The method is more practical and reliable than a single-point estimate.
Drawbacks
Depending on their experience, individual authors might still arrive at different estimates. However, the range of estimates (optimistic, moderate, and pessimistic) should help in accounting for any differences.
Process
The estimation method that should be used for a project depends on several factors such as:
- The overall size/complexity of a project. For example, simple projects may not require detailed estimation and specification.
- The urgency of requests for sizing a project. There may be adhoc, but critical requests to estimate projects, for example, to assign authoring resources depending on the priority of a project.
- The stage at which a project currently exists. If a project is at a very early stage, it might not be feasible to do detailed estimation.
The following flowchart shows a process that can be used to estimate documentation projects.
Figure 2: Estimation process
The flowchart outlines the following process:
- When an estimation request is made, create a quick estimate to assess the overall workload. Do not create detailed estimates at an early stage of the project, as the scope of the project might change.
- If the project is stable, but the quick estimate is less than or equal to 5 days, use only the quick estimate for the project – detailed estimates and documentation specifications are useful only for medium to large projects.
- If the project is stable and the quick estimate is more than 5 days, calculate a three-point estimate.
Checklist
In addition to the actual documentation updates, which include writing concepts, overviews, procedures, and creating diagrams, various other factors might influence your estimate.
The following checklist provides additional items that you can consider when estimating your projects.
| The quality of existing documentation (text and graphics) has been assessed. If appropriate, any further improvements to the existing documentation have been identified and accounted for. | |
| Dependencies on other teams and/or any information that is currently unavailable have been identified and accounted for. | |
| If content can be reused, the appropriate versions of the source files are available. | |
| Any outstanding documentation bugs from previous releases have been reviewed and accounted for. | |
| Any impact of the documentation updates on other guides/projects has been identified and communicated. | |
| Additional time for unexpected tasks has been included in the estimate. | |
Conclusion
Documentation estimation is an integral part of the planning process, which can be useful to assess workload, schedule projects, and allocate sufficient time to produce quality documentation.
Estimation does not always have to be a detailed process involving complicated procedures. You can use appropriate techniques depending on the stage at which your project is and the complexity of work involved. With consistent use of these techniques, the estimation process can get easier and allow you to proactively identify and deal with aspects that are likely to impact your project.