Why Most University Transformation Programmes Don't Survive Year Two

August 20, 2026

A few years ago I was reviewing minutes from a project board meeting at a Russell Group university, reviewing discussion points from a room full of smart, well-intentioned people sign off on a transformation strategy that everyone in the room already knew wouldn't survive contact with the next academic year.

Not because the model or strategy was wrong. Because nobody in that room owned making it stick.

That's the pattern I keep seeing across higher education, and it's worth naming properly: universities are not bad at designing transformation. They're bad at making it outlive the programme that delivered it.

The shape of the problem

Higher education has more genuine pressure on it right now than at almost any point I've worked in the sector — OfS scrutiny tightening, funding models under strain, enrollment increasingly volatile, and a digital estate in most institutions that's been patched together faculty by faculty rather than designed once, centrally, on purpose. Every Vice-Chancellor and Transformation Director I talk to knows all of this. None of them are short on diagnosis.

What they're short on is a way to change how the institution actually works — not just what it runs on — and have that change still be there in eighteen months, after the programme team has moved on and the consultants have left.

Two gaps show up almost everywhere I look, and they rarely get named together.

• The first is a maturity gap in how the institution actually delivers projects and business change — not the technology, the discipline: governance that holds, prioritisation that sticks, and the ability to land what's been committed to instead of quietly re-scoping it halfway through.

  
  

• The second is a fit gap in the student systems themselves — the SIS, admissions, progression and awards, timetabling — where the system on paper and the system people actually trust are two different things, and registry, faculties and student services end up running parallel spreadsheets around it because the platform doesn't quite do what the institution needs it to do.

Both of those are diagnosable on day one, if anyone actually goes looking. Most programmes don't — they start with a solution instead of a diagnosis, which is exactly how you end up delivering a very well-built answer to the wrong question.

Three things kill it, almost every time:

1. Business and IT run parallel programmes instead of one. The Transformation Director designs a future-state operating model. IT delivers a platform. They meet in a steering committee once a month and assume alignment is happening because everyone's nodding. It isn't. By the time anyone notices, the operating model assumes capabilities the platform doesn't have, and the platform has features nobody asked for.

2. Change management gets bolted on at the end. A training deck in month eleven of a twelve-month programme is not change management, it's a leaving present. Awareness, desire, knowledge, ability, and reinforcement — the actual mechanics of a person changing how they work — have to be built into every stage of delivery, not scheduled as a final activity before go-live.

3. Delivery is one big reveal instead of a series of proven bets. Universities, more than most sectors I work in, are drawn to the comprehensive plan — the 40-page target operating model document, agreed once, delivered as a single release eighteen months later. It feels rigorous. It's also the single biggest predictor I see of a transformation that stalls, because nobody finds out what doesn't work until it's already built.

What "sustainable" actually requires

The framework I use with institutional clients treats sustainability as a design requirement from day one, not a hoped-for outcome. In practice that means three shifts from how most university transformation programmes are run:

1. Outcomes get defined and agreed across business and IT before anything gets designed — so the two sides are solving the same problem instead of running parallel workstreams that quietly diverge. 

2. Delivery happens in increments, with real feedback loops, so a target operating model gets tested against reality in month two, not discovered to be wrong in month fourteen. 

3. And change management — the ADKAR mechanics of awareness, desire, knowledge, ability and reinforcement — runs through every single stage of delivery, not as a phase, but as a thread. People are being brought along the entire time, which is the actual difference between a transformation that gets adopted and one that gets tolerated until the programme team leaves.

The result isn't just a new operating model. It's an institution that's slightly better at changing, next time, than it was this time — because the capability to adapt was built alongside the solution, not left for someone else to figure out later.

I've used exactly this approach inside a Russell Group university — taking a system serving 4,000 students to one serving 40,000, releasing over £1m a year in operating value along the way. The technology mattered. What made it stick from year 1 to year 4 was that the people running the system, not the consultants who built it, were the ones who understood why it worked and how to keep improving it after we left.

A question worth sitting with

If you're a Transformation Director, CIO, COO or Vice-Chancellor reading this: think about the last major change programme your institution ran. Is it still working the way it was designed to — or has it quietly drifted back toward how things used to be done, just with a new system underneath?

If you're not sure, that's usually the answer.

I've built a short self-assessment for university leaders to work out whether this is a live problem for their institution right now — covering delivery maturity and student systems fit alongside the sustainability question above — and whether it's worth a conversation. Takes about four minutes. I'll drop it in the comments below.

If any of this mirrors what you're navigating, I'd genuinely like to hear how you're thinking about it — reply here or send me a message.

Eugene James | Agility X — Transform. Enable. Deliver.