Read the Article below "5 Keys to estimating" and submit your summary feedback

Abstract

In the realm of project management, nothing is more valuable than estimates that accurately reflect reality, motivate their fulfillment, and facilitate rigorous accountability. During this unique, concise presentation you will receive the keys for mastery of an enduring project management challenge. Years of experience have shown that mastering the art and science of estimating can help you avoid painful, tragic lessons...and accelerate your career!

This powerful training experience gives you a solid understanding of estimating as a science, as well as the experience of estimating as an art, with loads of practical information on how to :

• Reconcile and align objectives and estimates
• Handle estimates that exceed budgets
• Eliminate "sand bagging," "compounding," and "unintentional buffering"
• "Unlock the unknown" with a quantifiably defendable estimate
• Create repeatedly desirable estimating results

Introduction

An often overlooked but very important point is that a project needs to have both objectives and estimates...and that they should be different! In fact, it is a common and often fatal mistake for the project team to prepare estimates to meet objectives instead of preparing them to evaluate objectives. Techniques for avoiding this trap will be demonstrated in the section "Reconciling Project Objectives and Estimates."

When the project is analyzed and the total estimate exceeds the total budget, we have a not uncommon problem. Understanding and resolving this challenge requires analyzing the variables that are driving project cost so that they are objectively isolated. As the results become known, typically a classical misperception of project risk is at the center of the misalignment. We will describe how to resolve this problem in the best way possible in the section on "Handling Estimates That Exceed Budgets."

Using team-based planning disciplines for reviewing work breakdown structures (WBS) and project schedules we will look at how a fully integrated estimate eliminates many difficulties. We will also show how it motivates the entire team to fulfill the work requirements while staying within the estimate. These concepts will be covered in the section on eliminating "sand bagging," "compounding," and "unintentional buffering."

Among all the stressful facets of project management, none evokes the fear, the sense of foreboding, and the absolute dread that comes from needing to provide estimates for some requirements that are, quite simply, unknown or unknowable. Luckily, we have quantitative tools that make it possible to manage even the very nature of this complexity. The Program Evaluation and Review Technique (PERT) Kernel will be demonstrated as one such tool in the section "Unlocking the Unknown with Defendable Estimates."

Having a process that repeatedly delivers successful estimates is the "holy grail" of project management. In the section "Creating Repeatable Successful Estimates," we will detail the normal steps involved in such a process: Step 1: prework; Step 2: creating initial estimates; and Step 3: finalizing the real estimates.

Reconciling Project Objectives and Estimates

As we learn the process of producing accurate estimates, we should recognize that one important purpose of a WBS is to organize the work-effort of a project in such a way that it aids in estimating the total resources required by a project. It is also worth noting that project schedules focus on time-phased resource needs. However, without accurately estimating the total resources initially, it is impossible to schedule those resources accurately.

A second important point is that a project needs to have both objectives and estimates...and that they should bedifferent!

It is a common and often fatal mistake for the project team to prepare estimates to meet the objectives of the customer or marketing or management, instead of preparing them toevaluateobjectives.

During the typical bid and proposal process, the customer and marketing "team" are trying to achieve an objective---for example, to develop and deliver the Acme SuperBot within 1 year for $1 million. This desired objective influences them to start where they want to end up and develop top-down estimates that "succeed" by meeting the objective (Exhibit 1).

Exhibit 1--Evaluating Objectives

To counter this natural tendency of the customer and marketing team, the project team must draw a distinction by working from the bottom up: first defining the requirements, then estimating the work, and finally evaluating the results.

It is a happy and rare day when the two processes reach the same conclusion. More often the project manager and team are faced with the challenge of estimates that exceed budgets. Before we learn the estimating process, it will be useful to understand how the project management system that you are learning faces this challenge.

Handling Estimates That Exceed Budgets

There are three main causes of this problem. The first are the misperceptions by the customer and marketing team that led to over-optimism while they developed the budget. The second is misunderstanding by the project team that developed the estimates, which usually results in pessimistic or very conservative assessments. And the third is a combination of the first two. In all three cases, the solution is better communication about the objective facts that control the project. Luckily, those facts are within the domain of the project team.

In order to develop the needed objective facts you need to understand the basic project management ecosystem. Step 1 is developing an accurate WBS. Step 2 is accurately estimating work package and task durations. Step 3 consists of the two disciplines of developing the project schedule and analyzing its critical path. Step 4 is evaluating the results. Step 5 is reconciling the budget and estimates and communicating the objective facts to the appropriate stakeholders. Step 6 is to return to Step 1, make any needed revisions, and reprocess the project. Let's look at how this systematic approach solves the problem of estimates that exceed budgets.

