5 Lessons From Rescuing the UK's Largest Transformation | HOBA

📅 Updated September 2026. This post was originally published in September 2019, after we were called in to rescue the largest transformation in UK history. We've updated it for the AI era — the failure pattern hasn't changed, only the technology has. The five lessons still rescue programmes.

Here's the lie: this time, with AI, government transformation will be different.

It's not happening. We first published these lessons in September 2019, after being called in to rescue the largest transformation in UK history — a programme 8 years late and more than £1Bn over budget. Seven years later, the failure pattern hasn't moved. Only the technology has changed.

Now it's AI. Departments are starting AI programmes the way they started eBorders: big requirements, big builds, big surprises — at machine speed. The threats change. The adversaries change. The mistakes don't.

The eBorders programme (which I was called in personally to set up the Business Architecture on the second attempt, some 12 months after it restarted), to update the process and systems in the UK Border was 8 years late and cost more than £1Bn.

In that time, the threats had changed, the adversaries had changed, and the programme hadn't produced anything to meet that need. The five lessons below rescued a £1Bn programme. They will rescue your AI programme too — if you apply them before you buy the technology.

Here are the 5 lessons learned from being called in to rescue these large transformations:

• Know your Why?
• Share the progress, success and failures
• Transformation is everyone’s business, not just technology.
• Don't underestimate culture.
• Look for quick wins, celebrate them, and build momentum

🔍 Click to enlarge

Know Your Why?

The first thing I do when I go into a programme is understand their Why – why are you transforming? Most of that time that is clearly laid out on the project or programme brief “we want to be the best X by 20XX”.

That lies the first problem – what is “best”, and by whose definition?

When I ask the key stakeholders on the programme, from the Sponsor to the Programme Director, Programme Manager and so on, everyone has their own version of the Vision, and what it means to them.

In order for the programme to be successful, everyone needs to be pulling in the same direction, towards the same Vision, the same ‘Why?’.

Part of the reasons transformation programmes fail is poor planning. Everyone is not on the same plan; they are pulling in the wrong directions, towards their own versions of ‘Why?’.

So how do you address that?

First, you need to acknowledge there are two Why’s – the Big Why (the Vision), and the Little Why’s (the Business Benefits).

In terms of the Big Why.

You need to be clear that there is the ‘big picture’ outcome for the transformation – the “Big” Why? which everyone needs to pull together. There is only one Big Why (the Vision).

To remove any ambiguity, so everyone is pulling in the same direction, you need to break that Big Why down into how it is to be achieved (Strategy/ies), Objectives (of each Strategy), and Measures (of success, and progress in achieving that Objective).

The tool for that is the Vision, Strategy, Objectives and Measures (VSOM) Map:

🔍 Click to enlarge

Then in terms of the Little Why’s (the Business Benefits).

Then there is the Business Benefits that the Business will realise as a result of implementing the transformation – these are the “Little” 'Why’s?':

The changes that the programme delivers enable the Business to release those Business Benefits.

The current mistake in thinking is that once the programme delivers changes into the Business, the Business automatically realise Business Benefits from it looks like this:

🔍 Click to enlarge

Its close, but that is not how it works at all.

The relationship from Changes delivered, to the Business realising the Benefits from using those changes slightly different.

The programme delivers changes that create or enhance Business Capabilities, that when used by the Business produce outcomes, that over time enable the Business to realise the intended benefits:

🔍 Click to enlarge

The relationship from the little-Why’s to the Big-Why is via the Business Benefits, and the Benefits Model:

🔍 Click to enlarge

Once you identified your little-Why’s (Business Benefits), and the enablers (Business Changes and Technology) needed by the Business, in scope for the transformation, and you lay them out on the Project-Benefits Map.

By showing the indicative roadmap for implementation to realisation, what projects under that programme are delivering which changes, you start to get everyone pulling in the right direction of what those changes are, the priority changes are to be delivered into the Business, that enable the Business to achieve the Big-Why!

This is what HOBA Pro's Business Architecture software models as a living system — not a slide deck.

🔍 Click to enlarge

Share the progress, success and failures

The second lesson is to Share the progress, success and failures.

A common practice in transformation programmes right now is not admitting you don't know, or having trouble is a weakness, so what happens is when you ask for input from Stakeholders they either don't tell you want you need to know, or they don't tell you at all.

🔍 Click to enlarge

Business and Technology Architects are accused of this all the time. They hide away in “their ivory towers”, they don't consult with the Business about their ideas or understand their problems or pain points, then come out with their grand designs, that literally “took weeks and months” to put together (on their own, I might add), that the ‘work they have done took so long, and was so involved’ that no one (the Business mainly, led by the SMT and CXOs) have the time, patience or budget to allow any ‘slippage’ they are literally forced to ‘accept’ what is being presented, and collectively resentfully agree to “go with it” and adopt what they have proposed, with the hope ‘if it doesn't work, we can always change it in the end”.

Well, that approach is broken and doesn't work.

