WHY "IT PROJECTS" FAIL

by Paul van Essche

I doubt there is single subject in this entire industry that's been given more air and space than the stubbornly surviving "Why IT Projects Fail". You'd think we'd have worked it out by now! But no, Sisyphus-like, we seem doomed to repeat our fate, while sad accounts of lousy and failed projects distract us like mosquitoes at the lake-house, complete with the equally bugging list of hack remedies, lessons learned, and ever-so-tired CSFs - Critical Success Factors - now one of the oldest TLAs since TLAs were a thing.      

And just when we thought it was safe to go back in the water, the whole subject was given a monumental energy-boost late last year by the very publicly disastrous implementation of the US Government's new on-line Medical Insurance system. Google this title and see: anything written after October last year makes mention of it. 

So I've accepted the challenge to say something different on this tired subject, or at least say it differently. I'm taking the "senior executive sponsorship, experienced team, clear objectives" mantra for granted here, and have tried to distill it all down to just a few succinct points that, I sincerely hope, encapsulate the issues, and will make a real and tangible difference if heeded. 

In my humble opinion therefore, why do these projects underperform so badly, and so often fail outright? Why do we so often get it wrong?

1. They’re not IT projects. 

An IT project replaces wired computer networks with wireless ones, or upgrades email servers for greater speed and capacity, for example. Overhauling the way in which social security benefits are managed and paid is a business project, and needs to be managed as such. Managing business projects like IT projects will invariably cause them to fail because the skills, methods and tools required for each are significantly different (see 2. below). Rather, they should be branded, managed and supported as “business transformation” projects, which is exactly what they should be if they are worth doing at all. Why would you invest in a project in the first place if you weren’t expecting significant beneficial change, and bottom-line impact? IT can make that change possible, but it doesn’t make it happen. 

2. Fundamentals are not respected.

The fundamentals of any operation or project, whether you’re making shoes, or growing potatoes, or computerizing a national health service, have a lot in common, even if the execution (obviously) varies. They require the management of the same three primary resource classes: people, process and technology. Unless conscientious, skilled farmers (people) prepare their fields appropriately (process) with well-maintained ploughs and the right fertilizer (technology), their crops will fail. Failed projects in general, and failed business transformation projects in particular, have insufficiently experienced, qualified and/or motivated people, using inadequate and/or inappropriate methods to implement the wrong and/or wrongly configured technology. It defies reason, but this mistake is made repeatedly: non-specialized people, capable only of muddling through, are expected to execute strategically critical projects with the same technology that everyone else bought (and mostly failed with), without adequate support. Imagine if the same approach was adopted by your surgical team, or even your auto mechanic...

3. Partners are mismanaged. 

Arguably this element would fall under process or method in the fundamentals area, but it is so critical, and such a major cause of failure, that it requires its own mention. In addition, clients are often over-reliant on their partners, particularly management and IT consulting firms, to provide the people, processes and technology for their projects in the first place, as well as all the advice and knowledge relating to these assets and how they should be deployed. “Managing” partners means keeping them honest and getting good if not excellent value from them, and actively steering them away from the "we win whether you win or lose" paradigm - an insidious reality that the vast majority of decent clients are so blissfully unaware of. This may sound simple but it’s far more difficult than anyone who has never attempted to do so could possibly imagine. 

4. Recipes replace Leadership.

Somehow we've come to believe that 100'000-line project plans are the recipe for guaranteed success, and that all we need to do is execute to the letter and all will be fine. Nothing could be further from the truth. Even in complex projects, if your plan goes over about 1000 lines, you're in trouble. Keep it simple, don't treat the project as a sausage-making exercise, encourage creativity and adaptability, and provide your team with continuous reminders of the higher goals, motivation, encouragement and support. Of course, "leadership" is one we could talk about for hours, but that's a subject for another post...

Bottom Line

So, the bottom line is this: manage a transformation like a transformation, not like a server upgrade. Decide what you want to achieve, and keep aiming for it and working towards it -unwaveringly. Make sure senior people are responsible for and tied into the success and the benefits you expect, every step of the way, and put them under pressure to deliver. Staff the effort with competent, experienced people, put them under pressure too, but support them and the mission purposefully and energetically. If you need external help, find the very best - remembering that big names don't guarantee you the best result - and push them relentlessly to deliver fair value, possibly giving them some skin in the game too. Be bold, trust your gut, and just do it. 

Post Scriptum: the most fabulously excellent book I’ve ever read on the sticky question of leadership is “Artists, Craftsmen and Technocrats: The Dreams, Realities and Illusions of Leadership” by Patricia Pitcher. I believe it’s been republished under the title “The Drama of Leadership” but get a copy of either one. Absolutely mandatory reading.