“Everybody has a plan until they get punched in the mouth.”

—Mike Tyson

As someone who has spent many years helping organizations deploy new systems, applications, and websites, I often think of the quote above.

I remember many instances over my consulting career in which team meetings resulted in poorly conceived, inscrutable Gantt charts. In no particular order, these included:

  • 30 days for testing
  • Two weeks for report development
  • Eight hours for employee training

In each case, the estimate was nothing more than a SWAG. Even worse, tasks and entire phases based upon these misguided estimates add up. It’s no surprise, then, that so many traditional tech projects fail. While the factors are multifold, downright awful planning is arguably at the top of the list.

A Different Type of Estimation

So we should never make estimates, right?

Wrong.

As it turns out, we humans are terrible at making absolute estimates. Fortunately, we make relative estimates quite well—and this is a key tenet of Agile methods such as Scrum. (For more on this, see The Elements of Scrum.)

Let’s demonstrate this notion in non-technical terms with a simple example. How long would it take you to mow each of the following lawns?

What happens when weeks turn into months?

In absolute terms, I don’t know. However, barring some unforeseen circumstance, it will take far less time to mow the lawn on the left compared to the one on the right.

This might seem like an obvious and simplistic observation to make. No argument here, but far too many people fail to remember the obvious when planning—especially on IT projects. Over- or underestimating an hour here or there on a small project may or may not cause massive problems, but consider the following:

  • What happens when hours turn into days?
  • What happens when days turn into weeks?
  • What happens when weeks turn into months?

Now you begin to understand the folly of absolute estimates.

Feedback

What say you?