The key to how the system resolves the problem is Step 3. When the project schedule is created and the critical path is analyzed, the variables that are driving the time and cost facets of the project are objectively isolated. As the results of Step 3 are evaluated (in Step 4), the causes of too much optimism on the part of the customer and marketing team are isolated. Likewise the evaluation isolates the causes of too much pessimism on the part of the project team. Classically, a misperception of project risk is at the center of the misalignment. When the customer and marketing team were considering the three variables of a project---time, cost, and quality---the information that they were considering was most likely incomplete. In order for the information to be complete, it must include an accurate understanding of how the three variables interact. Yet that information isn't really available until the project manager and team work out the project schedule, because defining the logic of those interrelationships is a vital part of the scheduling process.

On the other hand, when the project team was estimating work package durations, in order to be conservative, each person more often than not added some time as a "buffer" against the risk of unexpected issues. Also, as a rule, the project team developed the schedule using the standard or most common understanding of the logic that governs the relationships between tasks. Each of these considerations must be addressed during the evaluation. The first order is to eliminate the "compounding" effect of individual estimates containing a buffer. The second thing that needs to be done is consider redefining the logic controlling the relationships from hard logic to soft logic.

Once the project manager and team are convinced that the logic has been optimized and the estimates have been revised to reflect reality, the final hurdle to cross is communicating the results to the customer and marketing team. If the project team has done a thorough analysis and given an effective presentation to the customer and marketing team, two primary results are possible. Most of the time (in our experience) the customer adjusts their expectations and the project can begin with a realistic, even promising, launch. When that is not the case, over time the validity of the project team's estimates will become apparent. Then, depending on the nature of the contract, the customer will pay more or the company will begin to "buy into the project" (i.e., lose money).

Because the results of the project will ultimately be a matter of objective fact, project management is most effective when it helps all stakeholders to make decisions based on accurate and adequate information. By providing solid, truthful information, project managers can lead team members, management, and even customers to make better decisions. No amount of denial or wishful thinking will deliver a $1 million project for $750,000. Recall that it is incumbent on the project team to produce an accurate and adequate estimate of the project's outcome. It is the responsibility of the customer and management to deal with that reality.

Sometimes estimates exceed budgets because that is the real truth. As hard as it might be to make a good decision under those circumstances---and the bigger the variance, the harder and more critical the circumstances become---reality must be faced by the customer and management.

Eliminating "Sand Bagging," "Compounding," and "Unintentional Buffering"

When the project team is estimating durations for each work package, in order to be conservative, more often than not they added some time as a "buffer" against the risk of unexpected issues. (Although the practice of "sand-bagging"---defined as selfish or unscrupulous exaggeration of the time required to complete work package or task---is unofficially decried and formally denied, it has the same affect as buffering, and therefore we will not address it separately.) The result is a schedule with an oversized buffer due to a "compounding" effect which, while normal, must be eliminated in order to develop a true picture of the schedule.

So even though initial estimates can be made individually, final estimates need to be defined during a team exercise analyzing the schedule. The final schedule must be the result of project estimates that integrate all aspects of work execution and consciously insert buffers that correspond with risks identified and agreed upon by the entire team. In practice, the team gathers in a conference room or other suitable space and reviews the project schedule, examining each work package or activity identified. The work package owner explains to the team the work that will be executed to convert the input received from the predecessor activities into the output defined in the completion notification sent to the successor activities. The team's purpose during this discussion is to determine that the same work is not being included in two tasks and that the estimated duration is reasonable given their experience.

For many team members who have never participated in this type of review before, there may be initial shock at how rational the process is, how impartial the calculations are, and how quickly overstated estimates are questioned by the team. They may put the work package (and its owner) on the critical path, where they are subject to closer scrutiny and management by the project manager.

"Unlocking the Unknown" with Defendable Estimates

Among all the stressful facets of project management, none evokes the fear, the sense of foreboding, and the absolute dread that comes from needing to provide estimates for some requirements that are, quite simply, unknown or unknowable. Luckily, we have quantitative tools that make it possible to manage even the very nature of this complexity. The Program Evaluation and Review Technique (PERT) Kernel is one such tool. Earlier, we developed the idea that decomposition was pursued until accuracy in estimating was possible or until greater detail in the structure was impossible. When the limit of greater detail has been reached, and accurate estimating is not considered possible, we have reached the realm of the unknown.

