If you work in a domain, as I do, the need to answer the question when will we providing that needed capability to produce the planned value for the planned amount of money, then estimating is going to be part of answering those questions.
If you work where those paying for the work have little or no interest in asking these questions or knowing these answers, or have confidence you'll not overrun the cost, schedule, and deliver the needed capabilities as planned, then maybe estimates are needed.
Be interesting to hear from those actually paying for those outcomes to see what they need to make decisions in the presence of uncertainty.
Here's some more guidance for getting started with estimating software efforts.
- Optimizing Software Estimation Models
- Optimizing Software Effort Estimation Models Using Firefly Algorithm
- A Survey of Software Test Estimation Techniques
- An Efficient Approach for Agile Web Based Project Estimation: AgileMOW
- Software Development Project Risk Management: A New Conceptual Framework
- Models for Improving Software System Size Estimates during Development
- Estimating Software-Intensive Systems: Projects, Products, and Processes
- Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective
- How to Measure Anything: Finding Value of Intangibles in Business
- The Flaw of Averages
- Hard Facts, Dangerous Half-Truthsm and Total Nonsense: Profiting from Evidence Based Management
- Guesstimation: Solving the World's Problems on the Back of a Cocktail Napkin
- Mathematics and Plausible Reasoning, Volume 1: Induction and Analogy in Mathematics
- The Art of Insight in Science and Engineering
- Street-Fighting Mathematics: The Art of Educated Guessing and Opportunistic Problem Solving
- Estimating Software Costs: Bring Realism to Estimating
- A Causal Model for Software Estimating Error, IEEE Transactions on Software Engineering
- An empirical examination of a mediated model of strategic information systems planning success
- Software Estimation Best Practices, Tools & Techniques: A Complete Guide for Software Project Estimators
- An alternative method for determining adjusted function points as the basis for software cost estimating
- Software cost estimating: craft or witchcraft
- Software Estimation Best Practices, Tools & Techniques: A Complete Guide for Software Project EstimatorsThe Cost of Developing Large-Scale Software
- An empirical validation of software cost estimation models
- Practical Software Project Estimation: A Toolkit for Estimating Software Development Effort and Duration
- Agile Estimating and Planning
- Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams
- Software Project Estimation: The Fundamentals for Providing High Quality Information to Decision Makers
- Demystifying Story Points: A Simple Way to Understand Story Points in Agile
- Software Project Estimation Foundations and Best Practice Guidelines for Success
- Practical Estimation: A Pocket Guide to Making Dependable Schedules
And some tools to help out
- Construx - from Steve McConnell where one #NoEstimates advocate claimed Steve proves estimates cannot be done. Of course, that's simply not true.
- Agile COCOMO II
So you see a trend here? There is nearly unlimited resources on how to estimate software development projects, how to manage in the presence of uncertainty, how to elicit requirements, how the plan and schedule software projects.
So if you hear we're bad at estimates, that's likely the actual experience for the person making that statement, because the person saying that hasn't yet learned how to estimate. Or when we hear estimates are a waste, it's likely it's not their money, so to them estimates take away from some other activity they see as more important. Why do they care of the project overruns it's budget, is late, or doesn't produce the needed value? Or my favorite estimates are the smell of dysfunction, when there is no domain, root cause, or corrective actions suggested, because that's actually hard work, and it's much easier just to point out bad management than provide suggestions of good management.
Estimating is hard. Anything of value is hard. All the easy problems have been solved.
But if we are to ever get a handle on the root causes of software project failure modes, we do need to seek out the root causes. A that means much more than just asking the 5 Whys. That's one of many steps in RCA and far from the complete solution to removing the symptoms of our problems. So start there, but never leave it there.
Here's some approach we use
Unanticipated cost growth is a symptom of failing to properly estimate in the first place, update those estimates as the project progresses, and deal with the underlying risks that drive that cost growth. Same for lateness and less than acceptable delivered capabilities. Once the estimate has been established in some credible form, adjusted as the project progresses, you of course have to execute to the plan, or change the plan. It's a closed loop system
- Assess performance
- Determine error signal
- Take corrective actions
- Change target
- Change execution processes
- Repeat until complete
The answer to the root causes that create the symptoms we so quickly label as smells of dysfunction is NOT to stop doing something, but the learn what the actual cause is. Stopping before this knowledge is acquired leaves the symptom still in place. And that doesn't help anyone.