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