Introduction

Some programmes really matter and deliver enduring value way beyond their brief.

If you’re lucky in a digital transformation career, you may get 3-5 truly pride-inspiring, sometimes career-defining programmes that you reflect on with a gentle smile and inner contentment and think, we really did something special there.

In 2014, I was brought in as Programme Manager at the University of Oxford to deliver something that, on paper, sounded ambitious but achievable: a digital research infrastructure platform to give neuroscience researchers (particularly those studying dementias) better access to NHS clinical records data at a huge scale.

Of particular interest to researchers studying dementias, is the unstructured / free-text data contained in clinical observation notes, not just structured demographic data such as date of birth, diagnosis etc. Unstructured data can of course however contain highly sensitive, patient identifiable information.

The programme was therefore ambitious because of the type of data that would be accessible and its federated, pan-organisation nature, yet achievable because we had already proved the concept in a preceding programme (D-CRIS) on a smaller scale.

Two years later, we had built a secure, cloud-hosted platform — UK-CRIS — now holding records from over 6 million NHS patients. It was available, for the first time on such scale, to researchers studying some of the most complex and chronically underfunded conditions in medicine: dementia, schizophrenia, treatment-resistant depression, the full spectrum of severe and enduring mental illness.

The programme’s success led directly to a spin-out company, Akrivia Health, which has since extended and expanded those services considerably. That research platform is still running. The dataset has continued to grow. Research studies that were not possible before the platform existed are now published in peer-reviewed journals. Clinicians are making better-informed treatment decisions as a result.

I am immensely proud of those outcomes. But looking back, what I remember vividly is not the technology — which excelled. What I remember is how close the whole programme came, on multiple occasions, to not working at all. And the reasons it nearly failed, and the reasons it ultimately succeeded, are the same reasons I think about whenever I take on a complex programme now.

Here are some key lessons that stayed with me.

1. The hardest problems aren’t technical — they’re trust problems

A bird considering whether to take a seed from the outstretched hand of a human
Photo by Marek Piwnicki

NHS patient data is among the most sensitive personal information in existence. The UK-CRIS programme was proposing to give researchers — academics, in many cases without a direct clinical role — access to the medical records of millions of patients across fifteen NHS Mental Health Trusts. (This would continue pioneering work first started at the Biomedical Research Centre at South London and Maudsley NHS FT with its own data.) UK-CRIS patients had not specifically consented to their data being used for research. The legal basis, the ethical framework, and the technical architecture for doing this safely and legitimately at scale had to be constructed almost from scratch.

Every stakeholder in that process had legitimate concerns, and some of them had the power to stop the programme entirely. The Caldicott Guardians at each Trust — the senior clinicians with statutory responsibility for protecting patient information — needed to be individually satisfied before a single record was made accessible. The Research Ethics Committees needed to approve the governance model for the study framework and the pseudonymisation processes that would be used to de-identify data to make it safe for research but still clinically rich. The NHS Digital governance team needed to be satisfied with the data security model. Information governance leads needed to sign off the data sharing agreements. Patient advocacy groups needed to be consulted.

None of this was bureaucracy for its own sake. It was the appropriate protection for an extraordinary and unprecedented access to sensitive personal data. But it meant that the first year of the programme — before the design of any technology was finalised, let alone built — was largely devoted to building the relationships and the trust that would allow the technical work to proceed.

The sequence matters enormously and is frequently reversed in programmes I have seen since. The instinct is to start with the technology — to design the platform, select the supplier, begin the build — and to treat the governance and the relationships as something to be sorted out in parallel. That approach fails, consistently and predictably, because the governance requirements shape the technical architecture in fundamental ways. You cannot build a secure, ethically sound research data platform and then retrofit the information governance. The IG has to come first, or you build the wrong thing.

Practical takeaway: In any programme involving sensitive data — patient records, financial data, personal information of any kind — map your information governance requirements before you specify your technical solution. The IG landscape will constrain your architecture, your supplier choices, your data model, and your timeline. Understanding it early is not a delay to the programme. It is the programme.

