Quick! What's the answer to this question?

Bob and Jane are leading a project that started January 1st, 2008. The deadline is December 31st, 2008. There are four milestones, three months apart: one each at the end of March, June, September, and December. Each milestone requires an internal release, so each milestone does a good job of exercising the team's ability to create a shippable product.

The team doesn't meet their March deadline until the end of June. In other words, they're three months late. Assuming the team size and makeup doesn't change and the requirements don't change, what's the most reasonable thing Bob and Jane could tell their boss about their schedule?

1. The project will ship on time, in December, as planned.
2. The project will ship three months late, at the end of March 2009.
3. The project will ship six months late, at the end of June 2009.
4. The project will ship a year late, at the end of December 2009.
5. The project will never ship at all and should be cancelled.

Answer below (highlight to reveal):

The correct answer is "D." The project is most likely to ship a year late. Of course, with such a long time schedule, anything could happen. (Specifically, it could take longer. The team is doing a good job of mitigating this risk by creating internal releases for each milestone.) Still, this is the most reasonable interpretation of the data. The team took twice as long as planned to meet their first milestone, which means the estimates were half of what they should have been. They'll probably take twice as long as planned to meet every milestone... so the whole plan will take two years instead of one and the project will ship a year late.

It amazes me how many times people choose "B," or even "A". For some reason, people think that these missing milestones are just flukes... that somehow the team will magically go faster in the future, or even "make up" the lost time.

Sorry, it just doesn't happen that way. Projects almost never go faster than estimated. That happens less than 10% of the time. They usually go slower than estimated, and according to one set of data I've seen, 50% take over twice as long as estimated. There is no making up time. The best way to predict the future is to measure the team's actual performance, compare to their estimates, and apply a scaling factor. XP's velocity does exactly that, which is why good XP teams do so well at meeting commitments.

I've had people tell me "past performance is no guarantee of future gains." (Clearly, these folks have been spending too much time obsessing over their stock options.) That's true... there are never any guarantees when talking about the future. But past performance is a pretty good indication of future performance, and when it comes to project planning, I've never seen a more accurate tool. At worst, it's too optimistic, and excessive pessimism isn't usually the problem you'll be facing when injecting reality into a schedule.

(The optimism problem shows up if you're not getting your software "done done" at the end of each iteration or milestone. You end up scaling your estimates to how much time the work actually takes, true, but you're not doing all of the work that you're supposed to. You end up with an indeterminate amount of wrap-up work at the end of your schedule that's nearly impossible to estimate. That's part of why so many projects have an unending series of "two more weeks" promises after everything is "done".)

PS: Some people will argue that the most reasonable thing for Bob and Jane to do is to give their boss answer "A"--saying that the project will ship on time. That way they won't get fired. Sorry--wishful thinking won't prevent the truth from coming out eventually. Leaders have a responsibility to their organization... and if your organization is that bad, why are you still working there?