In classic economics, a price represents an equilibrium between supply and demand or value and scarcity. This suggests that there should be a close relationship between the estimate and the price. However, the difference between pricing and an estimate is the pricing strategy. Over the long term in commercial organizations the price must be equivalent to estimate plus a planned margin. In the short run for any specific account the relationship can be significantly more variable and nuanced. Pricing strategies work because IT sourcing markets are not perfect markets.

The classic equilibrium theory assumes absolutely free markets without barriers. Software development, operations or other IT staffing scenarios typically have several market imperfections (this is most true in the short run), which make pricing strategies effective. For example, a price to win strategy might be to price the work using lower margin (or negative) in order to get into an account, with price escalation in the longer term to get back to a planned margin. You can see this strategy in your local grocery store where prices are marked down to entice switching or stockpiling (stockpiling is useful to resist competitive pressures).

An estimate describes what sourcer thinks will be required to deliver the work, and therefore is an absolute based on what is known (and many times what is not known). The estimate is a step to a price, but only a step. The most basic formula would be:

 Price = Estimate * Planned Margin

The margin is a function of the pricing strategy. The equation could be enhanced (or complicated) by adding timeframes. In this model the estimate, unless new information is encountered (e.g. scope change, different resource costs, inaccuracies or process improvements), is a constant. That means that if the organization wants to change the price, they will need to change the expected margin or find other efficiencies. What should not happen is that a price change results in a command to change the estimate without some substantive rational.

In internal organizations, the relationship between an estimate and what is charged (charged back or applied to budget) is typically the same with the possible exception of an allocation of overhead. There is little need for an internal pricing strategy, as internal IT organizations are typically run as cost centers rather than as a business. In later articles we can discuss both the positive and mostly negative outcomes of this behavior.

In commercial IT (application development, support and operations), the price that ends up being charged or in the contract should be related to the estimate.  Related as modified by the pricing strategy being used to capture the business. Where there are market imperfections, such as high barriers to switching, that difference between the estimate and price is tilted toward the sourcer. Estimates are an input to the price, but only that – an input.

Fantasies are as ethereal as a cloud.

Fantasies are as ethereal as a cloud.

There are a number of fantasies about estimation that non-IT people and even some experienced software development professionals have. They are that 1) estimates are like retail prices, a predictable fixed price, 2) estimates can always be negotiated to a smaller number with impunity, and 3) in order to be accurate estimates must be precise. The belief in any of these fantasy fallacies will have negative.

The first fantasy is that is that custom projects can be priced like a cup of coffee. We fall prey to these fantasies because we are human and we want software projects to be as predictable as buying that cup of coffee.  When you go to most coffee shops, whether in North America, South America, Europe or India to buy a cup of coffee, the price is posted above the register.  In my local Starbucks I can get a cup of coffee for a few dollars, I just read the menu and pay the amount. The same is true for buying an app on my iPhone or a software package. Software project estimates are built on imperfect information that ranges from partial requirements to evolving technologies and, worse yet, include the interaction of people and the chaos that portends.  From a purely mathematical perspective these imperfections mean that the actual effort, cost and duration of the project will be variable.  How variable is influenced by the process used, the amount of learning that is required to deliver the project and the number of people involved. These are just a few critical factors that drive project performance. This variability in knowledge is why mature estimation organizations almost always express an estimate either as a range or as a probability, and why some organizations suggest that estimation is impossible. Agile projects re-estimate every sprint based on the feedback from the previous sprint using the concept of velocity.  Many waterfall projects re-estimate at the beginning of every new phase so that the current estimate utilizes the information the team has learned through experience.  Even when a fixed price is offered, the organization agreeing to a fixed price will have done an analysis to determine whether they can deliver for that price and what the probability is that the project will really cost (with a profit). This would be the process followed for any project to say they were x% confident of an estimate. When projects run short on time, resources or money and they can’t beg for more, they will begin to make compromises ranging from cutting corners (we don’t need to test that) to jettisoning scope (lets push that feature to phase two).  Many of these decisions will be made quickly and without enough thought, which will hurt IT’s reputation and increase project risk.

A second classic fantasy is that you can always brow beat the team into making the estimate smaller.  This fantasy can be true.  A good negotiator will leverage at least two physiological traits to whittle away at an estimate.  The first trait is the natural optimism of IT personnel, which we discussed in Software Project Estimation: Types of Estimates.  The problem is that negotiating the estimate downward (rather than negotiating over scope or resources) can lead to padding of estimates or to technical debt driven by pressure on profit margin or on career prospects. Estimators that know they are going to be pushed to reduce any estimate regardless of how well it is built will sometimes cheat and pad the estimate. So, when they are pushed to cut they can do so without hurting the project. This behavior is only a short term fix.  Sooner or later (and usually sooner) sponsors and managers figure out the tactic (perhaps because they used it themselves) and begin demanding even deeper cuts.  The classic estimation joke is that every first estimate should be cut in half and then sent back to be re-estimated.  A second side effect of this fantasy is that when the estimate is compressed and the requirements are not reduced, the probability of the team needing to cut corners increases.  Cutting corners can result in technical debt or just plan mistakes.  In extreme circumstances, teams will take big gambles on solutions in an attempt to be on budget.

