It seems that more than a few of the biggest ERP projects never do get finished. The cancellations of a couple of big SAP implementations in the States (tens of millions of dollars each — U.S. money to boot) were significant enough to rate a recent article in the Wall Street Journal.
The pattern is a familiar one: a new CEO or CFO, seeking to distance themselves from the expensive transgressions of their predecessor, cancels a big IT project half way through.
“A well considered decision,” he or she might say. “Things have changed in our environment, and we’ve decided to save the company the $40 million that we would otherwise have had to commit to this project from now to the end.”
What they’re saying is obvious: the world changes fast, and so do project requirements.
For the IS guerrilla, this kind of behavior is almost entirely predictable, and leads to a natural aversion to ‘big’ projects that span multiple years, and especially to the way these big projects are planned.
He or she knows full well that during the span of a multiple-year project, significant things in the project environment will change, and that the context in which the project was originally undertaken may have changed entirely by the time the project team is a year into the work.
The cynic will say that any project with a duration of more than six months will be subject to so much environmental change as to make the original reason for doing it a distant, vague, and sometimes unpleasant memory.
Think I’m overstating the case? How much has changed in your organization and in the organizations of the clients you serve in the last two years? How much of that change did your organization correctly anticipate and factor into your major project planning? I rest my case.
The bottom line is these changes render any detailed planning beyond a six month horizon entirely useless.
What the executives who cancel big IT projects don’t say is also significant here:
1. We’ve already flushed $20 million down the pipe to get to this point.
2. We probably didn’t plan this thing right in the first place, so we’ll do it ‘differently’ next time.
The first thing they don’t say is embarrassing, the second one is ominous: the usual meaning of ‘differently’ is ‘more carefully’, and ‘more carefully’ is too often used as a proxy for ‘even more detail’. I think we’ve agreed that given how fast changes occur, more detail is definitely not what we need.
I heard an especially good analogy used to describe this over-planning phenomenon in a meeting recently in Washington. A technical architect for KPMG called it “steering beyond the headlights.” He suggested that you wouldn’t plan the tactical details of your project more than six months out any more than you’d steer further down the road any further than you could see in your headlights.
Beyond the headlights, he’d suggest that we watch the road signs, check off towns on the map as we passed through them (projects milestones, as it were), and even adjust our route as the weather and traffic dictated.
It doesn’t mean that large projects are by nature doomed to failure, but it does mean they should be managed in detail only in the near term, and to significant (and sometimes flexible) milestones further out.
The IT guerrilla approaches big projects with caution, shuns detailed planning further than six months out, and never steers beyond the headlights.
Hanley is an IS professional living in Calgary. He can be reached at [email protected].
