“What’s that ticking sound coming from the engine of the car? Must be a loose valve. I’ll take the car to the mechanic for a valve adjustment…”
At the garage, they look up the flat-rate time estimate for a valve adjustment. It’s easier to estimate when you’ve measured the actual time from lots of competent people doing very similar work. They multiply that time estimate by their labor rates, add in some extra for gaskets, shop supplies and such, and give me a cost estimate. “It should be ready by 5:00.”
I go on my way, knowing I can pick up my car in the evening and how much it’s going to cost me. All is right with the world. But in the late morning, I get a call from the mechanic. “Your car doesn’t need a simple adjustment. The pushrod is bent. The reason it got bent is that the threads holding the rocker arm assembly are stripped out of the cylinder head. We’re going to need to keep your car another day, and the cost will be about triple the original estimate.”
What do I do with this information? I could berate the mechanic for giving me a bad estimate. I could insist that he only charge the originally estimated amount. I could tell him to work through the night so that I can pick up my car first thing in the morning.
I suspect that you don’t do any of those things. I don’t, partly because I don’t think it will get me what I want. Instead, it’s likely to damage my relationship with the mechanic, and get me less of what I want.
Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. If it weren’t different, we wouldn’t be doing it at all. Software development is orders of magnitude more complex than fixing a mechanical system. It’s fractal, whereby whenever we go into more detail, we also discover more complexities. It’s a very creative endeavour, requiring intelligent imagination.
We compound the difficulties by not keeping records that allow us to compare this work with previous work. We change the makeup of teams, so that even when we can compare the work, we can’t compare the workers. We add bureaucracy and technical constraints that may not be obvious when making the estimates. We change the circumstances after the estimates are made. We often expect other work to be done in the same time as the estimated work, without accounting for the loss of time and efficiency due to multi-tasking.
In spite of all these difficulties, I’ve observed managers berate developers for bad estimates, insist that they finish the work on the previously estimated date, and demand they work overtime to do so at their own cost. This article is not, however, about all the costly damage done by such reactions. Instead, let’s look at how we can act more productively.
When estimates and actuals don’t match, trust the actuals. Should you adjust the estimates to match? If you do this, then you can adjust the plan accordingly. How early can you test the correlation between the estimates in your plan and the actual rate of progress? When work is performed in large blocks and integrated at the end, it’s far too late for effective re-planning when the difference is noticed. How can you validate your plan earlier?
Working in small increments and continuously integrating can help, but you also need to know that those small increments are actually done. Using estimates of “the database layer is 90% done” won’t help, as you’re back to depending on unverifiable estimates. Rather than creating small increments based on the building blocks of your project, try using small increments of functionality. These functional slices will touch numerous building blocks, but can be tested unambiguously as to whether or not they work as desired.
After re-planning based on the reality you observe, you can attend to fitting that plan into your constraints. If progress is too slow to fit everything you want into your budgeted time or cost, consider trimming the scope of the work. This can be done by eliminating features, or by slimming features down into easier–though less capable–versions. You may have to make some difficult decisions about priority.
Observe where your delays and bottlenecks are. What makes the actual speed as slow as it is? If it seems that things “should be faster”, then it’s possible they would be–except for an accumulation of difficulties that impede progress. Perhaps there are some quick wins in out-dated procedures that can be eliminated and speed up progress. Perhaps the internal quality of the code has been ignored to the point that everything is hard to change. It will take time to improve that quality, but it will eventually pay off in faster development speeds.
Make adjusting estimates easy. Estimate in artificial units, and roughly correlate the artificial units to the ones you need to examine. People use story count, story points, t-shirt sizes, animals and other analog for estimation sizes. Try to be consistent, but be aware that estimation will vary over time. An advantage of artificial units is that you don’t have to go back and re-estimate when the apparent speed changes. If you were accomplishing 38 stories per month, and now you’re accomplishing 46, you don’t have to worry so much where that 8-story-per-month improvement originated. Merely project using the newer figure, and see what that does to your plan.
Don’t expect estimates to be precise. If you need them to be precise, you’re trying to plan too close to the edge of failure. Don’t rely on optimistic numbers. Also think about what a downturn would mean. Don’t validate your estimates with reality only once. Continue to re-check throughout your project. Work in priority order so that you can re-plan frequently to the end, but still deliver the highest priority functionality. And if you cannot prune the scope to fit and still achieve the project’s value, then you’re likely to be working on the wrong project.
As Tom DeMarco said, “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.” [“Software Engineering: An Idea Whose Time Has Come and Gone?”, July/August 2009 IEEE Software, pp 96, 95] Projects with a high return on investment can survive a few inaccuracies in estimation. Projects that need precise estimates likely won’t return their investment.
PM Guy's Blog 