Let’s assume you wish to estimate the total amount of work effort (typically expressed in labor hours) needed to complete a certain project. The estimation process begins with each participant independently developing an initial list of the tasks that will have to be completed to reach the stated project goal, using a form like that in Figure 11-3. This form is also included with the work aids that accompany this book. Figure 11-3 illustrates a very small estimation activity, developing the requirements for a new project called Project X. The person who completed this form initially identified five tasks that would be involved in developing requirements, the first five items listed under the "Task" column heading.
Each participant then estimates the effort each task will consume. Decompose each activity down into tasks that are small enough to estimate accurately. I don’t feel comfortable estimating individual tasks larger than about 15 labor hours but your size threshold could be different from mine. State the tasks clearly because someone will have to merge all of the participant task lists into a single composite list. Total the estimates you produce for each project task, in the agreed-upon units, to generate your initial overall estimate. Returning to Figure 11-3, the column headed "Initial Estimate" shows the number of labor hours this estimator assigned to each of the five identified tasks, for a total of 67 hours estimated for developing the requirements for this project.
Your estimate should bear no relationship to the answer you think the project manager or other stakeholders want to hear. There’s a chance the estimate will fall outside the acceptable project bounds of schedule, effort, or cost. This situation demands negotiation that could lead to scope reduction, schedule extension, or resource adjustments. But don’t let outside pressure sway your best projection of how the project will play out.
In addition to identifying the project tasks, separately record any tasks for related or supporting activities, such as quality tasks, process activities, and waiting time that imposes delays. In my first Wideband Delphi session, every participant forgot to list tasks on the first cycle dealing with quality control and assurance, configuration management, and process-related activities. We caught this quickly and added them in for the next iteration. Be sure to include rework tasks following testing or inspection activities. Reworking to correct defects is a fact of life so you should plan for it. If you’re estimating a project schedule, also identify any overhead activities that aren’t specific to the project that you might have to build into your planning. These include meetings, vacation, training, other project assignments, and myriad other things that suck time out of your day.
Since radically different assumptions can lead to wide estimate variations, record any assumptions you made while preparing your estimates. For example, if you assumed that you will purchase a specific component library or reuse one from a previous project, write that down.
Another estimator might assume that the project will custom-develop that component library, which will lead to a mismatch between your two overall estimates.
Keep the following estimation guidelines in mind, even if they don’t reflect exactly how the project work will be performed:
Assume one person will perform all tasks.
Assume all tasks will be performed sequentially; don’t worry about sequencing and predecessor tasks at this time.
Assume the worker can devote uninterrupted effort to each task. This may seem absurdly optimistic but it simplifies the estimation process.
In units of calendar time, list any known waiting times you expect to encounter between tasks. This will help you translate effort estimates into schedule estimates later on.