Bindu Nayar
Do you feel that estimating the documentation effort required for a project is nothing short of predicting the future? This view is strengthened when the estimates are inaccurate and the project is plagued with variance in scope and delays in delivery.
Any project is controlled by four major variables: schedule, scope, resources and risks. Unexpected changes to any of these variables can have an unexpected impact on the project. Therefore, it is imperative to make a “good” estimate of the time and resources required for the successful delivery of the project. The key is to not underestimate or overestimate the effort required.
There are many well established methods for effort estimation. Before you decide to adopt a particular method, it is important to understand whether the estimation method fits your needs.
Through this article, I will share my experiences in using the Wideband Delphi method of estimation for documentation projects. The process outlined in this article is customized to real-world project needs and the documentation life cycle.
What is Wideband Delphi?
The Wideband Delphi method evolved from the Rand Corporation in the 1940’s as an estimation technique. In the 1970’s, this method was re-evolved to include greater communication, interaction and participation among the estimators. The method, which was earlier used as an estimation tool in the sales and marketing field, was later on used for estimation in software projects.
Let’s take a look at the process.
Prerequisites
You need the following information before you begin the estimation process:
- A list of features or the Product Requirements Document (PRD) that will have an impact on your product.
- Milestones and deadlines for the release of the product.
- List of subject matter experts (SMEs) who can help you understand the changes better.
The Process
The Wideband Delphi estimation technique involves the following steps:
- Identifying the estimation teams
- Introduction/kickoff meeting
- Preparation
- Estimation meeting
- Closure meeting
Identifying the Estimation Teams
An ideal estimation team comprises 3-7 members. Usually, the project manager decides the team composition and appoints the moderator. In the absence of a project manager, the author can take the responsibility of deciding the team members.
The estimation meeting must include key SMEs, the engineering manager, and a peer. This composition ensures that all aspects of documentation and the project are factored in during the estimation meeting.
Introduction/Kickoff Meeting
In this meeting, the author shares the scope of changes that will affect the documentation with the estimators. This information helps the estimators to get acquainted with the product changes that have an impact on documentation. The author should share only the scope and the impact on the documentation piece and not the effort involved in getting the work done. This step is important to ensure that the estimates worked out are fair and without bias.
Illustration 1: Scope of documentation changes
While sharing the understanding of the features with the estimators, make sure that you share the authoring process as well. For instance, if you need to conduct peer reviews, technical reviews, and unit testing to consider a feature as complete, share this data with the estimators.
Sharing the scope and impact on the documentation helps set the context among the estimators. This ensures that when all the estimators meet for the next step— the estimation meeting—everyone has the context. This will help effective utilization of time.
Preparation
After the author shares the scope and impact, each estimator individually generates the initial estimates for each change. During this process, each estimator also assesses the scope and impact details shared by the author. The data from this activity is intended to be utilized in the estimation meeting.
Estimation Meeting
At the start of the meeting, the moderator or the project manager charts down the estimators names and the list of features for discussion. In the estimation meeting, the moderator leads the estimation team through iterative steps to get a consensus on the estimates.
The moderator then asks each participant to share the estimates. All the estimators have the details ready after the Preparation phase. As illustrated in Illustration 2, all estimators start by first sharing the size estimate in pages and then the effort estimates in terms of person days.
In a typical scenario, the authoring process involves more than just writing about the product. It also involves a series of steps ranging from understanding the feature to unit testing the feature to ensure correctness and completeness.
In this case, the author’s effort estimate indicates the effort spent by the author in getting the document ready for review and incorporating the comments from the reviewers. During the estimation process, the other estimators are also called upon to assess how much time they think the author should ideally take to author and review the document.
Illustration 3: Author’s estimates
Let us use an example to make this point clear:
Author A needs to document five new features for a release. The author has made estimates on what is the size of documentation and the effort required to get it done. This is what the author’s estimates look like:
The other estimators also share their estimates. In the above figure, you can observe a variance in the estimates of the estimators. This is expected because every person has a different perspective on the effort required to complete a work product. The Wideband Delphi method is devised to deal with such situations and arrive at a consensus. It is now the turn of the moderator to assess the variations and investigate why the estimates differ and if there is a way that the estimates can be revised.
In Illustration 4, look at the effort estimate data corresponding to Feature 1. All the estimators agree on the number of pages that Feature 1 will require, but they don’t agree on the effort that is required.
It is now up to the moderator to find the reasons for the variance. He or she asks each estimator to explain the assumptions behind the estimate that they have suggested. If required, the author can explain the scope again and the impact of scope on documentation that was considered while projecting the effort. The other estimators then re-assess their estimates in the light of the explanation and can revise the estimates.
This process continues until all the estimators arrive at a consensus. In some cases, the estimators may not arrive at the same effort estimate even after multiple iterations. So the Wideband Delphi method allows for a variance of .5-1 person days or a variance of .5-1 pages. However, if there is a higher variance, the moderator must help the author to revise the estimates.
While estimating effort for complex projects, it is recommended to gauge the effort estimates using principles of “best’, “worst”, and “likely.” Here “best” indicates a scenario where there is no uncertainty about the scope and impact. “Worst” indicates a scenario where there is very high level of uncertainty. A “likely” scenario is that in which there is a medium level of uncertainty.
After all the estimates are listed, the moderator arrives at a nominal value by averaging out the variance. The nominal value is the best indicator of effort that will be required to complete a feature.
As explained earlier, the estimation team can do multiple iterations to iron out the variance and agree on the effort and size of the deliverables.
Closure Meeting
The closure meeting is the last step and is often not mandatory. This meeting usually takes place if, despite repeated iterations, the estimators cannot arrive at a consensus. In this meeting, the author clarifies his or her stand on the estimates and explains the reasons for the projected estimates. The last word on the effort estimate lies with the author.
Delphi in the Real World
No projects are static in nature. In a real-world scenario, many factors can impact the scope of a project. Every time the project faces a variance, it is important that you reassess the assumptions and conclusions and make adjustments accordingly. Using the Wideband Delphi method of estimation has several advantages over other methods of estimation for the following reasons:
- The introduction meeting helps build a complete task list or work breakdown structure that can be utilized for other major documentation activities.
- As the base of this method is arriving at a consensus, it helps to eliminate bias in estimates.
- No estimator knows what the accurate effort and size is, for a deliverable. Therefore, there are no right estimates or wrong estimates but just realistic estimates. A mix of stakeholders ensures there is no bias in the estimation process.
- This method depends on iterations to arrive at effort and size estimates and thus re-establishes the value of iterations to complete a complex activity.
About the author
Bindu Nayar is a Lead Technical Writer with over 10 years experience in the technical writing field with core experience in protocol and developer documentation. In addition to primary role of authoring, she is currently involved in project management activities at Novell. 
Cool article..
Great article … clearly explained the process
Thanks