In 1958, the U.S. Navy with the aid of Booz Allen Consulting (Booz Allen is now Booz Allen Hamilton) developed the Program Evaluation and Review Technique for the Polaris Weapon System program. The PERT method is capable of feats of estimation and schedule management that are utterly mind-bending, but it also requires far too many expensive resources to be useful for less challenging circumstances.

However, by extrapolating and simplifying certain assumptions, we were able to come up with a process we affectionately call "The PERT Kernel" (Exhibit 2). It is less powerful than the original method, but requires far fewer resources and is useful in most circumstances.

Our first assumption was that most people---project managers and team members included---do not maintain a command of, and love for, statistics. Therefore, we decided the approach had to be intuitive, bordering on simple.

Our second assumption was that some form of rationalized estimating was better than any form of irrational happenstance. Therefore, we decided a method for estimating the unknown with a basic, statistical foundation would experience more success than guessing. And, as an added advantage, it would have the ability to be improved over time as quantified experience became available.

Our third assumption was that since no better starting point was available, it made sense to believe unknown events would have the same characteristics as known events typically represented by a beta-distribution of outcomes. Then, as experience was gained, users could skew the normal distribution (i.e., a "bell curve") by adjusting the formula.

Our fourth assumption was that those customers (and management and most stakeholders) who would quickly challenge what is commonly referred to as a WAG estimate, would equally quickly accept what is commonly referred to as a SWAG estimate. (The definition, just in case you were wondering, of a WAG is "wild guess" and of a SWAG is "scientific wild guess.")

To apply the PERT Kernel, several definitions need to be understood, and a simple methodology needs to be followed.

Exhibit 2--The PERT Kernel

First, the terms in the equation are defined as:

1. LOE_emeans Level-of-Effort Estimate and is defined as the work required to finish specified project element, expressed in an agreed-upon unit-of-measure (i.e., hours, days, weeks, or months).
2. O_emeans Optimistic Estimate and is defined by the assumption of only minimal difficulties actually happening; it occurs or is expected to occur,figurativelyspeaking, approximately 3% of the time.
3. ML_emeans Most Likely Estimate and is defined by the assumption that the most common difficulties actually happen; it occurs or is expected to occur,theoreticallyspeaking, approximately 94% of the time.
4. P_emeans Pessimistic Estimate and is defined by the assumption of maximum difficulties actually happening; it occurs or is expected to occur,theoreticallyspeaking, approximately 3% of the time.

You'll notice that in each of the definitions the wordtheoreticallyis emphasized. That is because successfully applying the PERT Kernel hinges on properly explaining expectations to the estimator! It is, however, worth confirming that the suggested percentages are based on the common convention of statistics for events with a normal distribution (i.e., "bell curve) of outcomes.

It is incumbent on the project manager to make three things clear to the estimator. First, theactual durationof the elementisaccepted as unknown,and greater detail in decomposition is not possible. However, an estimate must be made nonetheless. Second, the reason for the estimate is that scheduling requires an estimate of duration, and the project is, in fact, in a better position with an estimate where the accuracy is commonly understood to be highly questionable than it is without one. Third, the task before the estimator is to try to quantify an expectation using afigurative--in other words, qualitative---number that hopefully represents some degree of reality.

The estimator's first task is to determine a pessimistic estimate of what might be expected as 3% of the outcomes on the negative side. The key is that the estimator must realize we donotwant a "one-in-a-million, struck-by-lightning" pessimism. What we do want is an "edge of reality, but reality nonetheless" kind of pessimism. The estimator's second task is to determine an optimistic estimate of what might be expected as 3% of the outcomes on the positive side. The key is that the estimator must realize we likewise donotwant a "one-in-a-million, winning-the-lottery" optimism. What we do want is an "edge of reality, but reality nonetheless" kind of optimism. The estimator's final task is to determine a most likely estimate of what might be expected as 94% of the outcomes on average. The key is that the estimator must realize we donotwant them to "just split the difference." What we do want is an "informed intuition" kind of average.

With these three estimates established, it is a simple matter of mathematics to apply the formula. We add the amount of the pessimistic estimate to four times the amount of the most likely estimate to the amount of the optimistic estimate and divide the sum by six. The result is the estimated duration for the unknown element.

