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