A third fantasy is that precision equals accuracy. Precision is defined as exactness.  A precise estimate for a project might be that a project will cost $28,944 USD and require 432 hours, will take 43 days beginning January 1st and completing February 12th. Whether the estimate is accurate, defined as close to actual performance, is unknown.  This is precision bias, a form of cogitative bias, in which precision and accuracy are conflated.  In most cases in precision bias occurs the high precision infers higher accuracy.  The level of precision gives the impression that it is highly accurate.  The probability of a highly precise estimate being accurate is nearly zero, however add few decimal places and see how much more easily it is to be believed. As we have noted before, wrong budgets and/or estimates will increase the risk of project failure.

When I teach estimation I usually begin with the statement that all estimates are wrong.  This is done for theatrical effect, however it is perfectly true.  Any estimate that is a single, precise number that has gone through several negotiations (read that as revised down) is nearly always wrong. However, if when we jettison the false veneer of precision, integrate uncertainty and stop randomly padding estimates, we can construct a much more accurate prediction of how a project will perform.  Always remember that an estimate is a prediction, not a price.

Do I budget, estimate or plan the number of crawfish I am going to eat?

Do I budget, estimate or plan the number of crawfish I am going to eat?

Software project estimation is a conflation of three related but different concepts. The three concepts are budgeting, estimation and planning.  These are typical in a normal commercial organization, however these concepts might be called different things depending your business model.  For example, organizations that sell software services typically develop sales bids instead of budgets.  The budget to estimate to plan evolution really follows the path a project team takes as they lean about the project.

Budgeting is the first step.  You usually build a budget at the point that you know the least amount about the project. Looking back on my corporate career, I can’t tell how many late nights were spent in November conceptualizing projects with my clients so that we could build a budget for the following year.  The figures we came up with were (at best) based on an analogy to a similar project.  Even more intriguing was that accounting expects you to submit a single number for each project (if you threw in decimal points they were more apt to believe the number).  Budget figures are generated when we know the least, which means we are at the widest point of the cone of uncertainty.  A term that is sometimes used instead of a budget is rough order of magnitude.

The second stop on the estimation journey generally occurs as the project is considered or staged in the overall project portfolio.  An estimate generally provides a more finite approximation of cost, effort and duration based on deeper knowledge. There is a wide range of techniques for generating an estimate, ranging from analogies to parametric estimation (a process based on quantitative inputs, expected behaviors and past performance).  The method you use depends on the organization’s culture and the amount of available information.  Mature estimation organizations almost always express an estimate either as a range or as a probability.  Estimates can be generated iteratively as you gather new information and experience.

The final stop in the decomposition of the from the budget to the estimate is the plan. A plan is the work breakdown structure for the project (generally with task estimates and resources assigned) or a task list. In order to create a plan you must have a fairly precise understanding what you are building and how you are going to build it.  Good planning can only occur when a team is in thinnest part of the cone of uncertainty. Or, in other words, where you have significant knowledge and information about what you are planning.  Immature organizations often build a plan for a project, sum the effort and the cost and then call the total an estimate (this is called bottom-up estimating) which mean they must pretend to know more than the really can. More mature organizations plan iteratively up to a short-term planning horizon (in Agile that would be the duration of a sprint) and then estimate (top-down) for periods outside the short term planning window.

Short Descriptions:

  • Budgeting: Defines how much we have to spend and influences scope.   A budget is generally a single number that ignores the cone of uncertainty.
  • Estimating: Defines an approximation of one or more of the basic attributes that define the size of the project. The attributes include of cost, effort, duration. An estimate is generally given as a range based on where the project is the cone of uncertainty.
  • Planning: Builds the task list or the work breakdown so that resources can be planned and organized. Planning occurs at the narrowest part of the cone of uncertainty.

Estimating means many things to many people.  In order to understand the process and why some form of estimation will always be required in any organization, we need unpack the term and consider each of the component parts.  Each step along the continuum from budgeting to planning provides different information and requires different levels of information ranging from the classic back of the napkin concept (budget) to a task list generated in a sprint planning session (plan).  Having one does not replace the need for the other.