Salvaging the Situation

When you’ve missed some milestone, it’s natural for people to want a new estimate for that milestone. How much longer will it take? When will it be done? Or, as a boss of mine once asked me, “How many more unforeseen problems are we going to have?”

Reestimating when we’re in a hurry to make up for lost time is really frustrating. It’s tempting to skip it. You’ll meet that milestone when it happens, and you can’t afford to waste time on estimation. Perhaps, though, you’d do better to skip the part about hurrying to make up for lost time. Hurrying has been known to be associated with making more errors, which creates more delays. Yes, it’s true that you’ll meet that milestone when it happens. That, however, doesn’t change the needs of people who want to know when it will happen.

Obsolete Estimates

People talk about estimates being “wrong” when reality fails to match them. I find it more useful to think of them as obsolete. You now have more information and can see the situation more clearly. The estimate you made was rooted in the past and based on the assumptions and knowledge you had at that time.

Estimates don’t become obsolete suddenly at the arrival of the estimated date or the accomplishment of the estimated work, however. They become a bit more obsolete every time you learn new information, or you correct an assumption. Long-term estimates age a little bit every day.

Tiny bits of information erode our estimate like dripping water on a soft stone. It happens so slowly you often miss it, especially if you’re not specifically looking for it. You would do well to observe this slow degradation, and do something when you notice it. When the final reality proves our estimate “wrong,” the most wrong thing is that you never updated it along the way. (See ​If Estimating Is Hard, Estimate More Often​.)

Replanning

When estimates and actuals don’t match, trust the actuals. The actuals are data. It may be noisy data. It may be data that says things you don’t want. But it’s data. The estimates are opinion. Therefore it’s prudent to adjust your plans to take that data into account. Recalibrating is the same process as ​Calibrating to Unknown Context​, but you have more information about the variability in the rate of progress.

What’s past can’t be changed, so delays you’ve experienced are going to add to the current plan. Don’t expect that you’ll go faster to make up the lost time. Denial and optimism do not make a healthy plan. Even if you identify some time-saving changes to make in your development process, it will take time to integrate those changes effectively. Don’t count your chickens before they’re hatched.

Should you adjust the estimates of future work? Yes, it’s likely that there are lessons from the current delay that apply to this future work. (See ​What Didn’t We Know Earlier​.) If you learn these lessons, and adjust your plan accordingly, you may avoid some repeated disappointment. Don’t expect that you’ve solved your problems until you see it in the data, though. If you have eliminated the conditions that made progress slower than you expected, then you’ll get a happy surprise in the future.

After replanning 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-to-develop, 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 outdated procedures that can be eliminated and thus 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.

• Are there handoffs between one person to another or one team to another? Such handoffs always seem to create delays in matching schedules and in relearning the same lessons. Is there some way both people and/or teams can work together collaboratively to avoid a handoff?

• Are there times when some stream of work is waiting with no one actively working on it? Delays, like handoffs, decrease the efficiency of the work being done. Often such delays are due to work waiting on a bottleneck constraint. You may find it more effective on the whole if others help reduce that constraint, even if they’re not as efficient about it as those already doing that work.

• Are there internal documents, reports, or work products that no one is using? Eliminating these may speed up the work. If these are being used to communicate across handoffs, then collaborating in parallel may eliminate the need.

• Do people have multiple work items in progress at the same time? Multitasking reduces efficiency and increases mistakes.

• Are people trying to accomplish work faster than their capacity to do the work? If you stretch people too thin, then the work takes longer to do, and more mistakes are made.