The Detailed Estimation Process

The recommended estimation process for business and IT projects is outlined in Figure 14.5. It involves slightly different steps for software developments and business and infrastructure projects such as PC installation, mainframe upgrades, LAN installation, wide area network (WAN) installation, and so on.

Figure 14.5. The generic estimation process


As we noted earlier, whereas there has been extensive research into techniques such as function points for estimating software development, there has been little research into formal estimation techniques for business and infrastructure projects.

As for all our planning techniques, the process of estimation is team-based and participative. This is very important even if you are using an estimation technique such as function points. If you do not have a team formed when the estimates are required, at a minimum, you must involve key stakeholders, peer project managers, and relevant IT and other technical support people. Again, the RAP process handles this perfectly .

When the team is created, the initial estimates must be revisited to enable team members to provide their input.

Saying No Revisited

The process of estimation can be negated by the need for senior management and other people to obtain quick answers to the question "How long will Project X take?" The process of project estimation must be taken seriously and professionally. In many cases, a "quick" estimate commits organizations to project investments, which, had a more professional approach to the estimation been undertaken, the organization would never have undertaken.

Terms such as "gut feel," "ballpark," and "professional judgment" are often excuses for poor estimation made under pressure. Project sponsors should take responsibility for ensuring that the estimates for their projects are produced in a professional manner.

Producing a reasonable project estimate requires time, effort, and commitment from the project sponsor, project manager, team members, and relevant stakeholders. The time and cost of professional estimation will be paid back many times in the improvement of decision making on project investments.


The quick "ballpark" quickly becomes a slow nightmare.

A Review of Risk Assessment

As we covered in detail in Chapter 12, risk assessment is the formalization of an "intuitive" process that has always been undertaken by project managers when planning a project.

Risk is critical in understanding the dynamics of projects and improving estimating accuracy. Project risk has an impact on four key project management concerns.

In general, the higher the risk of a project, the lower the expected quality, the higher the estimates and costs, and the longer the schedule. Conversely, the higher the required quality for the project's deliverables, the higher the risk; the shorter the schedules for the project, the higher the risk; the more severe the cost constraints, the higher the risk and; the higher the skills profile of the team, the lower the project risk should be.

The process of risk assessment is critical to ensuring that as many factors as possible are considered before you begin the estimation of effort and cost. The evidence is clear that high-risk projects have higher levels of incorrect estimation and lower probabilities of success. A complete risk model ensures that the project owner and steering committee are fully aware of the dynamic of the project that they are about to approve and the likely inaccuracy of the estimates.

Having completed the project risk assessment, you and your team can undertake the next step in estimation. If the project involves software development, the team would undertake a function point analysis and estimate. However, for all projects, the development of a project task list or work breakdown structure is required for the team-based estimation process.


The use of two or more estimating techniques enables a multipoint correlation. For example, if the estimates from function points are in the same "ballpark" as those derived from wide- band Delphi, then you should have a higher degree of confidence in your team's estimates.

Develop a Work Breakdown Structure

The development of a task list or work breakdown structure for the project is a relatively simple yet important step. Within a typical system or product development model, phases are broken into tasks and tasks are broken into subtasks (remember Chapter 13).

The process of work breakdown or task listing is essential for estimation, as it ensures that the team understands what work has to be done. One of the most common causes of poor estimation is simple failure to list all tasks required. In the team-based project estimation session, the use of experts and full participation by the team and stakeholders usually results in an accurate task list.

Having developed the work breakdown structure for the project, the project manager and the team can begin to develop the detailed estimates for each task.

Complete a Function Point Estimate

If the project involves software, it is useful to see if you can apply a function point estimate. Jones (1994) and many others have written comprehensive books on function point estimation so, if you need more detail, check out their material. Of course, there are other software estimation techniques (e.g., COCOMO), and you might want to explore these as well.

However, the following quick and dirty approach is a great start. [5]

[5] Capers Jones Applied Software Measurement , New York, McGraw-Hill, 1996. Worldwide Software Development Benchmark , International Software Benchmarking Standards Group . Thanks to Peter Hill.

  1. Count the number of logical data files and user views, not physical database files.

  2. Multiply by 10 (average weight for file complexity).

  3. Multiply by 5 (files are on average 20%25% of total function point).

  4. Adjust by 30% for low risk, 0% for medium risk, and +30% for high risk projects.


This will give you a very rough guide to the size of the software component. You can then use the following productivity factors to derive a "first cut" estimate in hours of effort:

  • Visual development environments (e.g., Visual Basic, Microsoft Access, Powerbuilder, etc.): 2 to 4 hours per function point.

  • Hybrid development environments (C++, third generation language [3rd GL], and visual front-end, Natural, etc.): 6 to 8 hours per function point.

  • 3rd GL development environment (COBOL, PL/1, etc.): 14 to 18 hours per function point.


Complete Team-Based Estimates

