- 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

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:

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:

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

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!

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.
Heath Gascoigne Tweet
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.

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
Heath Gascoigne Tweet
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.

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.

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