There is a popular - but seriously misinformed - notion that making estimates is the same as guessing.
It's not clear how this notion came about, since I haven't talked directly with those making statement like that. I'll have to estimate myself why this might be true.
One reason might be they haven't been exposed to the statistical processes used to make estimates in a variety of domains, not just project management. When we encounter the need for estimates, we need to come in contact with probability and statistics. All processes on projects are statistical in nature. This produces uncertainty and uncertainty results in probabilistic outcomes.
Estimating means searching in this probabilistic "space" for a number that is close enough to answer a question. How many people are in line for movie tickets inside? Should I buy my tickets at the kiosk outside? Or maybe, how long will it take me to drive from my office to the airport parking garage for my flight on Wednesday morning? These are not exact numbers, these ae quick estimates. The answer to the first question can be made with a quick look inside the theater. The second comes from the experience of driving to the airport several times a month over the past 20 years. One is informed by observeation of the current situation, one informed by past experience under a variety of situations.
Let's start with a simple definition of an estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
Making Simple Estimates
When we don't have the exact answer of some value, we can make an estimate of that value. The result is a number and a confidence on that value. Say we need an estimate of how long it will take to drive to the airport. It's 52 miles. Some on surface streets, some on open 2 lane roads, some on freeways. Knowing the speed limit for each of these segments can get us an approximate time portal-to-portal. We can improve the estimate, knowing the weather conditions and the traffic flow on the surface streets.
Let's look at five easy steps for making estimates (abstracted from The "Mother of All Guesses" - A User-Friendly Guide to Statistical Estimation, by Francois Melese and David Rose COPYRIGHT ARMED FORCES COMPTROLLER, 1998)
- Define the Problem - The objective is to make an estimate about the future value of something that's important.
- Identify the variable we want to estimate - money is a good variable for projects. So is time.
- Build a model - that reveals something about the relationships of other variables to the one we are estimating. What drives the cost? Just the passage of time multiplied by the number of people on the project? Maybe there are other factors? Complexity, external influences, the weather, the technology. Investigate these factors. Do some exploring of what might happen if one of these influencers were to impact our estimate. Collect some data about these from the past. Ask around to others in our business and technical community. What have they seen.
- Make an initial estimate - exactly wrong versus approximately right is good guidence. We want approximately right. This is an estimate. We don't work in accounting, we work in project management.
- Be careful - we can start to believe our estimates. This is called reference bias. It happens all the time. Our management can come to believe the estimates as well. This means we must not only produce a credible estimate, but must provide the confidence intervals for that estimate
Making Estimates for Project Work
With the steps above we can start to make estimates of our project work.
But first let's kill some myths used to not to make estimates.
We've heard them all and more. There is an endless list of reasons for not doing most anything on a project, but that doesn't remove our obligation to be stewards of other people's money we are spending with expectation (estimate) of some value in return.
Let's start with a core principle of all project work, and possibly a principle of all life's work when we encounter money.
We can't determine what something is worth until we know what it costs.
This is a crass capitalist point of view I know. But we live in a crass capitalist society and them's the rules. Don't like the rules, it might be better to look somewhere else for work other than spending other peoples money without knowing how much it will cost in the end and when we'll be done.
We all know and maybe even experience a Dilbert's paradigm when it comes to projects. But that doesn't make it right. We hear this some times from management. But we also hear it as an excuse for not making estimates from those who should be looking after the cost needed to compute the Return on Investment.
- Management doesn't listen to our estimates - this is an education problem. Maybe they weren't ever exposed to the concepts of probability and statistics.
- Management holds us to our estimate like it was an immutable truth - this is bad management, consider other issues beyond this in our future employment.
- We have to make up numbers because management wants on estimate without any backup data - they may be under pressures we have no knowledge of. It's even more important to produce a credible estimate with credible error bands.
- Management wants us to estimate things we don't understand - then tell them that and get funding to go find the basis of estimate information
- Management can't handle the truth - well now we're onto the real problem. That's the problem many times in our domain. Major systems would never be funded if the total cost were know up front. James Webb Space Telescope, Joint Strike Fighter, DDG-1000
A Few More Myths
- Breaking down work from some larger set of work - whatever that is - into small pieces of work is always good project management practice. But it doesn't result in an Estimate At Completion unless we know something about all the work needed to complete the project. It just makes estimating the current work easier. Little's Law describes how this same sized work flows through a development system. But Little's make a critical assumption - the arrival of work does not exceed the departure of work. This means if we don't know what done looks like for the arriving work, we won't know what done looks like for the departing work. All we'll know is when we'll be done with the work in the queue.
- No one knows what done looks like, because the customer doesn't either, is a bigger issue than estimating can solve. If we don't know what done looks like in units of measure meaningful to the decision makers, (estimating is all about making decision in the presence of uncertainty) there are much bigger problems with the project.
- Not knowing how to estimate is not the same as choosing not to estimate for no good reason other than management is misbehaving.
- We may work on projects that really don't need estimates. They ae self contained, relatively small - this is a loaded word since small to some is large to others. But answer the question what is the value at risk? If the money can be lost when the project doesn't work - tution costs - then maybe making an estimate of the total time and cost has little value. We actually don't get to decide that though, those with the money do.
Below are some links to other Blogs on this topic, explore, think about our role in managing other peoples money.
