It’s always Groundhog Day

But you’re thinking way too fast

So forget about the future

And let’s get on with the past

Sting, Forget about the Future

Yeah, I’m taking these lyrics out of context, and certainly not the way that Sting intended them. But the way I look at it, they make a point that I’ve been reminded of a number of times in the last year when reviewing IT project estimates.

Those of us who don’t learn from the past are destined to repeat it.

And man, are we ever repeating the past – it’s IT Groundhog Day ad nauseum.

The volume of historic project data and data analysis tools and access to expertise and communication vehicles that are being made available to us today are unprecedented. We IT types can pull in reams of data on historical project performance. We can crunch huge volumes of this data on an average, run-of-the-mill laptop. We can instantly access the work of some of the best IT brains in the world over the Internet, and we can talk to people when we need to – anywhere, anytime.

And with all this great stuff, we’re still making the dumb mistakes we’ve been making since DEC booted up the first PDP 11, and probably before that too, but I’m not old enough to know for sure.

A wonderful, terrible example: with everything we’ve learned about estimating for project budgets and schedules/durations, we still insist on estimating projects based on the lowest (completely unreasonable) budget and the earliest (entirely laughable) date – we either advocate for these unrealities ourselves, or we let them be imposed on us. In either case, the behaviour is inexcusable.

We know in our guts and from hard experience how wildly optimistic first estimates tend to be, especially when we really don’t understand the entire problem we’re dealing with.

Although it may not have been true a few years ago, it is now: there are data out there that tell us about typical project performance, and excellent organizations like the Software Engineering Institute are doing some good work in the area.

Even without looking outside our own organizations, we should be able to come up with some more accurate estimates for the future based on what’s happened to us in the past:

Go pull up the records on the last five projects your organization has taken on and write down their original estimates for cost and duration.

Next, find out what the final prices and duration for these projects were, assuming they weren’t cancelled. Pretty scary, eh? Forget about trying to account for changes in scope or excuses for delay.

“We’re more experienced now,” I’ve heard.

Yeah right. That and a quarter will get you…. When project budgets and schedules are presented to me now, I always ask: “Why should this project be any closer to the original estimates than any others we’ve taken on?”

And unless I hear some specific reasons that our estimating has improved, why should I assume this one is going to be different?

There’s a bunch of fundamental stuff in our business that we can fix, fundamental stuff from the past like estimating, fundamental stuff that’s been plaguing us for years, and now that we’ve got everything we need to attack the problem, there’s no excuse not to.

Like the skinny former-front man for The Police says, let’s get on with (fixing) the past.

Hanley is an IS professional in Calgary. He can be reached at