How lean thinking reduces the risk of digital and AI projects
Every digital or AI investment in health and community services carries a particular kind of risk: budget blowouts, stalled adoption, a project that quietly fails to deliver what it promised. Digital project risk in healthcare doesn’t behave like risk anywhere else, and once you understand why, you can start managing it properly. Lean thinking turns out to be one of the most practical frameworks for doing exactly that, before you’ve spent a dollar on a system, an AI tool, or a full PMS replacement.
What the research shows
In recent years, a Danish academic named Bent Flyvbjerg has been publishing some genuinely useful research on the subject of project-related risk. A recent paper he co-authored gets specific about the nature of IT project risk in particular. While the details are quite dense, I found the findings fascinating, mostly because it provides solid evidence for something many non-IT executives have long believed; that IT project risk is in a category of its own.
Essentially, IT projects are unique in that it is inherently harder to predict the risk of significant cost-overruns, and worse, than for any other kind of investment. One way of looking at this is that IT investments are like share market investments; past performance is no guarantee of future success.
In health, that unpredictability can result in wasted funding, loss of trust and potentially reset costs that dwarf the original investment. A recent review of the National Cervical Screening Programme’s Population Based Register provides an honest review of how these issues unfold in practice. It’s a useful read for anyone about to sign off on a project decision. Even though it is at a larger scale, the same issues apply universally.
Why IT risk behaves differently
The inherent unpredictability of IT projects stems from four factors:
Immaturity: IT is still a relatively young, largely unregulated field. There is very little that is equivalent to the protections provided by building codes, professional registration, or external safety oversight.
Intangibility: Software has no physical form that can be inspected. Milestones are invisible and reported by proxy which can lead to ill-founded optimism and problems remaining hidden until too late.
Goal ambiguity: Project teams are often incentivised to “get going”. This means that requirements are rarely clear at the outset, so scope drifts and it can be difficult to agree on what "finished" actually means.
Stakeholder resistance: IT projects almost always involve significant change. They redraw workflows and can shift power, so the people affected quietly resist or disengage.
These factors are well established. What’s new is what happens when you add AI into the mix.
The indiscriminate use of AI has significant potential to magnify these risk factors:
AI is the most immature area of Information Technology and evolving much faster than the life-cycle of projects.
AI is even more intangible than traditional software, with key characteristics hidden by vendors to protect their IP.
Ambiguity is baked into AI - it is a feature, not a fault.
Much of the conversation about AI has related to workforce changes and job losses, which increases change resistance and scepticism.
None of this is an argument against AI. Indiscriminate use of AI is not going to help us, but thoughtful and strategic use of AI capability most certainly can. Because most technical constraints can be reduced by AI, essentially anything is possible. That means the organisational constraints, the process, the people, the decision making, matter more than ever.
What’s needed is a framework for governing digital and AI developments. We believe that framework is Lean Thinking.
Lean Thinking: Seeing the risk before it happens
The essence of Lean Thinking is the gradual elimination of wasted time, system overload, and outcome variability by a relentless focus on continuous improvement of processes. As we’ve argued before, technology amplifies whatever process it’s laid over, which is exactly what makes an unmapped process such a risky thing to build a project on. So, this requires us to first have a clear understanding of the desired outcome of any given process.
Applied to a digital or AI investment, that means mapping the current process before a vendor gets anywhere near the room. Where is the same information being keyed in twice? Which step depends entirely on one person’s memory, and what happens the week they’re on leave? Where do two systems already fail to talk to each other in ways that nobody has bothered to escalate? Every one of those is a risk sitting in the process today. Left alone, every one of them is still there the day after go-live, just amplified.
Defining the outcome properly changes everything. For example, if we look at a classic patient engagement process (appointment booking through to patient being seen) as a means to push as many patients through the system as possible, we will take a completely different view than if we consider the desired outcome that every patient’s needs are identified and met as quickly as possible.
Two approaches to customer service
Recently I was forced to cancel a long planned overseas trip at the last minute due to illness. I was dreading the conversation that I thought I would have to have with a person in the airline call centre. It was quite hard to find the number to call on the airline’s website, and it seemed to be encouraging me to use the chat bot interface.
So, with some trepidation I gave that a try. I’m still not entirely certain that I was conversing with a real person. Even though the chat told me I was talking to Dennis there was something AI-ish about Dennis’ responses, especially when I pressed on the issue of a credit for my flights. In the end I achieved a completely satisfactory result with much less stress than I had the last time I had to do something similar talking with a person on the phone.
Contrast that with a friend’s experience trying to get a prescription for her sick newborn in the nasty winter flu season. Her local general practice, normally a very open and responsive service, had become so overwhelmed by calls they temporarily turned off the phones. That same week St John Ambulance announced they were initiating their emergency response centre, normally only used for significant civil emergencies such as floods and earthquakes due to the overwhelming demand for services.
I don’t want to sound unsympathetic to organisations that get overwhelmed by demand. In a crisis, we all do what we must to get through it. And it’s not that health can’t plan for a surge: St John’s own emergency response centre exists because someone, at some point, decided predictable spikes in demand deserved a permanent, ready system, not an apology.
The gap isn’t capability. It’s expectation. Commercial companies build the assumption of a spike into the everyday business, because every unmet call is a lost sale. Lean thinking encourages us to thinks of spikes in demand as regular occurrences to design for, not something to deal with when it happens. After all, winter, flu season, and school holidays all arrive on schedule every year.
Same discipline, whether it's a car or a system
Lean thinking offers a framework for addressing these problems differently. There was a time when the conventional wisdom of engineers was that the highest quality machines could only be produced at great cost. If you wanted a car that didn’t break down you had to buy a Rolls Royce. Using lean techniques, Japanese car manufacturers refuted that assumption and as a result dominate their world markets today.
What would our health and social services look like if we took a similar approach to challenging long held assumptions?
The same discipline applies directly to the system you’re about to buy. When you know precisely what’s broken, why it’s broken, and what fixed actually looks like, a conversation with a vendor changes completely. Whether it’s a PMS replacement, an AI scribe, or a new data platform, you stop being sold a demo and start testing whether the tool in front of you actually answers your problem. You ask better questions, and you notice the gaps that matter to your organisation specifically, rather than the ones the sales deck is designed to skip past. That’s how you reduce IT project risk before a dollar is spent, not after.
A decision the board can stand behind
Clearly defining the problem is a significant step towards solving it. It also happens to be exactly what gives a board the confidence to approve the investment: a decision made on evidence, with a clear view of what the technology actually expected to change. That clarity, more than anything else, is what reduces the chance of your next digital or AI project going off the rails.
CIO Studio helps New Zealand health, NGO, and community organisations map the risk before they commit to a system, an AI tool, or a full PMS replacement. For a readiness framework, including the questions worth asking before you sign anything, download our eBook, Before You Invest in Digital and AI.