In the absence of any formal estimating history, estimation in many projects would be better termed guesstimating.

Zip Your Lips Again

The team will be conscious of your reaction when they are estimating. Be careful that you don't get into behaviors that influence the estimation process. So, avoid "Whhhat!!!" or "Holy Fang" exclamations when the team comes up with really big numbers .

The following technique for guesstimating based on the Delphi technique developed by Herman Kahn of the Hudson Institute has been shown to be very effective in many projects. It is a team-based technique that is easily embedded in the RAP process.

At least three people (preferably relevant experts) need to be involved in the estimation process for the technique to be fully effective. It involves nine simple steps:

  1. Information sharing: If the team has not been involved in the RAP process, you must provide team members and stakeholders with the relevant information regarding the project (i.e., the business case, quality requirements, etc.).

  2. Review project risk: If it has not already been done, you should conduct a formal risk assessment with all participants .

  3. Review the work breakdown structure: Review and refine the work breakdown structure for your project or the phase or release you are going to be estimating.

  4. Individual estimation: Each person individually estimates each task or activity using sensitivity analysis to provide a best case, likely case, and worst case estimate.

  5. Review "first-cut" estimates: All estimates are written on to a whiteboard or some public area and grouped in the three ranges.

  6. Undertake Delphi analysis: Each person discusses the various assumptions and issues they considered when developing their estimates.

  7. Adjust estimates: Where required, the various estimates are adjusted based on the team discussion.

  8. Discard outriders: Each range is averaged with outriders discarded.

  9. Final reality check: The final results are reviewed and discussed again before the estimates are published.

This process results in a highly discussed ranged set of estimates, as shown in Figure 14.6.

Figure 14.6. Wide-band Delphi estimates



This variation on the Delphi technique will work very well, provided a free- ranging discussion about assumptions made by each participant while deriving their estimates (Step 6) is allowed and that the original estimates from Step 5 are adjusted to reflect the discussions. In Figure 14.6, the outriders in each range have been deleted after discussion and before averaging the remaining estimates.

Again, it is the discussion incorporated in the wide-band Delphi technique that is important. Your team and stakeholders learn more about their various assumptions during the estimation process.

When conducting the wide-band Delphi process, it is critical that the process not be dominated by the project manager. The key to the success of wide-band Delphi is the sharing of different viewsrisk, tasks, and estimatesand the development of a common understanding of what is required to undertake each task.

In our experience, the process of wide-band Delphi works more efficiently and accurately than other estimation techniques because it involves a detailed discussion of assumptions from various viewpoints. It is also powerful for all types of projects.

Not Another Note on Sensitivity Analysis!

It is essential to state estimates as a range rather than a single figure, especially during the early phases of the project development cycle. The use of sensitivity analysis techniques is highly recommended. This technique involves making estimates that are ranged into three figures:

  • Optimistic or best case,

  • Realistic or likely, and

  • Pessimistic or worst case.

The optimistic estimate would be based on everything going better than expected, the realistic estimate would reflect the likely situation, and the pessimistic estimate would be based on the worst case scenario.

Then, based on risk assessment, you should select one of these figures as a base for scheduling. For low-risk projects, the optimistic or the realistic estimates would be the estimates used for scheduling. The higher the risk of the project, the more the realistic or pessimistic range would be used. However, all three sets of figures would be included in the project estimates.

In many cases, the realistic estimate would be the most useful estimate for scheduling. However, certain tasks may entail a higher risk than others and these may require the pessimistic estimate. In other words, using an informal risk assessment of each task, the low-risk tasks would be scheduled using the optimistic estimate, medium-risk tasks would use realistic estimate, and high-risk tasks would be scheduled on the pessimistic estimate.

An alternative method borrowed from the engineering area (PERT) is to input all three estimates into the following equation:

Expected = (Optimistic + 4*Realistic + Pessimistic)/6

This gives a single estimate (Expected) that reflects the range and distribution of all three initial estimates, as shown in Figure 14.7.

Figure 14.7. Wide-band Delphi estimates and sensitivity analysis


The use of sensitivity analysis is vital in ensuring that all contingencies are evaluated at the early stages of the project. As discussed earlier and shown in Figure 14.2, the variances between the best case and the worst case will become smaller as the project progresses through development.

Adjust for Quality Agreement

Quality is generally perceived as a technical issue. However, as we covered in Chapter 9, it has a significant impact on project management. It is the nature of projects that they consist of a series of tasks that add value by processing the project's product through a series of dependent tasks. For example, the outputs from the requirements analysis phase are passed into the system design phase.

The Defect Ripple Effect

The dependent nature of project tasks means that any defect (human or machine-induced error) in one task is passed on to the next task, where it may be detected , adding unscheduled and unplanned time and effort to remove the defect.

