There is an endless number of reasons for why we should or shouldn't make estimates of our work. Some from credible sources, some from not so credible sources.
But let's start with a fundamental principle of all business, not matter the domain. If we expect to generate revenue or produce some measurable value from our work efforts, we need to measure those beneficial outcomes in some agreed upon units.
Dollars is one unit of measures common in the business world. If we work are a for profit company, it is likely the managers of the business use that unit when they discuss project work. If we work for the government, budget is used many times in place of cost, but cost - in dollars - is still in the equation. If we work for a non-profit or a not-for-profit budget and cost are half the equation. Intangible benefits the other half.
But it is unlikely any place we work, there is not some discussion of cost, budget, or expenses. So no matter what our personal opinion creating estimates of our work effort are, we can't escape the fundamentals of business.
We need to know the cost of something before we can assign a value
Let's look at some deep truths about estimating
- Estimating is actually easy - we do it ever day in our normal lives. there are numerous processes, case studies, examples of estimating in a variety of domains. We estimate how long it will take to drive to work. We estimate how much milk it will take to fill the pot ot make hot coco. We can play the 20 questions game almost any software project and get an answer within 15% in 5 questions or less.
- Applying estimates properly is actually hard - without hands on experience, successfully applying estimates, all the theoretical discussion of estimating is just that, theoretical.
- How To and How Not To Make Credible Estimates
- Cognitive Errors in Estimation: Does Anchoring Cause Overconfidence?
- Cognitive Limits in Software Cost Estimation
- Does Anchoring Cause Overconfidence Only in Experts?
- Overconfidence in Estimation
- Managing in the presence of uncertainty is mandatory - all variables on projects are random variances. Each of the random variables creates a variety of possible outcomes, which must be accounted for in the management processes.
- Short term, intermediate term, and long term estimating are very different animals - weekly, monthly, and longer terms outcomes must be accounted for.
- All project variables are random variables - worth stating again. If anyone asks for an estimate and is expected a definitive number, then they will be disappointed.
- The politics of estimating many times overwhelms common sense - this is a primary dysfunction of not only estimating but most project management activities.
- The mechanics of estimating is well defined - there are many process frameworks for estimating almost anything.
- The notion of you can't handle the truth is at the root of most management dysfunction - the fundamental political problem with estimates.
- The truth is out there (pardon to X-Files) - the actual cost of the project, with its probabilistic confidence intervals, it there for the finding.
So The Big Question?
- If we're not very good at estimating, does that mean we should just not estimate? Instead just start spending money until the customer tells us to stop? Probably not.
- Should we redefine estimating to mean we are working down a list of activities someone else as developed? and call that No Estimating? Maybe, but someone else is now responsible for developing the total all in estimate.
These issues are not unique to software development. They are found in every project domain. Public works, bio-pharma, energy, government contracting.
Estimating is hard, it's important, and needs to be addressed in much more detail, before being dismissed as simply something management wants.
