Tag Archives: estimating

Implementing SCRUM…the basics – part 2

implementing scrum part 2

via Flickr by drewgstephens

In this post, I explained that SCRUM is not a silver bullet and?that there some significant barriers to entry for organizations wanting to adopt SCRUM. In this post, I’m going to introduce Agile estimating, planning poker, fibonacci, and velocity.

Let’s say that your organization is ready to go, you’ve turned command and control on it’s ear, you’ve identified the Product Owner and you’re going to be the ScrumMaster. You’ve put together a team of seasoned developers, a creative designer, and a QA Lead, but the designer and QA Lead have never worked on an Agile project and they also have never worked with this team of developers.

Let’s say that the Product Owner has put together a pretty comprehensive list of User Stories [let’s say that for argument sake that these have been validated and prioritized and you have verified that they follow the INVEST principles…more on that in another blog post]. What now?

First, you need to work with the “Team” to make sure that they understand what their responsibilities are, this includes the talk about being a self-organizing team, that they’re responsible to one another, the?Product Owner,?and ultimately to the organization to do what they say they’re going to do.

The next step is for the SCRUM Team [that’s the development team, the Product Owner, and the ScrumMaster] to decide which items in the Product Backlog you’re going to deliver in the upcoming Sprint. In order to accomplish this, you need to be able to quantify how much time or effort each item on the Product Backlog will require.

This quantification of the Product Backlog is called estimation and is commonly accomplished?by having the development team play a game called Planning Poker.

Game playing? Man this SCRUM stuff is wierd. OK, let’s talk about Planning Poker.

The idea behind User Stories is to collect the requirements in bite-sized pieces. The size of those bites will inevitably vary. The Agile solution to this problem is to rate each User Story according to relative “size”.

The best analogy I’ve heard is to compare the stories to dog breed…compared to the other stories, if the current User Story a Toy?Chihuahua or a Great Dane? Where in the middle…Jack Russel Terrier? Labrador Retriever? Once each person?has an idea for the relative “size” of the item, each person has to play their hand, and the group consensus wins…highest and lowest have to explain why they think the feature is larger or smaller than the rest of the team.

When?I do this, as the ScrumMaster, I intentionally don’t play a hand because I don’t think I should influence the team’s collective insight into how big or small a feature is. To each their own. The planning poker deck we use was purchased from Mountain Goat Software and was well worth the few bucks it cost. There are online versions and of course with a pair of scissors, some index cards, some markers, and a little free time you can make your own.? The important part is that you understand the notion of the relative scale of accuracy and the variability that is introduced as a feature gets larger.

You’re probably familiar with the Fibonacci series of numbers. We use this series of numbers to incrementally scale the “size” of a feature. Why do this at all you ask? Well, if I ask you to estimate in inches, the distance from the tip of your index finger, where it currently is, to the tip of your nose, you will probably be able to estimate with?better than 85% accuracy. Now if I ask you to estimate using the same criteria the distance from the tip of your index finger to the middle of the letter “O” on the nearest Stop Sign [depending where you are right now] you might be able to estimate with a significantly smaller degree of accuracy, and finally if I ask you to estimate, in inches, the number of inches from the tip of your index finger to the tip of the Empire State Building in New York City, you are likely to have an accuracy approaching 0%.

With this in mind, we use the Fibonacci sequence because as a feature increases in size, our inherent ability to accurately estimate it’s size diminishes. After all of the items on the backlog are estimated, the next step is to determine the Sprint Backlog…the estimated subset of product features that will be addressed in the Sprint. We had a hard time understanding how much we could bite off in our first few sprints [in other works, how many “story points”…or Fibonacci values we could consistently complete in a sprint].

In order to get around this, we took two decisive steps.

First we committed to?micro (one week) sprints and second we intentionally rigged the sprint backlog with items that we knew were small enough to complete in a week, yet big enough to validate [one way or another] our estimates. This process allows us to determine our “velocity”. Velocity is the average rate at which a team can complete story points for a unit of time. Once we were able to determine out weekly velocity, we were able to extrapolate our bi-weekly velocity.

Once we were able to determine the velocity for a “normal” sprint, we have become increasingly confident in our ability to deliver on that velocity. I will put in a big caveat…the velocity statistic is only a general guide, and as you adopt SCRUM, the accuracy of the velocity is only as good as your ability to limit the variability of external change within the team. In other words, if you determine the velocity for a specific team, that velocity will be affected by making changes to the team, and even in some cases by changes that the team may make from within.

For more information on these topics, there is a great book on this topic written by Mike Cohn called “Agile Estimating & Planning“. I highly recommend it.

Estimating Effort: Part 5

piece-missing-emptyIn 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: Part 4

four-pieces-apart1This 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).

range-tableAnd 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.

Estimating Effort: Part 3

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.

Estimating Effort: Part 2

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

Estimating Effort: Part 1

This series of articles is extracted from a similar series I wrote for [email protected] 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.