Studying for the CAPM does something strange to you. You start seeing project management failures everywhere — in news stories, in product launches, in conversations about why things that seemed like good ideas never quite landed. Once you understand what a proper stakeholder register looks like, you notice instantly when nobody made one. Once you've studied what unmanaged scope creep costs, you recognise it in every headline about a government tech programme that ran years over schedule and hundreds of millions over budget.
Nowhere is this more obvious to me than in HealthTech. The last two posts I've written on this blog have diagnosed real problems: the structural failure of centralised health data, and the algorithmic bias baked into the tools we're deploying at scale. But there is a third failure mode that sits underneath both of those, one that rarely gets its own headline — and it is the most preventable of all. It's not a technical failure. It's a delivery failure. HealthTech keeps producing the right ideas and then executing them in ways almost perfectly designed to waste them.
The Numbers Nobody Likes to Quote
The healthcare industry has spent the last two decades attempting a digital transformation of breathtaking ambition and largely middling results. Electronic health records, telemedicine platforms, AI diagnostic tools, patient-facing apps — billions of dollars invested, thousands of projects launched. And the failure statistics are staggering once you stop averting your eyes from them.
Between 70 and 80 percent of healthcare IT projects either fail outright or fall significantly short of expectations. That isn't a fringe estimate — it's the figure cited consistently across industry research and clinical informatics literature. When you narrow the lens to EHR implementations specifically, one analysis found that roughly 60 percent fail and go 40 percent over budget. Research published in Procedia Computer Science found healthcare technology project failure rates of up to 70 percent when failure is defined to include unintended consequences like delays, cost overruns, or partial abandonment.
The United Kingdom's National Programme for IT — NPfIT — remains perhaps the most instructive case study. Launched in 2003 as the largest public sector IT project in history, it was designed to deliver a unified digital health record system across the NHS. After a decade of delays and stakeholder opposition, it was officially dismantled in 2011 with an actual spend of approximately £12 billion. No unified system was delivered. The failure has been studied extensively, and the conclusion is consistent: the technical ambition was sound. The governance, stakeholder management, and change management were catastrophically inadequate.
These are not isolated incidents. They are a pattern. And patterns have causes.
It's Not the Technology. It's the Delivery.
The most revealing finding in the EHR implementation literature is one that healthcare organisations consistently resist accepting: the majority of failures are not caused by the technology. A 2025 analysis put it plainly — most organisations treat EHR implementation as an IT project, and that is precisely why they fail. An EHR rollout is not an IT project. It is an organisational transformation that happens to involve technology. The distinction is everything.
What does a transformation require that a technology deployment does not? It requires a defined scope that everyone has agreed to and signed off on. It requires a stakeholder map that captures not just the executive sponsor and the vendor, but every group whose workflows will be disrupted — the nurses charting at 2am, the administrative staff who currently know the paper system by memory, the physicians who were not consulted on the selection and feel no ownership over the outcome. It requires a risk register. It requires a change management plan. It requires, in short, the disciplined machinery of project management — and in healthcare IT, that machinery is either absent entirely or bolted on as an afterthought after things start to go wrong.
"A system is only as good as its users. Without structured training and change management, even the most advanced software can go unused or misused."
The CAPM framework addresses this directly. The Project Charter establishes legitimacy and authorises the project before a single line of code is written or a single vendor is evaluated. The Stakeholder Register names every party with interest or influence over the outcome — and importantly, documents their level of engagement, their concerns, and the communication plan for each. The Work Breakdown Structure decomposes the project into deliverables concrete enough to be assigned, tracked, and completed. The Risk Register identifies what could go wrong before it does — not in retrospect, as a post-mortem exercise. These are not bureaucratic rituals. They are the structural supports that keep complex projects from collapsing under their own weight. And in healthcare, where the projects are complex, the stakes are clinical, and the stakeholders include everyone from clinicians to patients to regulators, they are not optional.
Scope Creep Is Killing Equity Initiatives
In my last post, I wrote about the ways HealthTech perpetuates inequity — algorithmic bias, device calibration failures, the digital divide in telemedicine access. One thing I did not address directly is why equity initiatives in healthcare technology stall so reliably, even when the intent is genuine and the funding is present.
I think the honest answer is scope creep and the absence of anyone owning the roadmap. Equity work in HealthTech tends to get initialised as a value rather than a project. Organisations commit to it in mission statements and funding proposals. But there is often no defined scope: no clear statement of what specifically will be delivered, by when, measured against what indicators. There is no stakeholder map that surfaces the communities most affected as primary stakeholders — not advisory voices, but principal parties whose requirements shape the deliverables. There is no risk register that documents what happens if the dataset remains unrepresentative at launch, or if the broadband infrastructure assumption proves false in practice.
Without those structures, equity commitments behave the way all unscoped work behaves: they expand endlessly in ambition and contract endlessly in execution. Every time a more urgent technical requirement surfaces — a security patch, a regulatory deadline, a budget revision — the equity work is the thing that slips. Not because anyone decided to deprioritise it, but because it was never formally in scope. You cannot protect something that was never written down.
"You cannot protect something that was never written down. Equity without a scope statement is just intent — and intent doesn't ship."
Stakeholders Include Patients
One of the most consequential distortions in HealthTech project management is the consistent treatment of patients as end users rather than stakeholders. The distinction matters enormously in practice. An end user is someone the product is designed for — consulted perhaps through user research, represented perhaps in a persona document. A stakeholder is someone with a legitimate interest in the project's outcomes, whose requirements formally shape the scope, and whose concerns are documented, tracked, and addressed throughout the project lifecycle.
When a hospital implements a patient portal and 63 percent of patients report not using it within the past year, that is not a user adoption problem. That is a stakeholder engagement failure. It means the people most affected by the tool were not meaningfully involved in defining what it needed to do. Their workflows, their literacy levels, their language needs, their access constraints — none of it entered the scope documentation in any binding way. They were consulted in the abstract and ignored in the specific.
Proper stakeholder analysis in a healthcare context would identify patients not as a single homogeneous group but as a matrix of distinct populations with different needs, different risk profiles, and different relationships to the system. Elderly patients are a different stakeholder group than digital-native young adults. Non-English speakers are a different group than native speakers. Rural patients with intermittent broadband access have different requirements than urban patients with fibre. A stakeholder register that collapses all of those into "patients" is not a stakeholder register. It is a placeholder.
What rigorous PM looks like applied to a HealthTech equity initiative:
01 — Project Charter: Written mandate that equity is a primary deliverable — not a value statement — with executive sign-off and defined accountability
02 — Stakeholder Register: Disaggregated patient populations identified as principal stakeholders, with documented requirements and engagement plans per group
03 — Scope Statement: Explicit, bounded definition of what will be delivered — training data composition, interface languages, offline functionality — not aspirational language
04 — Risk Register: Pre-documented risks including dataset underrepresentation, infrastructure assumptions, and regulatory gaps — with mitigation plans before launch
05 — Change Control Process: Formal mechanism requiring any scope reduction to be explicitly approved — so equity features cannot be silently dropped under schedule pressure
The Discipline That Makes Ideas Land
I want to say something clearly, because I think it is misunderstood: project management is not the opposite of innovation. It is the thing that allows innovation to survive contact with reality. The PMBOK framework, the CAPM body of knowledge, the disciplines of scope management and stakeholder engagement and integrated change control — none of these exist to slow things down. They exist because complex projects attempted without them fail at rates between 60 and 80 percent. The discipline is not bureaucracy. It is the institutional memory of every project that didn't have it.
In HealthTech specifically, the argument for rigorous PM has a humanitarian dimension that I do not think gets made enough. When a blockchain-based health record system is built but never adopted because clinicians weren't engaged in the design phase, the people who suffer most are the patients who needed the privacy guarantees most. When an AI diagnostic tool launches without a risk register that accounted for training data bias, the patients who suffer most are those already underserved by the system. When a telemedicine platform is scoped for urban broadband users and the rural access question is deferred to a later phase that never comes, the patients left behind are those for whom distance was already a barrier.
Project management failures in HealthTech are not neutral. They are not just waste. They replicate, with technical precision, the same inequities the technology was supposed to help address. The ideas are often right. The architecture is often sound. What is missing is the structured delivery that gets it across the finish line and into the hands of the people it was built for.
That is what I keep coming back to after earning my CAPM. Not the frameworks as abstract exercises — but the understanding that a well-run project is, in healthcare, a moral act. Defining scope protects the people whose needs would otherwise be cut. Engaging stakeholders gives voice to those who are usually consulted last. Managing risk means anticipating harm before it occurs rather than apologising for it afterward. The tools are not glamorous. But they are the difference between a good idea that stays on a slide deck and one that actually changes what happens when a patient walks through a door.