Considering the nature of the result, it is clear that the foregoing is nothing more than the proverbial "educated guess." It is "educated" precisely because the decision to weight the Most Likely estimate four times more than either the Optimistic or Pessimistic estimates accesses the wisdom and credibility of statistics until reliable experience can be used to more appropriately guide the estimating process. So, as was already pointed out, using this method has several benefits. Foremost among these is that it demonstrates to any inquirer that a reasoned and reasonable approach has been used to formulate the estimate, which means it can be defended under review. It also is quite clear that as experience is gained, and lessons are learned and recorded from current results, the estimates for future unknown elements---and for future projects!---can be expected to improve, which benefits the organization both now and in the future. And finally, during project scheduling (which we develop in the next chapter), for high-profile or extremely important projects or subprojects, multiple scenarios can be scheduled using variants of the duration of the unknown element.

It is also worth noting that the formula for progress is a function of difficulty times work velocity [Progress =f(Difficulty * Work Velocity)]. This formula gives us the opportunity to greatly enhance the accuracy of estimates by creating repeatable exercises or tests that mimic aspects or facets of the unknown element and then using that information to establish parameters for our Optimistic, Pessimistic, and Most Likely estimates.

Creating Repeatable Successful Estimates

Having a process that repeatedly delivers successful estimates is the "holy grail" of project management. The normal steps involved in such a process are as follows:

Step 1: Prework

As explained earlier, the core team and project manager develop an appropriately detailed WBS. Then they obtain copies of marketing estimates, as well as any actual results and lessons learned from prior, similar projects that might be available.

Step 2: Create Initial Estimates

Next the Work Package Owner or Activity Owner, as the case may be, using the information gathered in prework, develops an estimate of the level-of-effort duration for each element. They hold discussions and meetings with subject matter experts and technical leads, as needed, to validate the initial estimate.

When estimating the level-of-effort required for any work package, activity or task, it is valuable to recognize that, as a discipline, estimating can be improved significantly over time. The most common cause of negative variances between estimates and actual work execution are problems that were not accurately factored for the probability and severity of their impact. Within a proper estimating process, time is taken to review lessons learned that were documented on other projects. The information in the lessons learned improves the estimate by increasing the accuracy with which problems are identified, as well as the quantification of the likelihood of occurrence and severity of their impact. That improvement is often called the "learning curve."

In order to benefit from the learning curve that naturally occurs in all estimating, each work package, activity or task must be decomposed in the WBS until one of two conditions exists. Either the element has reached a point of sufficient detail where an accurate estimate of its likely duration and expected problems is possible, or the limit of defining greater detail has been reached (i.e., irreducible complexity). When the structure of the detail has been increased to its maximum depth and an accurate estimate is still not possible, the realm of the unknown has been reached. In the next section we will cover how to cross that threshold and estimate the unknown.

Also to create learning curve it is important to have a structured estimating approach such as the following:

• Clearly and accurately name the work packages in the WBS.
• Decompose them into the deliverables-focused elements required to produce and manage them. The less experience the estimator has, and the less that is known about the item being estimated, the more detailed the elements should be to ensure reliability.
• Estimate the "level-of-effort" needed to complete the element in an agreed-upon unit-of-measure. Do not try to "factor" for interruptions, expected inefficiencies, or other environmental factors.
• Document constraints and potential risks as notes in the estimate. Identify triggering events for each risk if possible. For example, one note might be that the estimate assumes Susie Smith (who has 15 years' experience and two doctoral degrees) will do the design engineering, but if her current project runs past its scheduled completion date and a new hire is assigned to the project, there could be a threefold increase in the time required to complete the design.
• Document the elements included in, and excluded from, the estimate. For instance, one common oversight in software development projects is user documentation. The developer typically assumes none is included, whereas the customer typically assumes detailed user manuals are included. When the application is delivered, a dispute commonly occurs because neither party documented whether manuals were included or how much detail they would contain. Therefore, estimates should clearly define each element that is included and clearly identify each element that is not included.
• Validate time and resource estimates using the results of lessons learned that were documented on prior projects or other objective standards whenever available.
• Require the person who is responsible for delivering the work to provide, or commit to, the final estimate. This should be the same person who will report on the status of work progress during the work execution phase of the project. It may be the actual worker or a departmental manager, supervisor, or lead, who is part of the project team.

Step 3: Finalize Estimates

Finally, the team and project manager meet to review the estimated duration for each element. They then roll-up the estimates and compare them to any initial higher-level estimates. Using this technique, they refine and revise the estimates until the team agrees that the estimate reflects the most appropriate view of reality.