It Takes Three to Make Good Estimates

Avoiding the pitfalls of traditional estimating

Some general thoughts

Most people hate estimating. But why?

You are running a project as the project manager. Or you are supervising project managers as a project sponsor or program manager. Or you are a customer of companies running projects for you.

Then you will probably know it: It is so hard to get somewhat reliable estimates.

You may be applying a bottom-up approach and ask team members or subcontractors: "How long is it going to take you?" or "How much will it cost?" and the answer will be "Uuhm ... humm ... can't really say ... I first have to see what needs to be done ... so much is uncertain ... I can tell you after I have started working on it ... or have it finished ...", and so on.

Once you got the estimates you find out, that your team member—coming fresh from the University—has estimated far too optimistic and without considering organizational and technical risks.

Or the experienced person gave you estimates with exaggerated private (and hidden) reserves on cost and time, and you learn that Parkinson's law still applies that work is going to fill the time which has been assigned to it. And it also applies to the budget. These conservative estimates slow down your project and make it more expensive.

But why is it so difficult to get good estimates? There is a number of reasons:

Estimates need interpretations

An estimate may be optimistic, pessimistic or realistic, whatever this may mean. An estimate may be communicated to achieve a target. An estimate may be made according to a lot of experience or be just a ballpark number assigned to something yet unknown. An estimate may be fairly reliable or extremely uncertain. And after all—it will always remain an estimate, a kind of assumption. Unless we have the actual numbers.

Do we always know what somebody really means when we are given an estimate?

Estimates get implicitly converted to commitments

The conversation is often similar to the following:

Later when it turns out that the 4 weeks have been too optimistic, the staff member may hear:

Is it surprising that when staff members make estimates, they include extended reserves.

There is a good rule in military: It is the officer who owns and manages the reserves.

Sometimes you may even hear the following:

Is it surprising that team only rarely report early finishes? And how well you could often use that amount of unneeded spare time, e.g. for quality inspections?

Estimates are too often subject to politics

Discussions like the following are not that rare in presales team meetings:

Instead of a sales person, there may also be a politician or another person who is interested in selling the project than in successfully finishing it.

Don't forget: Today's project is tomorrow's legacy.

Estimates can not be better than the requirements against which they have been made

Before you can estimate costs, effort or duration of an activity, you must really understand it. There must be a joint understanding by all stakeholders what the requirements are, something which is referred to as congruence.

Congruence is often a problem, you may have seen the following cartoon earlier, which nicely describes what then comes out*:

How the customer explained it	How the project manager understood it	How the architect designed it	How the programmer wrote it	How the sales person described it
How the project was documented	What was installed	What was billed	What support made with it	What the customer really needed
NB: (Is it really true that these cartoons are public domain or is there somewhere a copyright owner on them?)

The blinkered approach to estimates

Estimates are undergoing learning curves. The nearer the item comes, the better they will be. But many managers want to keep the learning curve out of their project, they hate the element of unpredictability. See the article on the Sunk Cost Dilemma.

Bad communications

Not all project managers understand the most elementary yardsticks in projects:

There may be many more yardsticks in your project. Make sure you understand terms like WBS, critical path, critical chain etc. If you have problems with them, consider reading a good book on project management or attend a training.

A common reason for bad estimates are mismatches between effort and duration because they have the same metric. Or mixing up effort and costs which are rolled up and drilled down the same way.

Budget problems come rarely isolated

Most budget overruns come together with at least one more problem like:

• Schedule overruns
• Technical problems
• Overwhelming organizational and technical complexity
• Low quality
• Bad communications
• Lack of transparency

Is there a solution?

Experienced and well educated project managers say yes: Three-point-estimation may prove helpful:

Manager:	Can you tell me how long it takes to get xyz done if everything goes really, really bad?
Staff member:	Yes, you know, sometimes things go really bad. Hard to say. If I think of all the problems...
Manager:	That's exactly what I am interested in.
Staff member:	...then I would estimate some 5 weeks, 25 working days are on the safe side.
Manager:	Very good. And now let's assume things go easy.
Staff member:	You mean: No difficulties at all?
Manager:	That's exactly what I mean.
Staff member:	It's not very likely. 2 weeks may then be reasonable.
Manager:	Maybe as likely as the pessimistic 5 weeks?
Staff member:	Yes, both are very unlikely.
Manager:	But not impossible.
Staff member:	No, unlikely, but not impossible.
Manager:	Fine. And what do you think is most likely?
Staff member:	Should of course be between those 10 and 25 working days. Maybe 13 days are realistic.

So we have our three points and can apply something described in a methodology called PERT: We calculate the weighted average as
(1*Opt. + 4*Ml. + 1*P) / 6:

The 15 days would be used for scheduling, but the other values are getting documented too.

PERT 3-Point estimations assumes a beta distributions similar to the following diagram:

Benefits of 3-point estimating.

• Estimates are on average app. 30% faster. According to Parkinson's Law, this will speed up the entire project.
• There are no un-interpreted estimates.
• The degree of uncertainty is documented
  (in the example: Pess. - Opt. = 25 - 10 days = 15 days).
• The manager knows for what degree of overruns she should prepared herself.
• It is clearly communicated and documented that the 14 days are not a commitment.
• It is less likely that the manager gets overpowered by the Sunk Cost Dilemma.
• You can apply statistical methods to calculate a path sigma, or a total cost sigma out of single estimates (do not worry if you do not know what this means; read until the end, and then review the template Pert Calculation Sheet to learn the maths from it).
• When you do repeated estimates over the course of the project and over an activity, uncertainties should naturally become smaller. If this doesn't happen, this is a signal that the estimating person doesn't gain confidence, which is an alarm that something may be on the way to go wrong, and you haven't been told yet.

The last point is especially interesting, because it is often very hard in a project to get a clear understanding of what is going on. The author recommends to use candle diagrams to visualize the development of uncertainties:

The meanings of the top and bottom ends and of the PERT line are described in the diagram above.

The left candle diagram shows a normal situation: Estimates may have to be adjusted over time, but the degree of uncertainty goes down. The candle burns down nicely. It kis like driving on a free road and getting nearer to the destination with good speed.

The right diagram shows a situation, in which the uncertainty does not go down over time. A very bad sign!

The psychology of estimators

There are 2 types of estimators:

Three point estimation in Insight Tree

Three point estimation can be applied to efforts, duration and costs. As Insight Tree deals only with monetary costs and benefits, we will focus on this dimension.

You have two options:

1. Calculate the 3-point PERT value in Insight Tree

Create a node, add another branch to the node, set the node type to Chance and then set the node type to numeric:

Assign the numbers for likeliness (1, 4, 1) and costs.

A simple template showing PERT three points in Insight Tree may be downloaded by clicking here:

2. Calculate the PERT number in Microsoft Excel and link from Insight Tree to that number.

Another option is to calculate costs (or benefits) according to PERT in Microsoft Excel. The benefit is that you have the PERT calculation on only one node and do not have to follow up three branches with further chances and decisions.

Linking to a named Microsoft Excel cell is described here and in Insight Tree help function.

An Excel template for 3-Point calculations of durations, work and costs can be downloaded here.