Project Team Member

Estimating Effort: Part 2

by Bill Duncan

3d-pieces1

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. An informed assessment of an uncertain event. Informed means that you have an identified basis for the estimate. Uncertain recognizes that different 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 uses the effort estimate as one of the key inputs.

Baseline. A time-phased budget that has received all necessary approvals.

What are you estimating??Let?s start with a fairly simple example to build a conceptual foundation.?It may seem obvious, but the first requirement for developing an estimate is to know what you are estimating. For now, let?s assume that you have been asked to estimate how much effort (how much of your time) is likely to be required to paint your bedroom. Although this is a fairly small activity, it is still one with a significant amount of uncertainty:

  • Do you have to paint the ceiling and the woodwork, or just the walls?
  • Are there windows to be painted? Do they have mullions?
  • Is there furniture in the room? Can it be moved? If it can be moved, is moving it out and back in part of ?painting the room??
  • Is choosing the color part of this activity? What about going to the store to buy the paint?
  • How many coats are needed? Is there any special finishing involved (like marbleizing)?
  • Will anyone be helping you? Or will you be doing all of the work yourself?

If you don?t know the answers to these questions, you have a couple of choices:

  • You can decline to prepare an estimate at all.
  • You can prepare an estimate that allows for a large amount of uncertainty.
  • You can make some assumptions about the answers to these questions and estimate based on those assumptions.
  • You can try to reduce the uncertainty by getting answers to the questions before preparing an estimate.

Any of these approaches is acceptable as long as your stakeholders know which approach you are using!?Most of the time, you will use some combination of approaches. You will make some reasonable assumptions (and you will always document all of your assumptions!). You will ask some questions. Then you will apply your best judgment.

Range estimates.?You can improve the usefulness of your effort estimates by making range estimates. How does a range estimate work? In its simplest form, you estimate a low value and a high value for the amount of effort that you think you are likely to need. For example, in the case of painting your bedroom, and assuming that the work is limited to applying paint to the walls, you might estimate 2-3 hours.

The fundamental concept behind range estimating is that you don?t need to know the exact amount of effort that will be required. You do need to know that it isn?t going to take a full day out of your schedule. You do need to know that this isn?t a trivial activity that can be completed in a few minutes. As long as the actual result is somewhere between 2 and 3 hours, you have made a good estimate.

Even if the actual result falls outside of that range, you still made a good estimate since it was the best estimate that you could make given what you knew at the time. In addition, you can learn from any?variance (an actual result that falls outside the predicted range) and use that information to try to improve your future estimates.

Using range estimates takes much of the pain out of the estimating process. If you are accustomed to single point estimates, it can be very difficult to choose between 2 hours and 3 hours. Even proposing a single-point estimate of 2.5 hours can be difficult because you know that it might take more or less than that amount. Using range estimates allows you to estimate even in the face of uncertainty.?If your boss insists on a single point estimate, he or she is most likely looking for a budget, not an estimate. There?s no problem with giving them a single number as a budget, but you really should share your estimate with them as well so that they will understand how much or how little uncertainty is involved.

Three-point range estimates.?You can improve the?usefulness?of your effort estimates still further by making three-point range estimates. In addition to the high and low values of a simple range estimate, you add an assessment of the most likely in-between result.

Let?s say, for example, that you are living in the world of Groundhog Day such that you can paint your room 100 times and keep records of how much effort it actually took. You discover that you never spent less than 2 hours and never more than 5. You also discover that your actual results produce a triangular distribution with a peak at 3 hours as shown below:

range-for-pmstudent

Based on the availability of this actual, historical information, you would estimate the amount of effort required to paint a similarly sized bedroom as follows:

  • Most likely: 3 hours
  • Optimistic: 2 hours
  • Pessimistic: 5 hours

I understand that you will seldom if ever have such wonderful, perfect historical information to base your estimates on, but the great thing about range estimating is that you don?t need perfect data! As long as the three-point range estimate is reasonable, errors in the effort estimates for individual activities are likely to balance out over the course of the project.

Even in this case, even with perfect data, you still don?t know how exactly how much effort will be required for the next bedroom that you paint. It might be 2.5 hours; it might be 3.75 hours. Doesn?t matter. What is important is that you have effort estimates that are reasonable; that you have effort estimates that will allow you to manage your project more effectively.

Next: preparing three-point range estimates

{ 5 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 }

The Need for a New Knowledge Area

by Josh November 2, 2008 Risk

So I’m doing some PMP sample test questions today and ran into one where at the end, additional things were added and the customer is very happy. According to the answer, this project was unsuccessful because the additional features were “gold plating” which wastes time and probably cost. I got this wrong because I read “the project has added [this and that]” as the [this and that] = intended product of the project.

But there’s a deeper insight here.

Click to continue…