IT Project Failure: How Did We End Up Here?

McKinsey’s report last week, drawn from an analysis of 5,400 IT projects, deserves reflection. It makes sober reading:

“Our research, conducted in collaboration with the University of Oxford, suggests that half of all large IT projects massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.”

Conspiracy theorists and crime fiction fans will likely read it and claim skullduggery amongst the SI consulting firms invariably associated with large IT projects.  Resisting the inner detective, let’s just stay analytical and ask: how did we end up here?

At the heart of McKinsey’s prescription for delivering IT success is “helping IT and the business to join forces” – the need for effective collaboration.

Successful IT project teams, says McKinsey, continually engage with stakeholders – at all levels, internally and externally – within a rigorous governance framework for managing change.

IT program teams use email, Sharepoint, shared desktops, conference calls and social media.  They typically have budgets to allow substantial groups to convene for months of workshops in airport hotels. And the people involved, by and large, want to do a good job and to be associated with a successful project.

So, with all these resources: If effective collaboration is the key to success, and the costs of failure are so enormous, why do large IT projects so often fail?

In my experience, the two biggest barriers to effective collaboration between IT and the business are that:

#1 They don’t speak the same language. Theoretically, their lingua franca is ‘business process’.  But, most often, the IT program team adopts a technical language and systems mindset. So the business is forced to adopt swimlanes and other IT constructs. Without the business properly engaged in discussions of the current operational reality and the target operating model, the project is immediately vulnerable to what McKinsey identifies as a common pitfall: ‘teams focus disproportionately on technology issues and targets’.

#2 Holistic perspectives are lost or ignored. Most often, the IT systems mindset comes to dominate: if it’s not automated, it’s secondary. And so the business stakeholders come to focus only on the process fragments linked to system transactions, which limits creative thinking about transformation possibilities and hampers change management.  Far too few of those involved, if any, can see the whole. What starts out as a business transformation project enabled by IT slowly degrades to become an IT project with business consequences.

Which is how, most often, business stakeholders find themselves forced to approve enormous documents (400 pages is the biggest I’ve seen, others claim to have seen 600+ page documents), with each process fragment annotated with technical flowchart diagrams and multi-column tables of requirements extending over many pages. It might as well be in Egyptian hieroglyphs. Even worse, that document becomes simply a project milestone, the end of a requirements capture stage. It totally undermines the idea of the rich ongoing collaboration between IT and the business that defines successful projects.

That document is the smoking gun at the heart of IT project failure.

Related Posts

26 Oct 2012    Avoiding IT Failure (and Bankruptcy)

28 Aug 2012    The ROI on Process Visualization

© Text Michael Gammage 2012

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s