In other words, Task A passes input to Task B. Task B was scheduled, for example, as four days of work effort and eight elapsed days' duration. However, some of the defects from Task A are detected during Task B and these defects require another day of effort. Task B now has five days of work effort to allocate but still only eight days of duration. In other words, the person undertaking Task B appears to have misestimated the actual effort for Task B. In some cases, if Person B is not prepared to work harder, the elapsed duration for B will expand to 10 days. Of course, this process continues in a more significant way for Task C, which has to account for defects from Task A and B (see Figure 14.8).

Figure 14.8. The defect ripple



The impact of this in a project of more than 80 tasks is clearly massive and the traditional phase-end reviews will not be able to detect all the accumulated defects.

This defect ripple effect has been recorded by Jones (1994) and others as accounting for up to 40% of the total effort of a project over its development cycle. In other words, without an effective quality assurance process, a major cause of the difference between estimated effort and actual effort is the defect ripple effect.

Poor quality assurance is one of the biggest causes of poor estimation and project slippage, as it is obvious that by the middle of a project the actual effort required to remove embedded defects passed on from all the previous tasks can exceed the estimated effort required to perform the task currently being completed.

All experts on quality agree that the most effective way of detecting and removing defects is to assure quality and review each task's output before it is passed to the next dependent task. As a rough rule of thumb, each task should be expanded by 10% to allow for the quality assurance process to occur before the commencement of the next task.

It is also essential that the project tracking documents (time recording) have a recording category for defect repair and removal (see Chapter 7). Do not despair if the amount of time recorded for defect repair is high, as it is better to find them than to hide them.

Quality Requirements and Estimates

Another important aspect of quality in relation to project management is the definition of quality with respect to requirements and the impact of quality on estimates. As we introduced in Chapter 10, quality can be defined as a series of attributes.

Revising the approach introduced in Chapter 10, you should attempt to gain a consensus on what quality attributes are required for the project's deliverables and negotiate a formal quality agreement before planning and estimating the project.

In a landmark experiment with a number of computing teams in the late 1960s, Freedman and Weinberg (1977) showed that given the same data and functional requirements but differing quality requirements (e.g., one team was asked to produce the most readable output and another team was asked to minimize the use of the CPU), each team, although meeting its quality requirement, required a very different effort to achieve this. The productivity variance was 7:1!

Simply, different quality attributes have a different impact on the project estimates. Whereas some attributes such as maintainability and flexibility have relatively low impact (i.e., a requirement to make a system maintainable would not add a significant cost to the project), others have a major impact. In particular, high requirements for job impact, efficiency, usability, and portability require significant effort to achieve.

The extreme project manager and team must clearly understand the requisite quality requirements before they finalize the project estimates.

Whew! This was a big chapter, but we hope that the relatively simple and pragmatic approach to estimation covered will help you. Alternatively, you can just follow Indiana Jones and make it up as you go. It seems to work for him!

The P Files Episode 11: The Floating Brain

Fans of The Simpsons will remember the episode in which Homer runs into Ned Flanders in the mall. Ned starts talking and Homer's brain says "That's it. I'm out of here!" and leaves Homer's head, floating off. Homer just collapses and Ned keeps talking. We love The Simpsons. We saw an identical incident in a major project in Hong Kong. It was an extremely high-profile project that was running more than a year behind schedule. As we were interviewing the project people, the project manager described how, at the beginning of the project, she had been called (with no warning) to meet with the CEO. She walked into the room and the CEO was at one end of a large conference table. All the executive team was also around the table. The CEO gave her a five-minute overview of the project and then asked, "Well, Betty, how long do you think the project will take?" He then leaned back in his very large CEO-type chair . She told us, "I was so scared. I heard my voice say 500 days."

The P Files Team Comment

This is a classic case of the estimation ambush . All of you have been caught in this trap. Some big cheese comes to your desk and, after a very brief overview of some requirements, says, "So, ballpark, how long do you think this will take?" We cover this and many other estimation games in an article on our Web site ( called "Estimation Games ." However, the way out here is to get out as fast as possible without saying anything except "Right now, I don't know. Give me some time and I'll get back to you." By the way, when we finally resolved the Hong Kong project, the task of writing the software, which Betty managed, took 500 days! She hadn't had time to realize that the project also required a complete upgrade of the communications network, experimental hardware, and a massive corporate restructuring.

Case StudyEstimates

Joan and Kim sit with you and another Web developer from No Object and derive various estimates. After much discussion (wide-band Delphi), you all agree on the following estimates (in raw effort hours):


Given that the project risk has been assessed as medium, you agree to commit to the likely case range:

Initial estimate: 234 hours (Release 1 only)

You review and discuss the high-level tasks required for Releases 2 and 3. The major tasks in these releases involve training the Smuthe consultants in the other cities and capturing accommodation details in those cities. The more significant tasks are the marketing to and training of clients in Big Bucks. These are out-of-scope (we love the KepnerTregoe tool!).

You agree that the additional costs for Releases 1 and 2 are Smuthe costs.

Revised estimate: 234 hours (Releases 1, 2, and 3).

Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: