Episode #363 10 Steps to a Positive ROI in your AI and Tech Investments

IT PROJECTS HAVEN’T CHANGED MUCH

40 years ago to the day, I started my professional career when I walked into the State Bank of New South Wales as a newly minted trainee computer programmer.

Since then, I’ve been involved in IT projects of all shapes and sizes. And I’ve participated in many different capacities: as a coder; a business analyst; a project manager; a Chief Information Officer; a CEO; and a steering committee chair.

Today, virtually every organisation is racing to adopt AI. And, although AI offers the promise of groundbreaking productivity, the projects required to deliver it will suffer from exactly the same problems as every other IT project I’ve seen since I entered the industry in 1985.

In this newsletter, I get beneath the surface to explore the fundamentals of IT projects and reveal the root causes that are likely to make the difference between success and failure.

I begin with a couple of war stories from the IT projects that I’ve been involved in over the years; then I’ll give a brief summary of an interesting article that I came across about the root causes of IT project failures; and I’ll finish with 10 specific remedies that are going to massively improve your probability of IT project success.

THE ODDS ARE STACKED AGAINST BIG PROJECTS

In the 1990s, my roles as a project manager and project director for large scale IT projects gifted me a period of accelerated learning. This was what I did for a living, before I started my executive career with my appointment as CIO of an ASX top 50 listed mining company.

There wasn’t much I didn’t get to see. Some of the projects I ran were incredibly complex; but at the time the decision was made to invest in them, this complexity was poorly understood.

The projects tended to be driven by technical IT people who, in turn, had a poor understanding of the business objectives.

It was tech heads doing fun stuff with technology.

On the really big projects, control was often handed over to external service providers, which were euphemistically called implementation partners.

The big ones, like Deloitte and Accenture, understood one principle really well: at some point, every project gets to the stage where it feels like you’re too far in to go back, and the only way is forward.

They were also well aware of the fact that their own people had experienced dozens of IT projects, whereas for each client team, it was likely to be the first and only big IT transformation that they would be involved in, in their whole career.

The same executives who were blissfully unaware of what they were getting their organisations into, found themselves between a rock and a hard place. Sunk cost fallacy was rife, and project budgets and timelines blew out to the point where any ROI that might’ve initially been imagined was a distant blur in the rear-view mirror.

This made the implementation partners very wealthy, and left a proverbial trail of corpses on the side of the road.

In big business, very few IT projects are a genuine success, regardless of all the bullsh!t propaganda we see on LinkedIn about “on time, on budget delivery”.

For smaller businesses, though, IT is a little easier, because there are lots of excellent plug and play options. Software as a Service (SaaS) dominates the SME landscape today. For example, it’s both easy and inexpensive for a small business to have access to industrial strength CRM and e-commerce platforms.

But I had my fair share of project challenges. With one project in particular, I had to recommend to the steering committee that it put the project out of its misery… despite the fact that I just relocated cities to take on the job, the project simply had too high a risk profile and too little likelihood of ever providing acceptable returns.

So, I reluctantly put myself out of a job because it was just the right thing to do.

EVEN THE BEST IT PROJECTS AREN’T PERFECT

One of the better projects I was involved with was the core system replacement we undertook at National Transport Insurance (NTI). It was far from perfect, don’t get me wrong… and there were many casualties throughout the process.

But this was where I learned the most about how technology investment could help to drive business performance.

NTI specialises in heavy motor vehicles: trucks and trailers. And it has a unique market position which provides a competitive advantage over the broad-based general insurers that it competes against. A classic Michael Porter focus strategy, which gave rise to the project name, Project Focus.

I came into the company in the early stages of project planning and took the investment proposal to the NTI board. At that particular point, it was a relatively small company with only about $150 million in annual revenue.

As such, the board was mindful of not over-investing its capital, and rightly so. We proposed a bespoke development, as opposed to using an off-the-shelf product suite. We were only asking for about $12 million. But let’s face it, there were cheaper options and the board favored those options.

This was a really good board. And the further I went through my career, the more I appreciated how good it actually was.

