Range Estimates

Estimating Effort: Part 5

by Bill Duncan

piece-missing-empty In this last article of the series, I’ll cover a potpourri of other estimating topics including dealing with poorly defined work and what to do when management thinks it should cost less or take less time.

Dealing with Poorly Defined Work

In order to introduce the basic concepts of effort estimating, we limited our discussion to developing an estimate for a single, reasonably well-defined activity. Although this type of work may prevail in some project environments, most projects will have a significant amount of work to estimate that is not well-defined. In this section, I will cover some approaches to those situations.

No one on the team has experience with this kind of work. Here are some ideas that should help:

Find someone who does have experience, e.g., a consultant or someone in the organization who is not on your team.
Use a wider range estimate to reflect the greater uncertainty. Unless the unknown work represents a significant percentage of the total work, your overall project budget will not be greatly affected. Remember that we are willing to tolerate budget variances in individual work items as long as the project total is acceptable.
Break the work down into smaller units. Often, you will find that you do have experience with much of the work. The aspects that you don’t have experience with can be handled with a wider range estimate.
Develop some experience. It may be possible to have one or two team members do a couple of “practice” activities as part of the project planning process. I used this approach quite successfully as part of a database conversion project several years ago.

This is truly state-of-the-art stuff. See previous paragraph, especially the last bullet.

We really have no idea of what’s required or we don’t know enough at this point to define the work. Neither of these two complaints is an estimating issue; they are both either a scoping issue or a risk management issue. They might also be a defensive response to a skeptical manager. If so, see below.

Conflicting Estimates

Did you ever have two team members who differed widely in their opinions of the likely amount of effort required to complete a work item? Range estimates can help, particularly if the individuals involved are inherently optimistic or pessimistic — if their ranges overlap, it is usually much easier to reach agreement.

But the root cause of such difference is most likely to be the presence of conflicting assumptions. For example, a team member who assumes that previous design work can be reused will produce a lower estimate than one who does not. By surfacing the conflicting assumptions, the team can discuss the alternatives and decide what to do.

One particularly pervasive assumption is the skill level of the person doing the work. Estimating is often done by more senior staff, and they tend to think in terms of “how much effort would I personally have to expend to complete this work.” This is likely to produce an estimate that it too low. At the same time, they may become aware of their tendency to overestimate and overcompensate. I recommend that you remind your estimators to constantly assume an “average” resource, and to recognize that it will take 2-3 projects of comparing actuals to estimates for them to get good at knowing what “average” really is.

Converting Effort into Duration

I know that I am going to get a lot of flak from some of my colleagues about this next point. The technically correct answer about how to estimate duration is that you should do just that — look at the effort estimates and develop a three-point range estimate of the duration for each work item. For example, with an effort estimate of 30, 40, and 80 hours to be performed by a single individual working fulltime on the project, I think it is reasonable to predict that this person may need more than two full weeks to get this item done if it ends up requiring 80 hours of effort.

In addition, since virtually all network analysis techniques (Critical Path, Critical Chain, PERT, etc.) underestimate the most likely duration of the project, many would also argue that a Monte Carlo simulation is a necessity. And I would agree … if you’ve got the budget.

If not, take the easy way out — take the effort budget (the expected value of the effort estimate) and convert that into a single-point duration budget based on the availability of the individual assigned.

Maintaining Your Estimates

If the work of the project changes via an approved change order, you will need to estimate the new work and update your budget as well.

If any of the assumptions that went into your estimates are changed, you should also update your estimates. In this case, you may not be able to modify the budget, but you should still re-estimate the work. For example, if one of your most skilled staffers was supposed to work on Work-item D, and due to circumstance beyond your control D is being done by an intern from the local community college, you better reset everyone’s expectations about how long it is going to take.

Management Cuts It in Half

The first thing you have to do is find out why. Most such management actions are created by one of the following misunderstandings:

Your manager may not understand the difference between an estimate and a budget. Educate them. But in the nicest way possible if you want to keep your job.
Your manager may view your estimate as a negotiating position. Some managers assume that you have “padded” your estimate to provide negotiating room. Again, educate them — explain how the suggested cuts will either reduce quality or increase the risk of an overrun.
Your manager’s cuts may be a negotiating position. Most good managers understand that a more difficult task (where the target is aggressive) can serve to motivate the project team. But even good managers often fail to appreciate that an impossible task (where the target is so aggressive that it is clearly impossible) is a powerful demotivator.

Summary

Underestimating will drive you crazy. You will spend endless hours explaining why you are over budget and behind schedule. You will spend endless hours dealing with unhappy customers and stressed out team members. Overestimating may not be much better. Your projects will not get approved because they will be seen as too expensive. You may even lose your job if your padding is viewed as unethical.

