There exists anecdotal evidence that Information Technology (IT) projects fail at a greater rate than other types of projects. Why is this? Are we that bad at delivering projects? Or is it that we’re that bad at planning?
Have you ever asked an artist to predict how long it will take to create a novel piece of art? Or tried to get a marketing team to plan the schedule for coming up with the next campaign? Why are we as IT teams so ready to come up with these precise, scientific – even optimistic – schedules? What we do is often just as novel and just as creative. But we’re ready to plunk down numbers on a schedule with the confidence of divine inspiration.
Project Management is a special kind of management. That is, project management is the poster child of Management by Objectives (MBO). The unique aspect of MBO – and thusly project management – is the objectives (milestones) with which are either tracking or off track. To have objectives entails planning. In project management, we call the objectives milestones and they are points on a (time or cost) schedule.
I want to distinguish here among varieties of projects. Like the abstract water colorist who can knock out wilderness landscapes with the reliability of an assembly line, some shops do many very similar projects. With those conditions your planning can get fairly precise. It’s those other projects I’m talking about. Not high risk, no, not those. Rather, the high novelty projects.
Projects where you and the team have never really done anything like this before. You’re breaking new ground and every design activity is a unique creative effort.
How can you say up front how long this will take or how much it will cost? But we do. And we commit to these numbers. Why can’t we be like the artist or the marketer? Why are they so much smarter than us when it comes to these commitments? Is it because they’ve learned from their mistakes?
I assert that what we’re really predicting in our plans is not that it will take this long, but rather that it will take at least this long. That it can’t realistically be done in less time. And some of the engineering work can be planned. For example, we can lay out that we will complete requirements in x days. Or that development will take so many weeks. But how long does it take to research alternatives? How many prototypes will we have to do before we get it right?
IT projects – that is, novel IT projects – are just as creative as the artist carving the block of marble or the ad team brainstorming the perfect campaign. And we should be just as resistant as those artists to committing too much (too little?) in advance. We do ourselves, our team, and our stakeholders a disservice otherwise.
The root cause of IT project failure: committing to a plan too early. We don’t fail on delivery. We fail trying to deliver to a faulty plan.
What happened when you promised when you should’ve waited? What stories can you tell about trying to deliver to the wrong plan?