2. If trust is the question, communication and governance are the answer

Image of a group of 8 ground satellites pointing up to the sky to communicate
Photo by Ben Wicks

On any programme, good communication is vital. But where trust is so hard earned and so key to success, abundant transparent communication becomes absolutely critical.

All stakeholders need to have high degrees of confidence that the right governance will be implemented, that controls will be effective and that policies will be followed. That means involving stakeholders in their production, seeking input through every stage and dynamically responding to any concerns raised. If stakeholders are involved in defining the governance processes that will outlast the programme, they are much more likely to keep the faith.

As a programme team, you have to be really open to listening. You have to engage proactively and be honest and open about risks and issues. If you are concerned about something, you can be certain that so are your stakeholders. Maintaining confidence means facing risks, embracing them and working collaboratively on their mitigation with ongoing dialogue.

Robust governance is key. It needs to be visible, irrefutable and compliant. When you are opening up data for secondary uses you absolutely must do things the right way. Open, transparent dialogue with regulators, patient advisory groups, experts by experience and all stakeholders involved, whether they will become users of the system or not.

Practical takeaway: Fully commit to a proactive communication strategy and a robust governance model. Invest effort in establishing user groups, a steering group or forum that has genuine visibility under the hood of the programme fundamentals. Do not hide risks and issues, you want stakeholders to be discussing any concerns directly with you, not behind your back. Status reports must mean something, not just be superficial compliance.

3. Federated delivery requires a different kind of leadership

Image of a sign saying 'Community Management'
Photo by Hakim Menikh

Fifteen NHS Mental Health Trusts. Multiple universities. Specialist information governance advisors from the NHS and from academic institutions. External technology suppliers. Patient representatives. Ethics committees. The University of Oxford’s own research governance structures. NHS Digital at national level.

No single line of authority connected any of them. We had no power to instruct the Caldicott Guardian at a Trust in the north of England to reach a decision by a particular date. We had no ability to compel an ethics committee to expedite its review. We could not direct the University’s legal team to prioritise the data sharing agreement over other work on their to-do list.

This is a defining challenge of federated delivery and it is one that many programme managers who are accustomed to more hierarchical environments find genuinely disorienting. In a traditional programme, authority flows downward from the SRO. You have governance structures, escalation paths, consequence management. When something is not moving, you can — eventually — make it move.

In a federated environment, none of those mechanisms are available in the same way. The only tools you have are clarity of purpose, quality of relationships, and the ability to make it easy for each stakeholder to do what you need them to do.

Clarity of purpose means being able to articulate, in terms that are meaningful to each specific stakeholder, why this programme matters and what their contribution to it enables. A Caldicott Guardian cares about patient safety and information governance first and foremost, not necessarily about research output. An academic researcher cares about the quality and accessibility of the data, not about procurement timelines. A Trust Chief Executive cares about reputational risk and resource demand on their organisation, not about the technical architecture. The same programme has to be described in genuinely different terms to each of these stakeholders — and the description has to be true, not just tailored.

Quality of relationships means investing time in understanding what each stakeholder actually needs, what they fear, and what they need to see before they can say yes. On UK-CRIS, we spent significant time visiting Trusts, meeting clinical leads, understanding what they were concerned about, and finding ways to address those concerns that were substantive rather than cosmetic. That investment was not in the project plan. It rarely is. It is the difference between a programme that moves and one that stalls.

Practical takeaway: Before mobilising delivery in a federated environment, map every stakeholder by their decision-making authority, their primary concerns, and what they need to see before they will commit. Then build a stakeholder engagement plan that treats each of those conversations as a delivery milestone in its own right — because in federated delivery, alignment is not a precondition for delivery. It is delivery.

4. Maintaining momentum needs focus on benefits not just determination

Photo by Debby Urken

Complex programmes take dogged persistence. So, “gird your loins“. You will definitely need a steely and demonstrable belief in what your are trying to achieve to keep enough momentum to get through the difficult phases of the work.

