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

Avoiding IT Failure (And Bankruptcy)

News from a colleague yesterday of another SAP project using Nimbus: unforeseen delays, a shredded budget and a bewildered client. Another huge success in fact.

This European manufacturer was told by a leading analyst firm to expect to take at least 8-12 months for its Finance transformation and SAP consolidation project across 8 countries and 7 lines of business.

Opting to use Nimbus, the program team worked with stakeholders from across the European business units to agree common business processes – in blueprints that included KPI’s, policies, local variants and all the detailed requirements necessary to implement a single SAP instance.

Their results were completed, presented and approved by all the country CFOs and other CxO stakeholders in just 4 months.

Which leaves the program team with an unforeseen delay while the rest of the business scrambles to catch up (it was widely assumed that the program team would take at least 12 months to complete the blueprinting phase).

And the client’s budget is shredded.  The program timescale has been dramatically shortened, significantly reducing the consulting days required (as well as the equally expensive number of days required from internal resources).

This client’s savings are not at the expense of quality. The reverse in fact. As it happened, the client’s chosen SI implementation partner had no Nimbus expertise. So the client decided that they would not be required for the blueprinting phase. It was a gamble that paid off handsomely.  When the SI was recently re-introduced back into the project, at the completion of the blueprinting, its verdict was that this is “the best SAP blueprint we have ever seen”.

It’s another example of the power of Nimbus as a platform for effective collaboration across complex and dynamic environments (yawn…). But it’s extraordinarily relevant in a week when McKinsey has published results from a survey of 5,400 IT projects (with a combined cost over-run of $66bn).

As McKinsey notes, the keys to IT project success are not rocket science: good stakeholder management, effective teamwork and avoiding ‘the common pitfall of focussing disproportionately on technology issues’.

So a platform that provides visualization of end-to-end processes – intuitive, in their complete business context, and in the language of the business – and wrapped within a robust governance framework won’t just cut costs.  It’s the best possible insurance against a ‘black swan’ – the 17 percent of IT projects which McKinsey reckon go so bad that they can threaten the very existence of the company.

Related Posts

28 Aug 2012    The ROI On Process Visualization

24 Aug 2011    The Root Cause of IT Failures

© Text Michael Gammage 2012

Mapping The Stakeholders In GBS Success

I sat down with a recently-launched and highly ambitious Global Business Services (GBS) team to map all the stakeholders who will need to be engaged to ensure their success.  We rapidly filled the whiteboard (below – disguised!).

GBS Stakeholders

It’s an extraordinary number of people,  across multiple functions and regions.  And this is not just about preparing for the launch for this particular GBS. This is about ongoing collaboration – and its scope is only going to expand as this GBS scales up on its five year program.

This organization intends to adopt Nimbus to enable the collaboration across these diverse stakeholders that will be required to deliver outstanding service for its clients. Frankly, it’s difficult to see how else you could do it.

End-to-end process – in the language of the business – is becoming the universal business language.  Wrapped within a robust governance framework, and delivered to users in way that supports them in doing real work, it’s the platform that can ensure effective collaboration across the complex and dynamic service delivery environments faced by most GBS organizations.

Related Posts

26 Sep 2012    Global Business Services: Building The Brand

21 Aug 2012    How To Simplify Global Shared Services

© Text Michael Gammage 2012