Introduction

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 to give neuroscience researchers (particularly those studying dementias) better access to NHS clinical records data.

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.

Two years later, we had built a secure, cloud-hosted platform — UK-CRIS — 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 proud of that outcome. But looking back, what I remember most is not the technology — which worked. 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 the four lessons that stayed with me.

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

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.) Those 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 Committee 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. Procurement done well is a competitive advantage

We ran the UK-CRIS technology procurement through a formal procurement framework. We ran it properly: a full requirements specification, a detailed invitation to tender, a structured evaluation, transparent scoring, documented decisions. It took longer than a direct award or a less rigorous process would have.

It was worth every week it took.

Structured procurement frameworks (such as the UK-Gov G-Cloud) are one of the genuinely excellent procurement innovations the public sector has produced in the last twenty years. G-Cloud for example gives public sector buyers access to a pre-qualified marketplace of cloud suppliers, removes much of the overhead of a full OJEU procurement for straightforward technology purchases, and creates a compliant, auditable framework that holds up under scrutiny. Used well, it produces faster, better, cheaper procurement outcomes than the alternatives.

Used poorly — used as a rubber stamp for a supplier that has already been informally selected, or navigated without proper requirements definition — it produces the same poor outcomes as any other badly run procurement, with the added disadvantage of false confidence in the compliance of the process.

On UK-CRIS, the rigour of the procurement through the university’s formal procurement process (inTend) gave us three things that proved invaluable during delivery. First, a contract that was genuinely based on what we needed rather than what the supplier wanted to sell — because we had specified our requirements thoroughly before we first spoke to the market. Second, a supplier relationship that started on a foundation of documented mutual commitment rather than informal understanding. Third, an audit trail that meant that when the programme came under scrutiny — as programmes involving NHS patient data inevitably do — we could demonstrate that every decision had been made properly and documented appropriately.

That third point is underestimated by almost everyone until the moment they need it. When a governance review, a Freedom of Information request, or a parliamentary question arrives, the programmes that have procured properly have nothing to worry about. The programmes that have cut corners — that have awarded contracts informally, that have run procurement processes as a formality rather than a genuine evaluation — are the ones that find themselves in difficulty.

Practical takeaway: Invest in the requirements specification before going to market. Not a generic list of technical features, but a detailed, prioritised statement of what you actually need the supplier to deliver, how you will evaluate whether they have delivered it, and what the consequences are if they have not. That document is the foundation of the entire supplier relationship. The time spent on it is not procurement overhead — it is delivery assurance.

3. Federated delivery requires a different kind of leadership

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 the 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 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. Some programmes matter beyond their brief

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. She described the studies she 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.

She 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 budget, the schedule, the risks, the issues, the stakeholders, 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 are working on a complex data, digital, or transformation programme in healthcare or the public sector, I would be glad to compare notes.