Google ‘change management’ and you get half a billion hits. ‘Change management models’ gets 17m. Yet perhaps never in management has so much been sought by so many to such little effect. Almost all of the models referenced have one unwanted trait in common. They don’t work.
70% of all large-scale change initiatives fail, according to the Harvard Business Review. When they involve IT, the failure rate, in whole or in part, is 90%.
Why?
Well, not coincidentally, there’s something else conventional models have in common: a starting assumption that when you launch change, or more fashionably ‘transformation’, you know where you’re going. Of course you do: what leader would admit she didn’t? So change is a matter of planning how to get to the appointed destination, with a schedule of carefully orchestrated quick wins, deliverables, milestones and communication campaigns to keep programme and people on track.
But there’s a snag.
In any body composed of interdependent moving parts, change happens not mechanically but through a series of interactions and feedback loops between the parts, which ripple out and alter the whole. The behaviour of the ensemble can’t be predicted in advance from that of the components, and vice versa. In other words, change is emergent – a result, not a cause.
This changes everything.
The result is not just a different ‘change model’ – it’s a different way of thinking:
- Conventional change models come straight out of the command-and-control (aka central planning) playbook, decreed from above and cascaded down through the organisation.
- In a systems view, change is better seen as discovery, proceeding not by way of an abstract plan, plotted to an arbitrarily fixed destination, but by open-ended investigation and iterative experiment leading to deliver ever-improving outcomes.
In this latter version of the process, change starts by establishing not where you’re going but where you are now. Like it or not, you start from here, facing forward. And the only way to start the process of discovery is to go and see for yourself.
Professor John Seddon, founder of Vanguard Consultants, recounts how a brilliant and mercurial mentor noticed on one assignment how little front-line service agents could actually do for clients calling in with a problem – ‘what if we equipped them to deal with the calls that they are likely to get?’
It was a pivotal moment.
To work out how to do that:
- The first step was to listen to customers’ calls live – a revelation in itself, since the most striking thing was how many were complaints about something not done, or not done properly, on the first contact (since known as failure demand).
- Next, they had to turn that thought round and ask themselves what should have been done that would have made the follow-up call unnecessary – that is, what was the purpose of the service, from the customer’s point of view?
- Finally, they needed to know what kind of customer needs were predictable and which only arose from time to time. Only then could they proceed to train operators in a way that would reliably improve performance.
‘Go and see for yourself’ turned out to be critical in other ways:
- The root problem to be addressed, and hence the nature of the subsequent change, was never the one managers thought it was:
- The functional measures they were using – number of calls per shift, speed of response of the different functions – told them nothing about the experience of the customers, who naturally took an end-to-end view. As a result they were always surprised, and often dismayed, to discover that service that was excellent according to their (or regulators’) measures got a vigorous thumbs down from recipients.
- Conversely, the eventual benefits often went far beyond the incremental gains required by the plan e.g. huge increases in capacity by cutting unnecessary work and failure demand and steadily shrinking costs as customer service improved.
- The truth about the operational reality was so unpalatable to managers brought up on conventional methods, and who had so much invested in them, that unless they saw it with their own eyes they refused to believe it.
- It’s not that a systems view of work or organisation is harder to grasp than a conventional one; it’s that the two are so different that there’s no intellectual route map between them. They are parallel tracks with no connection. In other words, it’s impossible to convince a conventional manager to cross from one track to the other by rational explanation. They have to see it with their own eyes – the corollary being, once they have ‘got’ it, they have crossed a Rubicon: there is no going back.
There’s a rigorous discipline to ‘study’, but broadly speaking once customers have put them right about where they are, managers and front-line workers can jointly start to figure out what to do to meet the purpose of the service without recipients having to make follow-up calls to remind them. It’s only when the hypothesis has been tested in action and adjusted accordingly that it is possible to envisage what the redesigned process will actually look like.
This empirical approach to change brings two enormous benefits, one negative, the other positive:
- It prevents managers wasting large amounts of money and effort on top-down change programmes that are doomed to fail.
- It can eventually lead to the kind of gains that no one would have dared to put in a plan.
Both of these are well illustrated by the case of IT.
IT is usually presented as the ‘driver’ or ‘enabler’ of large-scale change, as in the ill-fated Universal Credit project in the public sector, and countless ‘digital transformations’ in the private sector. The assumption is that the IT system comes first and operations will automatically be more efficient if digitised. But this is diametrically the wrong way round. When managers start by learning how their system works, they usually find, again to their surprise, that a giant, all-singing, all-dancing IT system not only does nothing to solve the real problems – by locking in the old system, it is a constraint rather than an enabler.
This is not to denigrate or downplay the importance of technology – provided it is kept in its proper place, which is last, and always as an aid to rather than replacement for human intelligence.
As for any change project, the order is:
- First, study the system – get knowledge
- Second, improve the service to the customer – redesign
- Third, ‘pull’ the IT that you need – so you use it all and don’t buy bells and whistles you don’t need.
This goes for heavily IT-dependent services such as banking and insurance just as much as for customer helplines or emergency services.
If that sounds unlikely, consider the stories put forward by senior financial executives at a recent event put on by Vanguard where bank CIOs said:
- Changing rules of the game meant an urgent need to experiment with the customer journey without having a full plan, representing ‘a profoundly new world, mindset and model for banking,’
- ‘If you think of the solution as a technology thing or opportunity, you’ll solve the wrong thing or make matters worse.’
- ‘We forgot that banking is not about current accounts, it’s about accessing money and buying a home,’
- ‘It was a cost-related, industrialised approach. We had a lot to unlearn.’
- ‘Now, no one can touch anything unless they can show they understand how the system works and have experienced how the service is consumed.’
- ‘Don’t digitise what you don’t need to. Our problems weren’t caused by technology, so how can it solve them?’
Another leader in banking confessed that having joined the bandwagon to ‘go digital’ and invested heavily in new digital services, managers discovered through studying that it led to increases in failure demand into its service centres. Calling a halt to the costly dysfunction, they set about doing what should have been the starting-place – studying customer demand, studying how well the bank serviced those demands (not very well), improving the way the demands were serviced and, finally, on the basis of thorough knowledge, ‘pulling’ IT into the designs.
‘Innovation isn’t about technology. It’s about solving customer problems, and using tech to do it where necessary,’ said a South African insurance CEO who, after much heart-searching, had cancelled a big IT systems investment because she could see it was simply a modernisation of the old architecture that would do nothing to attract new customers. The breakthrough moment was a ‘what if’ question that emerged from studying the system: ‘What if we thought of our business not as picking up the pieces when things get broken but stopping bad things happening in the first place?’ Out of that came a clever initiative to use advanced technology to monitor customers’ heating boilers, triggering instant alert and repair in case of failure. ‘Insurance at the touch of a button! But it’s critical that the IT architecture supports the right measures.’
Change of this kind, as all the participants emphasised, isn’t a one-off event but a never-ending journey
What emerges is a service design that absorbs the variety of customer demand using new and fundamentally different controls which facilitate a constant focus on perfection.
Effective change starts with ‘study’, not plan.
The consequence of gaining knowledge is that change is guaranteed to work, and deliver results far beyond what might have been considered possible in a plan.
NB We have no connection with Vanguard Consultants but have always applauded their approach