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.
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. 
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:
Complete Team-Based Estimates
In the absence of any formal estimating history, estimation in many projects would be better termed guesstimating.
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:
This process results in a highly discussed ranged set of estimates, as shown in Figure 14.6.
Figure 14.6. Wide-band Delphi 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:
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:
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!