Why IT enabled projects still continue to fail

Published on : 13th December 2022

Why IT enabled projects still continue to fail

You probably have experience with many IT-enabled business transformation projects over your career. Many promise improved productivity and competitiveness, and with the current business landscape, are well and truly back in the spotlight. But do they really deliver and what steps can be taken to ensure future success?
David Lawrence (founder of Vine Resources) spoke with Clive Ewin a leading expert in this area to explore why so many companies do not realise the benefits of transformation and why they seem to make the same mistakes over and over again. 

IT or business driven?

Question - David. Why do so many organisations continue to fail to get value from business transformation projects? What are their processes and why is it important for them to find the business value in those proposed technology projects?

Answer - Clive. I think one of the problems is that often it's the IT department or the CIO that is driving the initiative. Frequently because of a perceived technical need. We've been saying for many, many years that it's not a technology project, it's a business project.

If we want it to be successful, we have to look at it that way. But then we initiate it from a technical perspective, which undermines the universal truth that we all know, which is that it needs to come from the business. So I think that's the core problem.

Often in large organisations, the only people that understand the technology are the CIO and his or her department. They are often the only people that also understand the end-to-end business as well. They see through the technology lens how information flows and what the outcomes are. There's often nobody else in the business who has that overview of the whole end-to-end value chain within the business. I think that's probably the other side of the problem. Nobody can see the whole business, but IT, so there’s a natural tendency to conflate technology projects and business transformation.

I think what we're seeing in response to this is that the CIO role is being pushed into the business. This means coming out of the Executive Team and reporting to a COO as opposed to the CFO. In the past, if you weren't reporting to the CEO, you were reporting to the CFO because you were seen as an expense, right? You are a facility. But I think we're now starting to see more CIO or GM of IT roles reporting to a COO or somebody who runs a core part of the business from an operational perspective. I have definitely seen this happening in the utility industry, 

We recognise that they are here to service the COO or service the operational side of the business. If we get that and it occurs correctly, then the COO (or part of the COO's organisation)  should own that end-to-end view of the business and how tech might operate across it and enable process improvement; not just see it from a technical perspective. Does that make sense? 

Question  - David. Absolutely. I think that's a great point. What are you seeing where they've got failing projects or failing programs? What are the reasons and what can they do to rescue them? What are some of the things that they should be thinking about to turn those around?


The business case


Answer - Clive. Well, I think, I think there are a couple of key points. One is to re-evaluate what are the business outcomes that you're actually seeking to achieve from the program. Often two things happen. One, they're not clear enough at the business case stage. They are simply too vague. You know, we're going to get a 1% reduction in customer churn, or we're going to reduce operating costs by 0.3 of a per cent or something.

Quite often it's a very long bow that has been drawn to come up with those numbers. The problem with business case numbers is once they're committed to paper, people think that there's some truth behind them when often they might have just been plucked out of the air on a Tuesday afternoon to get the business case moving. So I think re-evaluating the business outcomes is crucial, were they clear at the outset?


The importance of dependencies


Once you've got them clear at a relatively high level, the second thing then to do is to understand what are the dependencies to actually achieve those business outcomes. The technology implementation will only be one part of that. If you think about it, if you want to get a 1% reduction in customer churn, the number of things you need to get right to achieve that is going to be considerable.
What are the processes, and what are the policies? How are we dealing with our customers? It won’t be just what CRM system is being used. So it's really understanding all of those dependencies and putting metrics around them, a timeline and ascribing business owners. So all the measurement and control you put around the technical aspects of the project you also need to do with all of the soft aspects; the process change, the people change and so on. 

The whole thing needs to come together. Often, you'll talk to a business, it could typically be two years after the implementation and somebody from the board will say, well, where are the benefits we were promised? Not only did they not occur, but nobody knows why they didn't occur. That's because they didn't plot out all of those dependencies. That's the first thing I'd be doing. 

The second thing would be to say if the business outcomes are reliant on the dependencies and one of the key dependencies is the technology we're proposing to implement, will the technology actually deliver fully against the business requirement? Because often that's not the case. The business case ends up moving away from what the technology will actually enable from a business perspective to a selection focused on technical risk, for example, an upgrade, or technical compatibility.

Scope change

So the project kicks off and the technology seems to meet the business requirement, but when you evaluate it in a hard way, you find that there are a few key capabilities that are just not there. This means you have to go to more technology to bridge the gap and it just starts to get unwieldy. Then as we all know, in projects when the project starts to become difficult, the business starts to push back a bit. The timeline might have started to ease out a little bit. 

Suddenly everybody is under pressure and feeling nervous, and in the face of timeline slippage and increased costs,  the benefits suddenly go out the window, and it's just, how do we get this thing in?

So it's making sure that every change that you do in the project, whether it's to push the timeline out, whether it's to alter the scope, whatever it is, you have to relate it back to those original benefits and say, what are they, what is that change going to do to the benefits? If it's not going to improve the benefit, then why do it? If it's going to have an impact on the benefit, then what is it and how do we manage it?


I think the third thing I'd just throw in here because it's dear to my heart, is understanding who's accountable for what in terms of the program. Often, people are confused about what the System Integrator (SI) is actually going to deliver and who is actually accountable for the business outcomes.

Often the business will overestimate what the SI is going to do and there is a disconnect between the two. Businesses will find themselves becoming the system integrator even though they didn't intend that to occur. There's a gap that was not addressed at the contract stage of the project and at the end and the business has to pick it up. This is a big problem because very few organisations have the skills or capacity to be their own SI.

Many project managers will tell you, and correctly so, that the success of a project is determined by what happens at the set-up stage. Do we understand the business outcomes we want? Have we mapped all the dependencies to achieve those outcomes, and is it clear who is going to deliver each of these dependencies?

I often see organisations where these programs are so large and so complex or end up being so because of poor set-up, that the senior leadership team have moved on before the program has finished. And that is certainly the kiss of death, because nobody's accountable for the outcomes of the current project and the whole merry-go-round starts again, doesn't it?


David. Thanks, Clive so much for your valuable insights today. I’m sure many of our readers will find lots of great takeaways here that they will find useful for making their transformation projects much more successful.


Get in touch


Clive is an Independent Transformation Program Adviser, working with CEOs, CIOs and other Senior Executives to ensure that their transformation program delivers the intended benefits and business outcomes.

With 25 years of working as a Practice Leader, Industry Leader, Program Manager and Change Manager for a number of consulting firms (PwC, IBM, Capgemini, Wipro), he has a deep understanding of what makes IT enabled Transformation Programs successful.

He can be contacted at: https://www.linkedin.com/in/clive-ewin-7b88a09/