You have to be prepared to hear “No”. A lot. “It can’t be done”. “We’ve tried, we couldn’t get agreement to make that work.” “We love the idea but it’s unworkable, there is simply too much risk.”

When you’re trying to innovate in heavily regulated environments and achieve real digital transformation at scale, you will often meet resistance, usually founded in genuine concern over risk. That fear of risk has often bogged down previous initiatives or prevented others from starting at all. That fear can quickly become like quicksand, dragging you down and sucking the life out of any enthusiasm.

Photo by Claudio Schwarz

Those were the times when we had to put our pants on over our trousers and pretend that very British raincoats were capes. Maintaining momentum means holding on to the objectives, the targeted benefits, the outcomes and the bigger picture and keeping a steely determination to share your understanding of the benefits with everyone involved. If you can do that, you can turn those No’s to “Yes”.

Make it easy for your user base – At that time, providing the data was not enough. If your user-base is made up of clinicians and academics, you also need to ensure that part of your offering is data analysis tools that are complex enough in their analytical ability but easy enough to use. This was before LLM and machine learning had fully taken off and provided the extent of data analytics capability that we now take for granted in the AI-enabled era. As transformation leaders, we absolutely must always keep user experience and the right user journeys in focus.

Practical takeaway: Clarity of focus is key – it’s super important to prioritise what will lead to real benefits. Hold on to the targeted outcomes with steely determination. Proactively manage risk to alleviate fear and don’t let the programme get bogged down with functionality or features that will not add demonstrable benefit.

5. Some programmes matter beyond their brief

Photo by Vlad Tchompalov

At some point during the UK-CRIS programme — I do not remember exactly when — I had a conversation with one of the lead researchers who would be using the platform. They described the studies they had been trying to run for years: studies of treatment outcomes in dementia patients, studies of the relationship between mental health and physical co-morbidities, studies that required the kind of longitudinal, population-level data that simply did not exist in accessible form before platforms like UK-CRIS made it available.

They described what it had been like to work without that data. The studies that had to be abandoned, or that produced findings too limited to be clinically meaningful, because the sample sizes available through paper-based or fragmented digital records were too small to draw conclusions from. The patients who had received treatments based on evidence that was weaker than it should have been, because the research infrastructure did not exist to generate better evidence.

That conversation stayed with me. It is the kind of thing that is easy to lose sight of when you are in the middle of a governance review, or a difficult supplier negotiation, or a stakeholder meeting that is running for the third hour and producing no decisions.

The programme manager’s job is to manage the programme: the schedule, the risks, the issues, the stakeholders, the budget, the suppliers. But behind every complex programme — if it is a programme worth delivering — there are real outcomes for real people. In the case of UK-CRIS, those outcomes included research studies that could not have been conducted without the platform, findings that are influencing clinical practice, and a spin-out company that has taken the infrastructure further than the original programme ever envisaged.

That is what good delivery looks like: something that outlasts the engagement, that continues to generate value long after the programme board has met for the last time and the team has moved on to the next thing.

Practical takeaway: Keep the ultimate beneficiary visible throughout the programme. Not as an abstract concept in a business case, but as a concrete presence — the patient who will be treated differently because this system works, the researcher who will be able to ask questions that are currently unanswerable, the clinician whose decision-making will be better informed. When the governance meetings get difficult, and they will, that is what you are doing it for.

The platform is still running

UK-CRIS has evolved significantly since we delivered it in 2016. The dataset has grown. The research community using it has expanded. Akrivia Health — the company that emerged from the programme’s success — has built on the foundations we laid in ways that go well beyond what the original brief envisaged.

I had nothing to do with any of that subsequent development. Akrivia Health has gone on to expand the scope and quality of data available for research. But the fact that the platform we built became the foundation for something larger and more enduring than the original programme scope is, I think, the best possible measure of whether a complex programme has genuinely succeeded.

Not whether it came in on budget. Not whether it hit its go-live date. Whether the thing it built still matters, years later, to the people it was built for.

If you’re working on a programme where the stakes are high and the stakeholder landscape is complex — please get in touch, these are the programmes we get out of bed for.