Three-point estimates for effort may not get you into heaven, but they will make this life a lot more rewarding for everyone affected by your projects.

Estimating Effort

Previous in series

{ 0 comments }

Estimating Effort: Part 3

by Bill Duncan

Preparing Three-Point Range Estimates

The mechanics of preparing three-point range estimates, particularly if you are working with team members who have never used the technique before, are important. And just a reminder: we are still dealing with effort estimates; duration estimates come later.

Working one-on-one. Let’s again start with a simple case where you need an effort estimate from an individual team member regarding how much of their effort is likely to be required to complete a specific activity. The first step is to make certain that both of you have a common understanding of words like “estimate” and “complete.” For example, it is always tempting to say something like “how long do you think this will take?” This question is likely to produce a duration estimate rather than an effort estimate. Try to ask something like “how many hours of your time do you think this activity will take?”

Begin the discussion with a review of the work to be done to ensure that both you and your team member have a common understanding of the work. If there are unknowns, decide how to handle them—make assumptions, go get answers, whatever.

Once you have a reasonable level of agreement, ask the individual for their effort estimate of the most likely result. I tend to use words like “if these assumptions turn out to be true, how much of your time do you think this work is likely to take?” After they’ve answered that question, I ask “if every thing goes well, if you get very lucky with this activity, and still using the same assumptions, how much of your effort do you think this activity will take?” Then I use similar language to obtain a pessimistic effort estimate.

Remember to keep your assumptions constant. If you develop an optimistic estimate based on everything going well, and a pessimistic estimate based on nothing going well, the range of the estimates will be quite large. Very large ranges make most people uncomfortable because it appears that they don’t understand the work. In addition, it will be harder for you to assess the accuracy of the range estimate later because you’ll have to factor in all the different assumptions.

Understand that the first few conversations with any given individual are unlikely to go smoothly. They may generate additional questions or ask you to make additional assumptions at any point during the conversation. Fine. Let them. Help them climb the learning curve. My experience is that it takes most people 3-5 iterations to get comfortable with the process. After that, they’ll start giving you three-point estimates automatically.

Feel free to challenge their estimates, but do so constructively by asking clarifying questions. Do not cast aspersions on their estimates. If your estimate differs from theirs by a substantial amount, the most likely explanation is that your understanding of the work differs from theirs. Concentrate on identifying and resolving those differences.

It also seems to be important to start by asking for the most likely result, then the optimistic, and then the pessimistic. I don’t know why, but this sequence seems to work best.

Working with a group. Most of your estimates will not be developed one-on-one, but rather will be developed by small groups as part of a team planning process. The basic process remains the same for these small groups:

Review and agree on the work to be done.
Document the assumptions.
Develop three-point range estimates starting with the most likely result.

Even when some of the group members don’t have deep expertise in the project’s work, their presence can help to surface unstated assumptions and to build team-wide commitment to and understanding of the effort estimates.

Other approaches to three-point range estimates. Some project managers try to expedite the development of a three-point range estimate by asking for only two numbers—the most likely and some form of variance (e.g., “10 hours, plus or minus 2”). While this statement equates to a three-point range estimate of 8, 10, and 12, in my experience, it lacks the richness of my process—it doesn’t seem to generate the same degree of thoughtfulness from the estimator.

Will this take too much time?

I am convinced that the thinking process and the conversations that support three-point range estimating contribute to the development of more accurate estimates. Short-circuiting the process may appear to save time, but it’s a false economy.

My experience is that developing three-point estimates almost always takes less time than single-point estimates because the conversational process eliminates the posturing and gamesmanship that often delays the development of estimates. I’ve have had teams in my project management training courses spend less than an hour to develop an estimate for a 4,000 hour project — an estimate that later proved highly accurate. A recent client spent less than a day to discover that a mission-critical, multi-million dollar new product development project was going to be eight months late. An investment of something less than $10,000 is expected to return in excess of $10,000,000. Time spent estimating is not a cost, it is cheap insurance.

In the next article of this series, I’ll cover some of the more difficult challenges of estimating effort on projects: what to do when management thinks it should take fewer hours, using range estimates with project management software, how to deal with the natural (and normal) biases of the estimators, understanding the difference between accuracy and precision, and how to use some basic, simple statistical methods to create an estimate for the whole project.

Estimating Effort

Previous in series Next in series

{ 10 comments }

Estimating Effort: Part 2

by Bill Duncan December 17, 2008 Estimation

This is the second in a series of articles on estimating effort. In the first, I focused on definitions since I find that many people use terms such as estimate and budget as synonyms when, in fact, they are very different. Here is a brief recap of the key definitions that I will use: Estimate. [...]

Click to continue…