For my part, I had deep experience with projects of this type, and I had a great team behind me. But this really was an all-or-nothing deal. The core systems for underwriting and claims pretty much determined the success of the business: and there was no way to replace them, other than a big bang implementation.

We managed to deliver the project pretty well, in relative terms. It was functionally complete, but it was still several months late. And we had to provide additional funding to our New Zealand-based technology partner to keep them in the game.

In the end, we exceeded the high end of our budget range by around 5%. We hit some problems in a few other areas, too:

• We had genuine issues with functional design and scope containment;
• The initial development estimates were overly optimistic and our tech partners struggled to meet the agreed schedule;
• The data cleansing and migration process was way more complex than we’d initially anticipated;
• We had to take a few shortcuts with quality assurance by compressing some of the testing cycles; and
• After we went live, the reporting capability left a lot to be desired; the company was forced to ‘fly blind’ for almost two months while the reporting system was rectified.

But these problems were minor in relative terms, and the final verdict when we look back in the years that followed, Project Focus delivered genuine competitive advantage that underpinned NTI’s growth to the company it is today, with well over half a billion dollars in revenues.

It set a new benchmark in terms of capital efficiency, too. Across my 40 years in business, I have never seen another project (in any industry, let alone IT), to put such a small allocation of capital to such high value use.

But getting it done damn near killed me, and it pushed many of my team members to the edge of their capacity, too.

WHAT DOES THE RESEARCH SAY?

I read a fabulous article in The Economist recently with the apt title, Why so many IT projects go so horribly wrong. Apparently less than 10% of IT projects meet their original estimates for cost and time, not to mention the predictable lack of functional completeness.

Gartner, a research firm, says $5.6 trillion will be spent on IT in 2025. An increasing percentage of this will be on AI projects. These come with lots of hype and a predictable sense of urgency, but there’s little understanding of what “good” looks like.

According to McKinsey, 80% of AI pilots are failing to scale. And Accenture says that only 4% of AI projects deliver noticeable productivity gains.

So, the imminent death of the worker may have been exaggerated, at least in respect to timing.

In relative terms, IT projects aren’t necessarily the worst. Only 40% of IT projects overrun on costs. This is compared to:

• 97% of nuclear power plants;
• 75% of hydroelectric dams;
• And, unsurprisingly, 100% of Olympic Games projects.

I always thought defence projects were probably the worst, and this may well be the case. But the figures are audited and reported in a way that defies any detailed analysis on a project by project basis.

Leaving aside the headlines though, when IT projects go wrong, they tend to go… spectacularly wrong!

For example, if an IT project overruns its budget by more than half, then the average cost overrun is 450%. That’s almost five times the original budget.

Why? Well, The Economist offers some pretty good reasons:

The first is a lack of standards. The IT industry has low barriers to entry, and professional standards are patchy.

The second issue is that there’s a problem with inexperience. Very few companies build good IT project capability, because the projects they take on are few and far between.

Of course, one of the biggest issues is that software is largely intangible. Unlike infrastructure projects, it’s incredibly hard to visualise and describe what the finished product should look like. This often relies on taking the I’ll-know-it-when-I-see-it approach.

Most companies also fall into the fallacy of saying “we’re different”, which leads to the fourth big problem: excessive customisation. Project Focus at NTI was a rare exception, because the company’s competitive strategy was enshrined in the system itself. But this is almost never the case. Funnily enough, though, I once had a mining executive tell me that his coal mine was completely different from another mine in the company’s portfolio, because his was an open cut rather than an underground mine.

One of the most common ailments of software projects is poor scope control. Requirements tend to be discovered as the project team undertakes the design process. And scope tends to grow out of control, unlike the more tangible project types that have finite delivery parameters.

IT project sponsors often fail to follow the old tailor’s wisdom of measure twice, cut once. And the introduction of agile development methodologies only seems to have made this problem worse.

10 Proven Strategies to Successfully Deliver Large AI and IT Projects

What do you do if you’re caught in the crossfire of an IT project? Here are my 10 tips:

