Herding Cats: Want To Learn How To Estimate? Part Troisième

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.

And some tools to help out

QSM
Galorath
CoStar
Construx - from Steve McConnell where one #NoEstimates advocate claimed Steve proves estimates cannot be done. Of course, that's simply not true.
ACEIT
Agile COCOMO II
CSP
CoolSoft
r2Estimating

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

The Apollo Method

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

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