There are a large number of statements about estimating that are flawed from the start. From Dilbert's manager's use of estimates, to naive use of statistics, to suggesting the future can not be modeled, project's are too unstable, estimates are of no value, to my favorite, making estimates for our work takes away from doing our work. None of these notions and they are certainly notional (existing only in theory or as a suggestion or idea), has connected the dots between spending money to produce value and the need of those providing the money to know how much, when, and what.
Let's begin with what does a good estimating process need to look like
- A good estimating process produces good estimates for all the quantities we need without exceeding the resources allocated for the estimate. Estimating is a process just like designing code is a process, our developing a marketing campaign for the product we just release, is a processes. This means when you hear we can't spend more time on the estimate than the estimate is worth remember the speaker is restating the obvious.
- The primary requirement for the estimate is to provide a value for some quantity with a known and appropriate level of accuracy. All estimates by their nature have errors.
- The accuracy of an estimate depends on two things
- The inherent accuracy of the estimating technique or model
- The errors in the input parameters.
- To assess the amount of risk associated with a bad estimate. If we underestimate the effort needed to patch the SQL Server over the weekend, what is the cost of not being able to start the production server on Monday morning?
First A Bit About Ordinal and Cardinal Values in General
- Cardinal numbers describe how many- there were 8 rabbits in the garden this morning.
- Ordinal numbers describe position or relation - there were a lot more rabbits in the garden this morning than there were yesterday.
When we use Cardinal numbers, we can determine the relative relation of other numbers in our estimate. The effort to develop Function A is larger than Function B. But it doesn't tell us how long it will take to do either. Only after we know how to do one, we can tell the relative effort of the other.
If we know something about one of the Functions - that is we had a calibration of the estimates of that Function - we now have a Cardinal number. We estimate that Function A will take 16 days ±3 days and Function B is only ½ that effort, so we estimate Function B will take 8 days ±1½ days all things being the same. This last part is the source of most estimating errors. We make assumptions that turn out not to be true.
In our domain here are four root causes of program performance issues. Unrealistic cost and schedule estimates are in that list. But all four have at their root, estimating errors. Either risk, direct estimates, or expectations that were improperly estimated to be possible.
Measures are the Raw Material of Good Estimating
When we use uncalibrated numbers in our estimate, we can make decisions based on relative measures. I like Chocolate ice cream more than I like Vanilla. That's a decision based on an Ordinal measure. I estimate I can only play 9 holes of golf today, because it will take me 2 hours and I have to leave for a meeting in 3 hours with a 30 minute drive. These numbers are Cardinal.
So Why Do We Estimate? Let Me Count the Ways
Estimates are needed to make decisions in the presence of uncertainty. This is a fundamental principle of making choices in the presence of uncertainty. If it's Chocolate or Vanilla we don't have much uncertainty - unless we never tasted them before.
No matter how many times there it is conjectured decisions can be made without estimates. No matter how much this is repeated. No matter how desperately those making that conjecture want it to be true, it is simply not true when there is uncertainty about the future.
Since all project work is based on uncertainty (even production line work has uncertainty), the notion of making a decision without estimating the impact of that decision is mathematically impossible.
So why do we estimate? There are three simple answers:
- To control the project. Without a target to steer toward and an estimate of the time, cost, and probability of success of the efforts toward that target, we don't know if the target can be achieved. Once we're underway, new information is available to take corrective actions on the variances between planned progress and actual progress. This is the basis of Closed Loop control. Without a steering target, the estimated needed progress to reach the target as planned, measures of the actual progress to plan, the difference between planned and actual, and the corrective actions to get back on plan - we're going to be late, over budget and our gadget likely to not work.
- Have the business understand the potential cost, duration, and probability of success. It's not our money. We may hear statements about the waste of estimates, but it's not our money.
- Estimate future performance. If we're working on a project that has a duration beyond our ability to see all the work in detail, we need an estimate of how long, how much, and what can be done to produce the needed value for those paying for our work.
Estimates are measurement about the future
Any measurement is the resulting of applying a procedure. An operational definition puts communicable meaning into a concept - W. Edwards Deming
Estimates (measurements future outcomes) must address assumptions of scope, units of measure (Cardinal values), and conditions of the measures (estimate).
So if we want to understand something about the future in order to inform our decision making, we need to estimate - in some way - what are the possible outcomes we will see in the future and what happens if we pick one of those outcomes compared to another. This is the foundation of the Microeconomics of writing software for money. To attempt to make decisions in the absence of an estimate of the impact of that decision, ignores - likely with intent - the foundation of all business decision making