1. Understand the business problem
   

   Don’t let your IT project be driven by the technical solution. It has to solve a business problem. And the benefits have to be identified and delivered just like any other investment that the company might make. The return on investment has to be there from a business perspective.

2. Model the investment on likely outcomes
   

   Don’t just consider the optimistic, best-case scenario. We know from experience that IT projects tend to blow out spectacularly, so push your IT people to build scenario plans.
   What if the project costs blow out by double? How does that affect the expected investment returns? Make sure you know what the outcomes are likely to be based on things not going swimmingly. It’ll save you a lot of wailing and gnashing of teeth later on.

3. Use the principle of minimum viable product (MVP) and then build
   

   What is the minimum solution required to deliver value? This is about two things: risk reduction and speed to market. Just as you would for any new product, get a baseline release first where you can prove the concept out in a pilot or a prototype mode. Once you know it holds water, you can apply the learnings to build on it from there.

4. Be ruthless on scope control
   

   Don’t let the scope of the design creep… not even for a minute. This takes real discipline. Everyone in the food chain is going to have a great idea for how to improve the outcome.
   Don’t let it happen. If in doubt, refer to point three on minimum viable product.

5. Don’t let IT run it
   

   As a CIO, I used to frequently say, “If I want the project to be executed more than the project sponsor, whose business unit is eventually going to use it, then it shouldn’t be built at all.”
   If you don’t have a business sponsor who’s passionate enough to put time and money into the solution, that is a massive red flag.

6. Treat the investment with the respect it deserves
   

   Realise that you have an allocation of scarce capital. Don’t take it for granted and don’t fall into the delivery at any cost mentality that sometimes plagues IT projects. Like any other investment, you’ve got to be prepared to walk away if it ceases to make sense from an ROI perspective.

7. Build a competent steering committee
   

   Steering committees can provide an essential handbrake for enthusiastic project managers who get white line fever. That is, the maniacal desire to deliver, no matter what.
   Steering committees are sanity checkpoints that let people with a little less skin in the game review the project’s progress. This is the opportunity for everyone to push their chairs back from the desk, take 10 deep breaths, and make sure they aren’t just following the horde of lemmings over the cliff.

8. Apply infrastructure project techniques
   

   Big infrastructure projects have some really useful disciplines, like stage gates and independent peer reviews. These should apply equally to any large investment in IT.
   It’s important to drip feed the cash and the approvals as you learn more about the project. Approval gates at concept, pre-feasibility, feasibility, and execution are critical to provide those sanity checks.
   This requires a dispassionate analysis of the previous phase. What did we learn? Does the business case still stack up? Does it still make sense to go forward? Should we commit even more money to get to the next gate?

9. Don’t give control to an external firm
   

   Once you hand over the keys to your “implementation partner”, they’ll do anything to keep the project going. They’ll happily ignore sunk cost fallacy, because they know at a point in time you’re going to be completely beholden to them.
   Even if their performance is terrible, your switching costs are simply going to be too high to move. This may sound a little cynical, but I saw the dynamic play out too often to not mention it as a key risk. 

10. It’s what happens after the implementation that counts
    

    The project isn’t over when the software goes live. It’s over when the benefits start to be captured by the business. Make sure someone’s allocated to report on the benefits recovery phase.
    Too many projects just limp over the line; everyone pats themselves on the back; and then the system is reluctantly adopted by the business.
    But many projects are delivered with cost overruns, less than required scope, and little verification of the promised benefits. So, it’s no wonder that many executives turn a blind eye to the benefits recovery process.

CAVEAT EMPTOR

At some point in your leadership career, it’s likely that you’re going to be knee-deep in an IT-driven transformation. And with the current AI tsunami, it’s likely to be sooner rather than later. If you don’t have project management skills, you need to find an independent IT program manager with a deep track record of delivery.

But whatever you do, don’t rely solely on vendors or consulting firms to produce the outcomes for you. Now that you know the common failure points, be honest with yourself when the shiny promise of a new IT project comes your way. You’re better off not taking the project on at all, rather than becoming another inevitable statistic of IT project failures.