Why Are So Many IT Projects Successful?

It’s bizarre how many major IT projects are ‘successful’.

Imagine buying dinner for your loved ones at a restaurant where the service was always slow, the bill was usually way beyond the prices shown on the menu, and the dishes were less than half as delicious as you had expected.  And, 17% of the time, the evening would be so disastrous that it would threaten your marriage. Not sure that many of us would call that successful? But when it comes to ERP, that’s what people most often do.

A new survey on ERP implementations, published on Michael Krigsman’s Beyond IT Failure blog, records:

  • over 50% of projects experienced cost overruns
  • over 60% experienced schedule overruns
  • 60%  of respondents received under half of the expected benefits.

It’s another piece of evidence to add to the bulging portfolio marked ‘IT Project Failure’ (the root causes for which I’ve rehearsed elsewhere).

But it leaves the intriguing question: How can it be that 60% of respondents in this survey thought their ERP implementation was successful?  It’s not an aberration. The hard data and the shot-through business case may point conclusively in the opposite direction, but most often organizations define their major IT projects as ‘successful’.

Maybe it’s a mix of Stockholm Syndrome and exhaustion.  It may feel initially like a comforting embrace, but the SI relationship frequently turns sour (only 25% of respondents in this survey were satisfied with their implementation partner). As the project challenges mount, the client’s expectations plummet.  In the end, there’s relief that it simply finished. And at that point, the client is happy to draw a veil over its own shortcomings and declare success.

Which is understandable but a pity. There’s a colossal waste of resources going on here, and, as McKinsey has warned, maybe 17% of major IT projects are black swans that can threaten the very existence of the organization.

Related Posts

07 Jan 2013    Cloud Without Risk: Pie In The Sky

08 Nov 2012    IT Success: Don’t Let The SI Take The Wheel

© Text Michael Gammage 2013

The Root Cause Of IT Failures

Next month’s HBR has new evidence on the colossal cost of IT failures. It’s the largest global study ever of IT change initiatives. And it’s not optimistic:

“It will be no surprise if a large, established company fails in the coming years because of an out-of-control IT project. In fact, the data suggest that one or more will.”

The study conclusions seem sensible – smaller projects, better risk assessment – but they don’t get anywhere near the root cause.

For a start, even if IT projects were smaller and risks were better managed, there is the bigger problem of ‘projectification’ – the challenge of managing multiple projects within organizations that are complex, fast-changing and increasingly virtual.

The HBR report includes data on ‘projectification’:

61% of managers reported major conflicts between project and line organizations

34% of companies undertook projects that were not aligned with corporate strategy

32% of companies performed redundant work because of unharmonized projects.

All of which points to the underlying issue, the root cause of most IT failures: communication. More specifically, the lack of a framework for effective collaboration that ensures joined-up thinking across the enterprise.

This is absolutely not breaking news – Michael Krigsman and others have been hammering on about this for years. But it’s still true.

The answer, as leaders in this space have realized, has to be a collaborative framework, within a robust governance wrapper, that sits at the heart of the business.

It has to use the universal language of end-to-end business process. It has to be holistic, not just about what’s automated. It has to be integrated, combining process with analytics, risks and controls, documents, quality and compliance. It has to offer different stakeholder perspectives of one process reality, especially to align IT with the business. And it has to support people doing real work, and engage them in continuous improvement.

Implementing a platform of this kind is not necessarily easy. Conceptually it’s neat and obvious. And yet implementation often meets resistance beyond the normal inertia.

Maybe that’s because it’s hard to shift a culture to embrace transparency and new levels of visibility and accountability. But maybe there’s an even deeper reason for clinging on to things as they are and rejecting the wider perspective. Projects – even big ones – are quite comfortable places to be. There’s a seductive sense of certainty and control.

We don’t want to lose project control of course, but the future must surely lie in coordinating all projects within the wider enterprise perspective. It’s the only way that major IT failures, that can cost $m as well as the end of many jobs, can be averted. And major business transformation failures, and major compliance failures, come to that.