5 Lessons From Rescuing The Largest Digital Transformation in UK History

Like this Post? Share it 😁

Learn the 5 lessons from rescuing the largest digital transformation in UK history
There are a few problems with large digital transformations, especially in large organisations and government agencies. They start from the premise for a lot of development “we’re going to build a big thing”. What they do then is they spend a lot of time up front to try understanding what that “thing is”, and that requirements process can take anywhere between 2 to 5 years. Then they go in and design, build, test, then… Work out if it’s going to meet the cyber security requirements of the time and finally deploy something. In the government, they are anywhere between 5-8 years removed from the initial need. The eBorders programme (which I was involved personally called into to setup the Business Architecture, on the second attempt, some 12 months after that 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 have changed, the adversaries had changed, meanwhile hadn’t produced anything to meet that need. 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

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 XZY by 2020”.

That lies the first problem – what is “best”, and by who’s 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 the reasons transformation programmes fail is poor planning. Everyone is not one 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:I

It all starts with the VSOM (Vision, Strategies, Objectives & Measures) Map 🚀

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:

Perceived relationship transformation outcomes and business benefits

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 overtime, enable the Business to realise the intended benefits:

Actual relationship transformation outcomes and business benefits

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

Relationship between Little Why (Business Benefits) and Big Why (Vision)

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!

Project-Benefits Map

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.

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.

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 too, 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.

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.

Kanban Board

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 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 is previous post).

It is not technology that is changing, it is the business that is changing, by using in most cases, digital technology

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).

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.

3-Tier Governance Structure

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 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 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.

These a multitude of benefits of using or adopting an agile approach to developing and implementing your 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 comradery 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 look to 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.

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 my latest workshops on how to apply the 6-step agile transformation framework in my 2-day agile transformation mastermind, check here.

P.P.S If you want to join our Business Transformator community of like-minded Business Transformators, join the community on the Business Transformator Facebook Group here.

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

Share and Enjoy !

Shares
Picture of Heath Gascoigne

Heath Gascoigne

Hi, I'm Heath, the founder of HOBA TECH and host of The Business Transformation Podcast. I help Business Transformation Consultants, Business Designers and Business Architects transform their and their clients' business and join the 30% club that succeed. Join me on this journey.

Can't get enough real insights? Subscribe to Transformology®!​

We’ll send jargon free insights that you can actually use to transform your business straight to your inbox once a week. 

Work Smarter, not Harder!

Subscribe to Transformology®

Connect with Us

Trending

We got featured-How Do You Align Organizational Development Initiatives With Business Strategy

We are excited to announce that HOBA Tech, a multiple award-winning business transformation agency

Read More »
Greater London SME Awards_HOBA Tech_Most Innovative Business Transformation Solutions Enterprise_2024

We are excited to announce that HOBA Tech, a multiple award-winning business transformation agency

Read More »
What its like to work with a HOBA Business Transformator

Most business transformations fail, not because of the frameworks but due to how they’re

Read More »
Business Transformation Training - HOBA Is different

Become a Master of Business Transformation

Learn about Business-led Business Transformation
using the proven 6-step agile transformation framework
trusted by the UK Government, FTSE-100 and
fast growing companies

What's HOBA®?

HOBA® is the new way to transform organisations and the answer to the 70% failure rate of business and digital transformation projects today.

Learn more about HOBA®

Are you a consultant,
team or organisation
embarking on your
transformation and
want to move from the
model of transforming
business?

Join our free webinar
and learn ‘How to
maximum the return
on your
transformations,
improve service
delivery with less
effort, less time & cost
and increased profits!’

AGILE 1.0 ... 2.0

Successful Business Transformation starts here

More Articles

The Business Transformation Industry is Broken - Elephant in the Room 🤫
Heath Gascoigne

Business Transformation Industry is Broken

Why The Business Transformation Industry Is Broken? Before I show you how to transform your business, let’s define business transformation. What Is Business Transformation? Business Transformation is when a business changes the way it conducts business. It doesn’t necessarily change what it does, but how it does it.This can involve a change […]

Read More »
Overcoming the Business Architecture Challenge
Heath Gascoigne

The Business Architecture Challenge

Let’s start this post by defining business architecture. What Is Business Architecture? Business architecture refers to an organization’s framework. The Business Architecture Working Group of the Object Management Group (OMG), calls it “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical […]

Read More »
What is Enterprise Architecture Anyway? 🤓
Heath Gascoigne

What Is Enterprise Architecture Really?

Let’s start this post by defining enterprise architecture… What Is Enterprise Architecture? Enterprise Architecture looks at both Business and Technology Architecture. TechTarget calls it “a conceptual blueprint that defines the structure and operation of an organization”.Its aims to make sure your IT investment will help you achieve your current and future objectives at the […]

Read More »
Vector Globe Design for Business Transformation

Get content like this sent directly to your inbox!

Scroll to Top

Get a FREE Health Check of your Business Transformation Efforts

✅ Complete the Scorecard
✅ Get Your Report
✅ Start Transforming

HOBA Business Transformation Checklist

Wait. Unlock Your Business Transformation Potential!

Don’t leave empty-handed! Get our exclusive guide on effective business transformation strategies for 2024-2025. Discover actionable insights and proven methods to lead your organisation to success.

Webinar has eneded, Join Waitlist

The Webinar has ended and Please join waitlist to contact with us.

Apologies, The Scorecard is currently down!

We are working to get it restored. Leave your details below to be notified when we got it back up again!

Cookie-Man.svg

This website uses cookies to ensure you get the best experience on our website.