Estimating Software Projects:

So you messed up. Now what?

This is the final part of a series on estimating software project timelines. Previously, I’ve covered why we should make estimates, a technique for making accurate estimates, and advice on making rapid, intuitive “SWAG” estimates.

So now: say you’ve followed my advice, made an estimate for that project, and now you’re realizing you’re behind. You’ve estimated ten weeks, and are sitting here in week five looking at a TODO list that’s not anywhere close to halfway done. Now what?

Don’t do what I did

First, let me discuss what not to do, by way of a story. I’ve written a bit before about the circumstances that led to me leaving Heroku – I wasn’t fired, not exactly, but I also didn’t leave entirely voluntarily. One of the major factors that led to my not-quite-firing was a bad estimate. But that wasn’t the real mistake: I compounded the problem by failing to communicate our lateness for several months.

I was leading a major compliance project, one that we expected to take the better part of a year. It was a complex project: many moving parts, some tricky technical and human-factors issues, and pieces that touched nearly every team. I did the work to put together a timeline and estimate, got the staff and budget it said we needed, and got to work.

That estimate turned out to be wildly incorrect. The project ended up taking a year longer than I’d originally projected. The reasons are complex; the short version is that I made some major technical assumptions that turned out to be wildly incorrect. Several large architectural changes I’d thought we could avoid turned out to be unavoidable, adding all sorts of dependencies and additional work to the project.

This might have been OK had I handled it well, but I didn’t. Instead, I ignored the problem until it was far too late.

The whole thing situation came to a head in November: it became very clear that our timeline was way off. This was a huge surprise to my bosses … but not to me. I had started to realize as early as July or August that we were behind, and by early September I was increasingly sure we were screwed.

But I kept it to myself. I convinced myself that my intuition was wrong, that we couldn’t possibly be late. I avoided digging in and revising my estimate. The project planning spreadsheet said we were still on time (because it hadn’t been updated), and I convinced myself this was true despite mounting evidence.

I count this as one of my biggest professional failures.

I don’t think this story is that unusual. I’ve seen it play out many times. When we realize a project is late or over budget, that brings up all sorts of negative emotions: shame, fear, anger, disappointment, etc. It’s easy to get sucked into delusional thinking – we’ve all thought things like “yeah I know I’m behind, but I’ll just work through the weekend and catch up.”

So, with the benefit of hindsight, what should I have done differently? How should we handle an incorrect estimate?

Communicate lateness early by communicating status regularly

The most important lesson here is communicate lateness early. The moment you realize there’s some schedule risk, you should be making it widely known. Even if you’re not late yet and have merely realized that some part of the project is riskier than you’d thought and could potentially push the timeline out: you should still communicate that risk right away.¹

This is easier to say than to do; I knew this rule, and still ignored it! It can be hard to admit that you made a mistake, and easy to engage in magical thinking as a defense mechanism.

A way to fight back against this is to report status frequently – weekly, probably. Some organizations have regularly established mechanisms for status updates (e.g. project updates at weekly staff meetings). If yours doesn’t, I suggest weekly status emails to your boss and any other important stakeholders. Even if those emails just say “yup, still on track” – they’re worth sending.

A common tactic is to report project status using a “green/yellow/red” scale. I like this as a shorthand, but often there’s vagueness around what “yellow” means: “green” is “on time”, “red” is “behind or at major risk”, but “yellow” is … unclear. This leads to pressure to keep projects “green” until it’s too late, at which point they suddenly go “red”.

Thus, if you use “green/yellow/red”, I highly suggest you define “yellow” as broadly as possible. “Green” should be reserved for “on time, low risk”; as soon as there’s any slip, no matter how slight, or any additional risk, take your project “yellow”. You may face some pushback, but it’s far better to get ahead of a failure than to have it happen by surprise.

Avoid magical thinking

In the search-and-rescue community, there’s a well-known phenomenon where people who are lost get even more lost despite having good maps (and even GPS). As people get more and more frustrated, they start failing to match what they see around them to what’s on their map. They convince themselves that the stream they expect to have seen must have dried up since the map was printed, or that the trees are confusing the GPS signal and they aren’t really walking towards a cliff, etc. This is known as “bending the map”: we know where we want to be, and when the map doesn’t support our desire we convince ourselves that the map is wrong.

We do this with projects too: we want so badly to not be late that we convince ourselves that the data showing that we’re late is wrong, or that we’ll “catch up”, or some other form of magical thinking.

To help you avoid magical thinking, here are some facts about late projects:

• Late projects stay late. It’s terrifically rare to “catch up” on a late project. When projects run late, it’s because you’ve missed something in your original estimate: you’ve guessed that work will take x days, but it’s taking 1.5x, or whatever. For you to “catch up”, your estimate would have to be wrong about the rest of the project, but in the opposite direction. Even if you correct what led to the overrun, it’s terrifically unlikely that you’ll somehow make up time.

• Indeed, late project usually get later – it’s much more likely that your origin estimate will continue being wrong at about the same amount.

  Imagine a project you’d originally estimated at 10 weeks. It’s now week 6, and you’ve just hit the halfway mark. When should you expect to finish? The correct answer is “6 more weeks”: if you slipped a week in the first 5, that data suggests you’ll slip another week in the back 5.

• Adding more people to a late project makes it later. This key observation from Fred Brook’s The Mythical Man-Month is as true today as it was when that book was published nearly 50 years ago, but we still keep making the same mistake². If you haven’t read MMM, you should.

• “Crunch time” can work, but only sparingly and at a high cost. We sometimes turn to “crunch time” – working overtime to finish a project. The data shows that crunch time can work to make up time on a project, but only in very limited circumstances. Teams can only sustain crunch time for a week or two at most before quality suffers dramatically. Crunches that last longer, or reoccur often, result in worse results (lower quality, even later projects). And even short crunches that do have a positive impact on a project’s timeline will cause stress, frustration, and burnout³.

  My suggestion: if a single week of overtime will help you meet a critical deadline, and you can promise your team it’ll be an extremely rare occurrence (like, once a year, at most), consider asking for overtime. Otherwise, just take your lumps and accept the late project.

Make a new estimate (but keep the old one)

One last note: as soon as you realize you’re late, create a new estimate, taking into account what you now know (and the facts above). But don’t overwrite the old one; it’s important for your growth that you keep each iteration. Review your failed estimates sometime later, when the emotions have faded, to figure out what you did wrong. That’s how you’ll learn to make better estimates next time!

I hope you’ve found this series on estimation useful. Good luck with your estimates! As always, if you try out any of the tools and techniques I’ve shared, please get in touch and tell me how it went.