effort

Estimating Effort: Part 3

by Bill Duncan

translucent-pieces

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.

{ 10 comments }

Estimating Effort: Part 1

by Bill Duncan

This series of articles is extracted from a similar series I wrote for Projects@Work a couple of years ago. I’m posting it here in reaction to my review of Josh’s articles on Earned Value where he (in my opinion) used the term “estimate” when he should have said  ”budget.” Many of the terms related to estimating are used either inconsistently or imprecisely. Future items will address some “how tos,” but first, let’s take a minute to establish some common terminology.

Estimate. An estimate is 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. For example, if I tell you that there are two people standing outside the door, that one is male and the other female, and that one is 6’ 6” (200 cm) tall and the other is 5’ 2” (158 cm) tall, which would you guess is the female?

Most people will predict that the tall person is male. Most people will make an informed assessment of this uncertain event based on their knowledge that men tend to be taller than women, that few women are as tall a 6’ 6”, and that few men are as short as 5’ 2”. But what if I said the woman was a professional basketball player and the man was a jockey? Most people will now predict that the tall person is female.

Guess. A guess is a special kind of estimate—one where we do not have enough information to make an informed assessment. Note that in the above examples I used predict rather than guess since you do have enough information to make an informed assessment. For example, if I asked you to predict which person outside the door was taller, the person on the right or the one on the left, you would be forced to guess. In my experience, it is rarely necessary to make a true guess when working on a project.

Effort. Effort is an expenditure of physical or mental effort on the part of a project team member. We almost always measure effort in terms of staff hours. In many application areas (IT, NPD, pharma, consulting, architecture), most project estimates will be effort estimates. If you purchase resources from outside your organization, you may not see the effort estimates that were used to develop the cost estimates, but they’re there somewhere.

Cost. Cost is a measure of resource usage—employees and contractors must be paid, equipment must be bought or rented, and so on. Cost is usually expressed in monetary terms (dollars, euros, renminbi, etc.), but it can also be expressed in terms of hours of effort. One advantage of using monetary units instead of effort hours is that it should make comparisons between projects or among activities on the same project easier.

Another advantage of using monetary units to express cost is that the financial people in your company understand the language of money. One disadvantage is that monetary units can distort the numbers if the hourly rates are not reasonable. For example, if you use a rate of $100 per hour for an employee making $50,000 per year, and the same rate for someone making $150,000 per year, your cost estimates will misrepresent the actual cost of any project that has a preponderance of effort from one or the other.

Price. A price is what you charge someone for something. Prices are always (well, almost always) expressed in monetary units. Prices can reflect rates (e.g., $100 per hour) or totals ($500,000 for the entire project). Pricing is a business decision. It is usually derived from the estimate, but the estimate is not the price—if we are selling products or services to someone, we can charge more or less than our estimated costs. Even if we know for certain what the costs are or will be, we can still charge a different price.

For this series of articles, I’m going to assume that most readers are either managing internal projects or developing estimates in order to support a pricing decision that will be made by someone else (as is often the case for project managers working for a consulting firm). As a result, I am not going to cover pricing past the point of defining it.

Budget. A budget is a management control or metric (I prefer the term metric since control has negative connotations to some). A budget is a type of plan. Most people use the term only with regard to monetary metrics, but you can have effort budgets or schedule budgets as well. Project budgets should be derived from the project estimates.

Project budgets are not absolutes! Or at least they shouldn’t be. If a project is budgeted for $1,000,000, all of the stakeholders should understand that that number is a target. It is what the team expects to spend based upon what it knows today. If the team can find a way to spend less and still deliver the full scope, it should do that. If it needs to spend more, that should generate a discussion with the funders to decide what to do.

The project budget is not the same as the project price, even for a project done under contract. The seller can price the work for an amount that is different from its internal management metric.

Baseline. A baseline is very nearly a synonym for budget. There are two subtle differences. First, project baselines are normally time-phased. While I might say that the budget for my project is $500,000, I wouldn’t really have a baseline unless I had also defined when I expected to spend that money—how much in week 1, week 2, and so on. Second, the term baseline implies some level of formal approval. I can prepare a budget for an activity or a project, but it isn’t really a baseline until the relevant stakeholder(s) have agreed to it.

{ 32 comments }