Software project estimates – and targets and commitments | submitted by Robert T. Merrill

In “Software project estimates – the brutal facts,” I introduced you, the non-technical executive, to two cold, hard facts:

1. Software project estimates are even worse than you thought. The range at typical project go/no decision time is probably between a factor of two and a factor of four.
2. Though your IT folks can probably get better at estimating, they can’t get enough better to make the estimation problem go away.

I also suggested that you, although not a software expert, can do more than anyone in your IT organization to obtain consistently good business results, despite the brutal facts. How?

Two kinds of bad

When it comes to estimates, there are two kinds of bad. Consider these targets:

The shots on the left seem equally likely to be high or low, but show a lot of scatter, or “random variation.” The shots on the right have less scatter, but are consistently low. This is bias, or “systematic variation.”
Software project estimates are more like the shots on the right. They’re usually too low, except we don’t say that. Instead, we say the project ran “late” or “over budget.” It’s interesting how we blame the project. And we always have a reason. The gizmo didn’t work as expected, we discovered extra requirements, and our productivity didn’t improve like the consultant said it would. Everyone wants to “do better” next time, but the next project usually is late and over budget. If you had an employee who was consistently late – whose arrival time at work showed a positive bias – would you recommend that they drive faster?

Where bias comes from

Consistent cost and schedule overruns mainly happen because we’ve confused three very different things – targets, estimates, and commitments.

Targets

A target, or goal, is a desired outcome. “We want the new online shopping features live by mid-October.” IT people take note – there are often good reasons for targets, and the people making them don’t think they’re unreasonable. (If a sponsor deliberately is setting project teams up to fail, the CEO needs to throw someone off Jim Collins’ metaphorical bus. Someone’s trying to get up by pushing others down, at the firm’s expense.) Sooner is always better than later, and in other business activities they’ve managed in the past, “stretch goals” or “creating a sense of urgency” worked well for them. Plus, there’s uncertainty, so it feels like a negotiation. So targets tend to be optimistic.

Estimates

An estimate is a statement of probability. Really. If it’s not like, “Project X has a 75% chance of being completed by Oct. 15,” or “Project Y has a 90% chance of costing between $100K and $400K,” then it’s not an estimate. The future isn’t certain, but we know something about it, and what we know is most clearly expressed as a number (or a range) and a probability. The number can be days or dollars or dog piles, but if there’s not a probability with it, it might be a target or a commitment, but it’s not an estimate.
In too many IT shops, if you provide even a range, not to mention a probability, when asked for an “estimate,” you get told to try again. That’s because you’re really being asked for a commitment and, given rank and personalities, commitments tend to look a lot like targets and projects are overcommitted.
The downward pressure increases if your firm has a project portfolio management or gating process (not a bad thing, but be careful). Everyone wants “their” project approved, and with all this uncertainty in the estimates, it’s tempting to take a little off the top. IT people are guilty of this too. Given the choice of adding some features to a grungy old system or writing an iPhone app …

Commitments

Commitment means “an agreement or pledge to do something in the future.” Commitment also means “a consignment to a penal or mental institution,” which too many IT projects come to resemble. IT people take note again – commitments are not evil. Business, indeed all human interaction, runs on implicit or explicit commitments. There are consequences if a commitment is not kept. So “padding an estimate,” though meant as a pejorative, is actually quite sensible. If by estimate, we mean a number that has a 50/50 chance of being met, who wouldn’t increase that number until it has more like a 90% chance, especially if the consequences of failure are significant? The key to keeping promises is not making promises you can’t keep.

Minimizing Failed Commitments

Isn’t this what it’s really all about? As a senior leader, you want your firm to make commitments to itself that it can probably keep. You can start moving in this direction, right away, by keeping estimates and commitments separate.

Estimates are for decision support. You want to make the best decisions possible, so you want the best information possible. All estimates are made by people (even fancy estimation models have knobs you can turn, moving the result a lot) and are therefore malleable under heat and pressure. So eliminate the heat and pressure. Keep the target to yourself. Ask for a range and a probability, and take it for what it is, even if it’s brutal. Plan the project using the 50/50 numbers and manage to that. The difference between the plan and the commitment becomes the contingency, under the control of the sponsorship team and the project manager.

The contingency will be larger than you either expect or like, especially when expressed as days or dollars. I guarantee it. There’s a better way to handle the contingency, but it might require a change in how you run projects. I’ll save that for later.

Robert Merrill is the principal of uFunctional LLC, a Madison-based consulting practice.