This is the penultimate article in a series of five on effort estimating. In the first, I focused on definitions since many people use terms such as estimate and budget as synonyms when, in fact, they are very different. Here is a brief recap of some key definitions:

Estimate. An informed assessment of an uncertain event. Informed means that you have an identified basis for the estimate. Uncertain recognizes that multiple outcomes are possible.

Effort. Effort is an expenditure of physical or mental effort on the part of a project team member. Effort is normally measured in terms of staff hours.

Budget. A management metric that is derived from the estimate of the relevant work.

In an earlier article, I introduced the idea of three-point range estimates and covered the mechanics of how prepare them with your team. I ended that article by asserting that three-point estimates usually take less time to prepare than traditional single-point estimates.

In this article, I?ll cover the key outcome of estimating and converting effort estimates into budgets.

Key Outcome of Estimating

When I teach people how to estimate, I emphasize that the most important outcome of the estimating process is a project budget that is accurate, i.e., one where the actual results fall within an acceptable range of the budget. Acceptable budget accuracy will vary based upon the project :

• In New Product Development (NPD), it is often acceptable for the final cost of the project to be 3-4 times the initial estimates.
• In Information Technology (IT), ?10% is a reasonable target if the requirements are known, agreed, and stable, while the NPD range of +300-400% may also be perfectly acceptable if the project is mission-critical.
• For a fixed price consulting engagement, management may be reluctant to accept any overrun.

I argue that an estimate is accurate if (a) the actual results for most work items fall within the estimate?s range most of the time, and (b) the sum of the actual results is close to the sum of the expected values of the range estimate. In brief, we care most about the total. We care about the individual results only as a means to an end.

Let me illustrate. Let?s say that we have a project with 100 activities. To keep it simple, let?s ignore scheduling concerns for the time being, and let?s further assume that each work item has a three-point range estimate of 20, 25, and 30 hours of effort. The budget for each individual activity will be 25 hours (more on that later), and thus the budget for the project will be 2,500 hours.

If this project goes according to plan, most of the activities, probably around 70% of them, will be completed for an actual cost within an hour or two of their budgeted effort. One or two may take as many as 30 hours; one or two may take only 20. But the project total is likely to be very close to 2,500. Statistically, we have about a 95% probability that the project will finish within a range of ?50 hours. Not bad!

Now let?s take another project with 100 activities, only for this project, each activity has a range estimate of 10, 25, and 40 hours of effort. We will still budget this project for 2,500 hours, but ?50 hours has only about a 60% chance. If we want 95% accuracy, we need to go to ?120 hours.

Three-point range estimates help to support our goal of accuracy by encouraging everyone on the team to spend as much time and effort as they need to finish the work item correctly, and only the time and effort that they need. We avoid a lot of dysfunctional behavior:

• Team members may use the full budget even if they don?t need it.
• Team members may cut corners to avoid exceeding the budget.
• Managers at all levels of the project may waste time explaining minor variances.
• Managers may be tempted to manipulate the reported actuals in order to make the estimates appear ?better.?

And one more point: there are some circumstances when a single-point estimate is okay. For example, we can safely predict that a one hour team meeting that includes seven people will require seven hours of effort. Is there some chance that only six people will show up? That it will take an hour-and-a-half? Sure, but this is likely to be such a small source of error that we can usually ignore it.

Converting Estimates into Budgets

While an estimate is a range; a budget is a single number. An estimate expresses an opinion about the possible outcomes; a budget expresses a judgment about how much risk is acceptable. For example, if you expect a trip to the airport to take 40-60 minutes, you may budget 70 minutes if you are picking up your boss (close to zero chance of being late) and 40 minutes if you are picking up your spouse (he or she can wait!).

We can use some simple statistical techniques to convert our ranges into budget numbers. For this article, I?m going to ignore other budget preparation issues like unstable requirements and pre-defined budget maximums since these are more properly addressed through project risk management than through estimating.

The formulas for adding up ranges can be found in any basic statistics text. If you are willing to accept my suggestion that a triangular distribution is a good assumption, the basic process is straightforward:

• Develop range estimates (low, likely, high) for each detail item in your project plan.
• Calculate the expected value for each item by summing the three numbers and dividing by three.
• Total the expected values. This is your base budget (i.e., it does not include any reserves or contingencies).

And yes, it is just that simple. To the left is a worked example for a small project with two deliverables and seven activities that produces a base budget of 290 hours:

Many of you are probably also familiar with the formula for the expected value that is used in the Program Evaluation and Review Technique (PERT). The PERT formula is different because PERT assumes a beta distribution. I prefer to assume a triangular distribution because it produces more conservative results (a higher budget base) than a beta. Either assumption will work.