How Much Longer will it Take?

Let’s talk about re-estimating software projects. Here is a situation I find myself in every now and then:

Say I’m the lead/best/only developer on a project, and partway through that project, we realize that we’re going to miss an important deadline. My manager will come to me with a question that I absolutely dread:

How much longer will it take?

It’s a perfectly fair question. Since I’m the lead/best/only developer, I’m in the best position to estimate how much more time is necessary, and my manager needs this information to make important decisions (add more people? talk to the client? etc). But it’s extremely difficult to answer! If the initial estimates (which I either came up with or approved) are wrong, how am I supposed to magically come up with better, more accurate ones?

The most important thing is to not answer on the spot; a great manager once told me that the best answer any time anyone asks you for an estimate is always “I’ll get back to you” and he’s completely right — there is absolutely no way you can put together a sensible estimate off the top of your head. Ever. You’ll always have to do a bit of math and take a few things into consideration, so give yourself time to do those things.

Now, let’s talk specifics. There are three main approaches I’ve seen myself and others use to re-estimate a project. For the following examples, let’s pretend that you’re in charge of a project that was initially estimated at 10 weeks, and after 5 weeks of work you find yourself 1 week behind schedule. How much longer will it take?

The Naive Method

The knee-jerk reaction that you might even say out loud if you answer on the spot is that you’ll need 1 extra week for a total of 11 weeks. The naive thinking here is along the lines of: “hey, we’re 1 week late, so give us 1 extra week to make up that work and everything will be fine”. The problem here, of course, is that if you have been late on your initial estimates for the first 5 weeks, you’re probably going to be late on your initial estimates for the next 5 weeks as well. We need to account for more than just the time missing so far. This brings us to:

The Logical Method

You may be thinking that the correct answer is 2 extra weeks for a total of 12 weeks, since if you need 1 extra week after the first 5 weeks you’ll probably need 1 more extra week on the 5 remaining weeks. That’s no longer a naive answer (it’s indeed logical) but your math is flawed and we can do a bit better.

Look at it this way: it took 5 weeks to do 4 weeks’ worth of work. So after 10 weeks, we’ll have done 8 weeks’ worth of work. Historically, if 4 weeks’ worth of work takes 5 weeks, then that last 2 weeks’ worth of work will actually take 2.5 weeks. So what you should be asking for is an extra 2 weeks and 3 days (always round up) for a total of 12 weeks and 3 days.

Now we have an entirely logical answer, and by all accounts you should be able to tell your manager with confidence that the project will be done after 12 weeks and 3 days. But here’s the thing — you’re probably still wrong. The fault lies in the very concept of estimates: you’re assigning a logical, mathematical number to the actions of real people with real lives and real feelings. If your team was entirely composed of robots, then yes, the logical answer is probably a great estimate, but that’s not how teams work. There are a number of estimate-affecting factors that the team dynamic adds:

• Some people will work longer days, evenings or weekends.
• Some people will “speed things up” by skipping test cases or code review.
• Missing milestones affects team morale.

None of these are always going to be good or bad for the project schedule, but it is foolhardy to ignore them outright. That’s why I believe in:

The Human Method

This is where it pays to know your team.

The idea is to take the proper logical answer, 12 weeks and 3 days for our running example, and tweak it based on the team dynamic. Does one of your fellow developers step up her game when the project falls behind schedule? Knock a day or two off the re-estimate. Do you have a teammate that gets easily overwhelmed? Add a day just in case. Is a stakeholder in the project going to want to have frequent meetings about why the project is late? That’s another day or two as well. You might be surprised at how things stack up: maybe it’s not as bad as you thought, maybe it’s much worse. But at least now you know.

Of course, you can’t always predict everything about your team, so sometimes you have to ballpark the team-dynamic chunk of the re-estimate. The best thing to do in this case is to err on the side of caution and add a buffer — something in the 20~30% range. For our example, that means adding another 25-ish% of the 2 weeks and 3 days that we’ve already added, call it 3 more days, bringing us to 3 weeks and 1 day. This means that our originally-estimated 10 week project is actually going to take a little over 13 weeks. Probably longer than what your manager was hoping for, but at least now we have some numbers to back it up.

And what’s your alternative, really? Make something up off the top of your head?