What that approach does is it results in not only lost time, money and missed opportunities, it results in key staff members, who if we’re honest, in a lot of companies are collectively the company’s competitive advantage, end up leaving the programme and the organisation. Fed up with not being listened too, trying to fit a square peg into a round hole.

The first thing I do when I go onto a programme is to admit “I don't know your Business”. Most times, I don't (intimately) know the company. But I have a process. I have and do openly admit, as I did at the last programme board I presented to, getting the TOM and roadmap signed off in record time, which I was getting praised for, that 2x Tier 1 consultancies couldn't do for 14-months before me, who I replaced. That's why the Big 4 consulting model is dead — process without ownership doesn't deliver.

I said “I have a framework, it’s your people that have the answers. It is my job to get the answers out of them”.

Part of that process is to share that process, to provide transparency and visibility of what process is, and the progress through it. I stuck everything on a Kanban (via Jira), all the deliverables in the backlog (via Confluence), and carried out daily scrums with the team, both local and remote daily.

🔍 Click to enlarge

Everyone knew the process and had complete visibility of it and could check the process and progress at any time.

Transformation is everyone’s business, not just Technology.

Technology is the enabler in business-led digital transformation right now.

The problem with this is - it is not technology that is changing, it is the business that is changing, by using in most cases, digital technology (I covered this in a previous post).

🔍 Click to enlarge

But the reality is the tail (technology) is wagging the dog. The dog being the Business. It is the Business that needs to change, not technology (that needs to change). AI is the newest tail.

What this is causing is there is an overemphasis for Technology, at the detriment to the Business.

One of the major causes of transformation failure is lack of stakeholder involvement, which when you focus on ‘technology’, you are playing into what causes programme failure ‘lack of stakeholder involvement’.

A good way to survey whether you are listening to the Business, is to survey the room of your governance boards and design authorities, and if you don't a member representing the Business, you need to make some changes.

🔍 Click to enlarge

Don't underestimate culture.

Probably the biggest understated and underestimated element in transformation programmes today is culture.

Possibly because it’s hard to measure, and because it’s hard to measure and quantify, its ignored, and mostly it ignored by ‘technology’ people, if we’re honest.

The general attitude is ‘we’re building something big’ they should be a part of it. Or rather “they should want to be a part of it”.

I have worked on some of the largest transformation programmes in the UK (some made the headlines for the wrong, and right reasons), where it is clear to all parties concerned, especially the Business who as I am often told by the SMT when I initially propose my controversial approach “Heath, the Business know what pain they are suffering, they have been living the pain for 20+ years”.

But despite that “20 years of pain” you would think that the Business would be all too happy to not ‘live that pain anymore’. Yet why do these transformation programmes fail?

Because, culturally, the Business is not used to change.

Technology is not the hard part of transformations, it is the culture change within it that helps get through these business-led digital transformations.

Years of institutional risk aversion has led to the strategic dilemma plagued today – how to replace the 20-year hardware and software, on a 2-year timetable?

You don't force the Business through the transformation, you take the Business through the transformation journey with you. I wrote about it in a previous post here.

Look for quick wins, celebrate them, and build momentum

There's a multitude of benefits of using or adopting an agile approach to developing and implementing your business-led digital transformation.

One of them is, in terms of the Business Architecture, you chunk your work up into size and packages of work that you can complete and release to the Business at regular intervals, at regular frequency – regular ‘cadence’.

The process of getting everyone, namely the Core Team to work on deliverables, that they need to engage with the Business (and Technology) stakeholders, get their input, agree the changes, and release it to the programme at regular intervals (i.e. end of sprint), helps in many ways.

It builds the camaraderie within the team, that they are focused on the ‘one thing’, to get that deliverable(s) in an ready or approved state (as defined by the acceptance criteria on the User Story card, stuck on the Kanban for all to see), distributed to the programme and Business that it allows further work to continue, but most importantly, it builds momentum.

This is what I do, once the approach is agreed, the work is already chunked up from Reference Models, to Building Blocks to Blueprints, the next steps you agree on is the Teams capacity of how much work can we get through in a week, and then go about achieving it.

🔍 Click to enlarge

You track your progress on the burndown chart (above), so you know how you are tracking, make the corrections where you need and you celebrate the wins as you hit your milestones!

Those are my five (5) lessons from rescuing some of the biggest transformation programmes in the UK. Hope you found some valuable insights.

Thank you for reading this!

Sincerely,

Heath Gascoigne

P.S. If you want to join our Business Transformation Community of 2,000+ like-minded Business Transformators, join the HOBA Community here.

P.P.S. If you want to learn more about business transformation, check out The Business Transformation Playbook here.

---

Stop Patching. Start Architecting.

If your government or regulated-industry programme is starting the way eBorders started — big requirements, big build, big surprises — the fix isn't more technology. It's architecture first.

Take the HOBA AI Assessment and find out whether you're building a programme the Business can actually own.

Stop Patching. Start Architecting.

---

Heath Gascoigne

Founder & CEO
HOBA TECH