Avoid Operating Model Insanity
Designing a new operating model should be an opportunity to realise step changes in performance. It should be about reducing unnecessary waste that has built up over time, finding ways to help people be more effective, and to get that extra edge over the competition. However, this goal seems to get lost in the inevitable Op Model process, resulting in poor Op Model design, excessive costs to produce and, even worse, op models that are not fit for purpose. Leaders need to take responsibility for their op models and ensure that these are produced quickly, with the right expertise, and an acknowledgment that they will need to evolve as soon as they are implemented.
To get a successful op model, we recommend the following, which we have then expounded upon below:
Seek and listen to external expertise
Bring in Op Model consultants, not delivery consultants
Avoid the Big 4 for your Op Model work
Move at speed
Focus on your outcomes
Seek and listen to external expertise
A couple of years ago we outlined a strategy for a major government organisation to move to a multi-mode delivery model, which basically meant including Agile for certain types of delivery. The business case was clear and the organisation thanked us for doing a great job. They then set about with tasking their internal team to work out the detailed operating model. We were asked to come back 6 months later to complete the Op Model design because the inhouse team ‘couldn’t make sense of how Agile would work’. We completed the model in 2 months. We then immediately kick started a pilot and training programme to help the organisation understand what their new model could and should be. Without us they had been burning money. This is not a story to brag about what a great job we do – it’s a story to flag that Op Model work, particularly in the IT and Digital space where ways of working are dramatically changing, does require specialist help. It’s a big deal – so pay for the expertise and then listen.
Another client recently made the same mistake with moving to a DevOps model before bringing us in. They explained that they had wanted their teams to own the change, so they wanted them to come up with the answer themselves. One year later they had learnt a lot about what doesn’t work and had a better idea of what DevOps meant, but little progress had been made beyond that. All they had been missing was one to two specialists to advise and facilitate discussions so that they could then make decisions and own the changes.
If someone has done it before, get their insights into what is needed. Going to conferences and hearing about the success stories isn’t good enough. For starters, the conferences tend to focus on how great it all was, but you want to hear about the horror stories. You rarely see someone standing up and telling you about how they blew it for 3 years straight, or how their underlying business model just doesn’t add up. Bring someone in who has seen it a few times and can tell you the real story.
Bring in Op Model consultants, not delivery consultants
We’ve seen organisations bring in delivery consultants to do their Op Model work, rather than actual Op Model pros. Op Model experts tend to have higher day rates. Experienced delivery consultants don’t. These delivery consultants, with their consulting toolset, are quite adaptable and can actually do a decent job getting people to produce the Op Model on time. However, they typically don’t come with deep Op Model experience, so the quality of the design and strategy are poor. This is a false economy. It’s like getting a handy man to rewire your house. Sure, they might get the basics and get the job done – but do you really want to trust in the quality of the work? A real expert in Op Models will do a better job and is likely to save you money in the longer term.
Avoid the Big 4 for your Op Model work
This is the classic one, and no doubt this recommendation will annoy any Big 4 readers. When organisations do acknowledge the need for external expertise, then turn to the Big 4. It’s the classic “let’s get in one of the Big 4 to our Op Model design because no one ever got fired for hiring the Big 4”. This is frustrating because it’s a leader actively seeking to shirk their responsibilities and the Big 4 are not the best partners for an Op Model change.
It should be acknowledged that the Big 4 can produce great Op Models, and do have some great experts to call upon. However, in our experience their outputs are typically poorer and vastly more expensive than those produced by smaller, more specialist outfits. The reason for this is simple. Due to their resourcing structure and market approach, the Big 4 preference is to put one to two specialists on the op model project surrounded by a small army of ‘bright young things’. This model works effectively for delivery projects where those bright young things have the drive and brains to make things happen. However, that is not what you need on Op Model work. You need expertise. You need people who have seen it and done it, who know what others are doing and what you need to do to get an edge. This expertise and experience is essential for foreseeing issues with the theoretical models. What happens when we put this into practice? Will there be hidden costs or culture clashes. Will we have issues finding the new skills the model will need? The one to two experts from the BIG 4 will have the required insights and capability, but the kicker is that most of their energy will be on teaching their juniors or doing stakeholder management. That’s not what you want.
The biggest problem we see with Big 4 produced Op Models is that they are predictable. These days for IT and digital it will involve a high degree of outsourcing (often with the Big 4 taking on pricey leadership roles in the ‘interim’), IT and digital organised around product teams, a SAFe or Spotify inspired Agile op model, notable ‘cost cutting’ by slashing internal heads, and usually some sort of DevOps labelled programme to modernise the IT estate. All of these things are very sensible. It’s the direction everyone’s moving in. And that’s the issue. It all sounds great and looks good on the slides, but it’s the nuances the Big 4 will miss. Is SAFe or Spotify really right for the organisation. Will outsourcing work? What’s the cultural implications? Is there a smarter model out there? Again, the expertise and experience is what you need to take it to the next level.
The answer to the Big 4 issue is to opt for someone else who will bring their A-Team and truly challenge you. This A-Team will be smaller in number, more senior, and less costly. You run the risk of being fired if it all fails – but if you do your work and vet them properly, you will find they are the right answer.
Move at speed
Organisations take too long thinking and approving their Op Model design, meaning that by the time they implement they have spent too much, become too inflexible, and quite possibly got to a point in time when the Op Model benefits have greatly diminished.
Op Model design is all about a 70-30 rule. Do not target 90-100% completion. Get 70% worked out and then move ahead at speed. You can and should then iterative the model design as you implement and learn what works. Certain parts of the Op Model will need to be more fixed, especially where you are changing roles or reducing heads, but in plenty of areas you can still make notable changes during implementation. Too many organisations seek the perfect answer on the Op Model before implementing. Why? No plan lasts first contact with the enemy. You need to iterate, so think of Op Model work as an Agile project. Get it out there, learn, update, and repeat.
One key problem on doing op model work quickly is the approval process. Given the structural implications to an organisation, you typically need to go theory several layers of approval before funding for implementation is approved. In many organisations that can take 6-12 months after the high level (and even low level) design is complete. This is madness. The world will have moved on. Approval should be fast tracked by the leadership team and take 2 months maximum. If any longer then seek a different approach. Do your Op Model changes in small iterations and by stealth. Change area by area, rather than a whole department.
Focus on your outcomes
The goal of an Op Model is to achieve certain outcomes. Clarify these up front, and then keep returning to these daily. During the Op Model process there can be a real tendency to focus on designing and implementing a new model for the sake of the model. This is particularly true of the move to Agile. People get obsessed with implementing the theory to the T, without thinking back to the ‘why’. In every op model meeting, repeat back the outcomes. Remind yourselves of who you customers are, what you business strategy is, and challenge everything in your op model thinking.
