#183 | Why “target operating models” fail without capability clarity - Capability Unboxed Mini Series (powered by CIAB+) Part 7

Capability Unboxed Mini Series (powered by CIAB+) #7

Organisations invest heavily in Target Operating Model (TOM) design.

New structures are defined. Governance is redesigned. Processes are mapped. So why do so many of the same problems still remain?

In this final episode of Capability Unboxed, Fatimah Abbouchi explores why operating model redesign often fails to deliver real change — and why the missing piece is capability clarity.

Most TOM exercises focus on what is visible: structures, reporting lines, decision forums, and processes. But these elements don’t create performance on their own. They are mechanisms that support capability — not substitutes for it.

When underlying capability gaps exist — unclear ownership, weak coordination, fragmented decision-making — structural redesign alone won’t resolve them. The result is familiar: new diagrams, new forums, and new ways of working… with the same bottlenecks, delays, and cross-functional friction.

This episode reframes operating model design through a capability-first lens. Instead of starting with structure, Fatimah explores how organisations can anchor on outcomes, identify the capabilities required to deliver them reliably, and then design operating models that support those capabilities.

She also reflects on the patterns seen across the series — from capability vs capacity, to ownership, regulation, and governance — bringing them together into a single insight: organisations don’t succeed because of structure alone, but because their capabilities enable them to perform consistently over time.

Whether you’re leading transformation, redesigning an operating model, or trying to make strategy stick, this episode offers a clearer way to approach organisational design.

In this episode, I cover: 

0:42 Why Capability Clarity Matters

3:05 Agile and AI Trigger Op Model Redesign

6:05 When Restructures Fail at Execution

10:27 Capability Ownership Fixes Hidden Gaps

13: Why Op Model Redesign Misses Reality

16:35 Start with Outcomes then Map Capabilities 

20:03 capability in a Box and Key Client Pain Points

And more...

🎧 Tune in, take notes, and join us in May for our live webinar event where we take a deeper dive into

Transcript

Welcome And A Note Of Support

Fatimah Abbouchi 0:00

You're welcome to Agile Ideas the Podcast, hosted by Fatima Bucci. For anyone listening out there not having a good day, please know there is help out there. Hi everyone and welcome back to another episode of Agile Ideas. I'm Fatima, CEO at AMO, Mental Health Ambassador, and your host. By now you are probably at the stage where, like myself, hearing the word capability about a million times is probably a little bit too many. Nonetheless, it's really important. So in this final episode of our Capability Unboxed mini-series, I will be talking about why target operating models fail without capability clarity. And it's really interesting. This is very uh very timely. As I was recently having a conversation with a client about some of the challenges that they are facing in their organization at the moment. And a lot of the clarity that they need is missing because they haven't thought about what their organization actually does. And so we're starting to think a little bit more about how we can help them to redefine their operating model, not from necessarily just a structural perspective, but more from a governance, cadence, roles, responsibilities, and the actual right structure necessary for them to be able to make the right decisions, but also to be able to visibly see how having those capabilities and having the clarity that underpins it is better for them and their target operating models. So let's get into this episode. Let's talk about why target operating models fail without the capability, capability clarity, and um close out this series that has been an interesting one. I hope you found it interesting as well. It is something we're spending a lot of time talking about. So I'm uh will be happy to have just a little break from using the word capability. That being said, it seems to be something that is part of the day-to-day here at AMO, and really it comes down to the heart of everything that we're doing and helping organizations to plug the execution gap. So let me explain a little bit more about why many target operating models and exercises associated with that, particularly when it comes to strategizing and developing our target operating model, or maybe during transformation programs where they're revisiting their target operating model. I've seen a lot of different approaches. And even in the last sort of five or six years, I've seen a lot of organizations who went through and embarked on changing their target operating models as it pertained to how they were going to operate in an agile environment. And so there was this whole wave of agile ways of working, and that agile ways, ways, sorry, wave of ways of working actually was something that was quite um quite disruptive for a lot of organizations. And yes, the bigger the organization, the more they spent on that. Why am I using that as an example? Because I'm seeing the same thing happening now with AI, and organizations are spending a lot of time now revisiting and reviewing their target operating models again, but now they're fixating on how AI effectively can help either support or change completely, entirely their organization's operating model. So there's a lot of activity underway every day talking about strategy and these things. And what I find in the last 20 years spending time in organizations who have undertaken enterprise level transformation, uh, portfolio level, divisional level, every single time there's a focus and an emphasis on structure and processes rather than the capabilities. And the capabilities not being clear up front means it makes it more challenging to deliver the outcomes more reliably. And so in this last episode of our capability unbox series, I want to try to think a little bit differently about how strategy, transformation, and op model design come together. Because it's really important for us to try to evolve not necessarily what not necessarily what the organization does when it comes to doing their um strategy and their target operating models, but actually the how. And this is really important because having some um capability clarity underpinning that will make life a lot easier. So let's get into it. Now, when we think about many different organizations and the moment they reach usually annually, most organizations do their annual planning and then sometimes break it down into quarterly planning, and depending on the size of the organization, they typically approach the operating model conversation with an engagement with some top-tier consultants to help them to define and to do some market research, um, depending on what it is they're um they're trying to what change they're trying to bring. When it came to agile, a lot of um banking financial services organizations, as an example, use some of the sort of big four consultancies to help them redefine their target operating model. They brought the consultants in, they pitched, they ran workshops and they created some future state diagrams, and the organization defined some things around structures and reporting lines and different layers. Maybe they introduced some relevant governance forums, they talked about uh lines of business and a number of other things. Now that's all well and good, but then a year later, this continued to have the same problems when it came to execution. And this was consistent messaging that I not only heard but saw firsthand in a number of organizations who had the same problem. Fatima, the strategy is great, but we're not actually delivering, or maybe not delivering as effectively as we could. And so even though the structure may have changed, the organization's ability to deliver the outcomes hadn't. I'll give you another example. So in one of the big four banks, they as well, like many of the others, undertook a few years ago their big agile wave, agile transformation ways of working. They restructured their lines of business, they restructured all of their divisions, they uh changed role titles, they moved people around, and they really tried to break apart the not going to say hierarchies because they still exist and did exist, but they just reshuffled everything and actually confused a lot of people. And then what actually ended up happening is as they progressed into delivery and they found that the noise around agile and the structure and the target operating model started to um sort of soften slightly, they noticed more gaps. An example of that was in one of the banks we worked with, they identified that where technology, for example, um payment switch technology was owned, they found that there was initially there would be ownership in a particular line of business within the structure. And then when they reshuffled everything around, it was like the responsibilities and roles around that were split across multiple lines of business. So we then had to help them think about how they introduce a chapter concept that then went horizontally across each of those um parts of the target operating model so that they could plug that gap. And then they continued to have other mechanisms that they needed to start introducing and other workarounds. And what it what we found was even though the decision governance layers, even though they looked at all of those things, they they were important, but they weren't actually the starting point for how outcomes are delivered. When you look at how, for example, there's another client we're working with, and we've had to take them back a few steps and say to them, what outcomes are you trying to deliver? And if you remember and have listened back to the previous episodes, we talked about capability being the what a business has to do or what the business does. And so even if you introduce governance frameworks to accelerate decision making, if you're not clear on what it is the business does, and I'm not just saying we're a bank and you know we provide payment services and financial services and whole client monies, no, I'm I'm talking about actually breaking down the capabilities in a way that not only your customers can understand, but actually your teams who are there to actually support cross-functionally and collaborate across the organization to deliver the outcomes. So, in this um past few examples, cross-functional coordination was very weak. The governance redesign on its own was not going to fix the issues. Similarly, to an engineering, uh, sorry, an energy company, they introduced their agile ways of working. But what they found is just because they reshuffled the structure and changed some role titles and moved a few people around, it actually didn't change the capability to actually deliver and execute. And that in turn is where the gap is. So, why do operating model redesign office often miss the real problem? Well, first and foremost, one of the challenges is the fact that the strategy is usually done in isolation of those that have to execute. And I spend a lot of time talking about that. But also the operating model redesign frequently assumes that just making the changes that that's going to somehow improve performance. And unfortunately, that's not true. There are a number of unclear gaps that sit within the organization, and one of the very simple examples that comes up a lot is the ownership of the outcome itself, especially when you have a certain capability that might touch multiple areas. For example, there might be a capability that sounds like it sits in the financial, resource, finance and finance resource management space, but actually touches risk and compliance as well. And so then, because there's confusion around where something sits, it ends up being very poorly communicated and coordinated. And that also increases the cadences that each of these areas needs to put in place so that they can try to get the outcomes that they're trying to get. In another organization, um, I also happened to be a bank. When they made their significant changes to their target operating model a few years ago, it ended up being that the organization was so disparate in the way that they were operating that if you wanted to get something done, you would have to go to the book business banking, small business banking team, and you'd have to go to the home loan team, you have to go to all these different teams because at the time there wasn't clarity on where something started and where something ended. And so trying to run projects and programs in this kind of environment was actually very complicated. So gaps exist, and not really knowing where a particular aspect starts and finishes is really difficult. Capabilities provide those sort of containers that really help you to kind of cluster the things that your organization does, and it really helps, especially when you've got multiple aspects that sit across multiple different teams. So, for example, if we think about the customer life cycle in any business, as a capability overall, that's an essential part of doing business. But aspects that relate to that, such as complaints handling, product design, they may all sit in different areas themselves. And so without addressing that underlying capability around the customer lifecycle, it makes it really challenging for you to be as operating as effectively as possible. So the capabilities themselves will help you determine the performance, whereas the structure will only support it. So, why do I like to talk about a capability first approach when it comes to op model design? So, working with a few companies at the moment, one of them in healthcare recently, they are quite overwhelmed at the moment. They've started to make changes to their business operating model, but they've started making changes based on systems and tools, which is not a good way to start. And so we need to sort of reverse the sequence. And one of the things we like to do with our capability, capability-led approach is actually start, instead of starting with the structure, begin with the outcomes. One of the things we do typically when we when we're using our capability in a box um model is we like to actually spend some time to think about and ask the organization, the teams that we're working with when we're workshopping, is what are the outcomes that the organization must be able to deliver reliably? What makes that organization, that organization itself, what are the capabilities? For example, in ours, it's um it involves at the moment we're doing a lot of transformation work, we've got a project management background, we've got governance, there's all these sorts of capabilities that we have. And then it's around what enables those capabilities? What is the outcomes that enables, uh, what is the capabilities that enable those outcomes? And then thinking about those capabilities, we we try to weight them in terms of where and under understanding what needs to be strengthened now versus the things that maybe can be strengthened later. Not all capabilities are treated equal and they're not all needing to be addressed at the same time. As a small business ourselves, we've got a number of capabilities that are ranked green because they're ready to go, other capabilities that are somewhere in the middle, and then some that have not even been developed yet, but they're starting to be things that we include in our business repertoire. Only when an organization really understands the capabilities it needs to support itself will the operating model itself stick long-term. The structure then can support the think of it like scaffolding on a house. It provides the support to be an enablement and help you with that initial starting point. Now, this also is relevant whether you're running a enterprise-wide transformation to replace your HIRIS system, whether you are establishing a new subsidiary, whether you are resetting your whole structure. And like a lot of companies at the moment, they're looking at their operating model and completely flipping it on its head because they're introducing a lot more AI and AI agent technology. So before redesigning any function, it would be really helpful to make sure that you've mapped the capabilities that are required. So, for example, if you were going to redesign your risk function, you would want to be looking at what are all the capabilities we need to make sure that our risk management function can operate effectively across all business units. The governance forums, the decisions, the process, all of those things rolled up to that certain capability. And this helps to clarify what must exist and where the individual teams should sit. It also helps to shape the operating model from the outset as opposed to having to come back and go the other way, which is not really helpful. So then when we think about target operating model in general, some of the things to think about is when you are doing an enterprise-wide target operating model, it typically produces a lot of collateral. We're talking about future state diagrams, we're talking about governance artifacts, transformation schedules to take you from A to B. You might have strategy papers, you might need board sign-offs. There's so many different things. And if we don't have capabilities to tie back to, the challenge we'll find is there will be some inconsistency across those artifacts. It is something that's really interesting because there was another recent example of a client that we had worked with who originally came in thinking that some of the challenges they were having was because they didn't have a suitable structured transformation office capability. When we looked under surface, we realized that the poor handoffs, the slow decision making, and just the general gaps in execution within their IT division were just because they didn't have the right structure and operating model rhythm and cadence. And so they needed to undertake a target operating model exercise to actually revisit that and actually reset the way that their division and the department overall worked. And we did that by focusing on the capabilities first and tying back their IT capabilities to the enterprise capabilities. So, capability clarity. What does it actually enable? When we have clarity on the capabilities, executives and leaders alike can see what's actually critical to strategy. As I said earlier, not all capabilities are treated equal. And it also helps to understand where ownership sits. We're working with a couple of organizations now where we understand that as part of some of the work that we are doing, that they are required to provide input across multiple different areas. And some of the work we're doing may touch risk or compliance or customer service or sales. And it's very difficult to get a clear view for the executives around how the teams must collaborate to actually deliver a particular outcome without having the capabilities to anchor to. So, CIAB, Capability in a Box. How does that support capability-led operating model redesign? Well, first and foremost, I talked about it in the previous episode, but within the capability in a box environment, we have a range of capabilities that sit within our ecosystem. And I'm just looking at a couple of examples now. So, for example, one of the biggest sort of challenge areas for our clients usually pertains to the planning pipeline and demand capability. And this is because organizations, out of all of those that we have surveyed over the last 10 years in business, typically find it really difficult to prioritize and manage requests that come in, whether it's challenges between business and technology teams or rolling up what they're working on at an enterprise level. It really is a challenge when you don't have clear planning pipeline and demand management processes. And so one of the chiaps or capability in a box that we have is all around planning pipeline and demand. So another capability, for example, in most businesses is managing costs or managing resources, resource experience, reporting and analytics. There's a range of capabilities that apply. What we tend to do is we spend some time actually understanding and helping clients to make sure they're clear whether they know what their capabilities are or they need to refresh them, visualize how those capabilities operate across multiple teams and the interdependencies and handoffs between them. We can then assess the strength of those capabilities, and we can do that in a range of ways, including by leveraging some of the different conservators, both in capability and in governance as well. And then we also can assess the strength of the capability and then make sure that they have a clear roadmap for how to. Work towards that plan. Not every strategy needs to be outsourced and built by a consulting firm. Rather, helping organizations and their teams collaboratively work together to reassess and revitalize the capabilities for their organization that underpins their operating model. So this itself, as an approach, is one of the key things that we do, as well as many others, that helps organizations to make sure that they have a durable operating model that's scalable and sustainable. When it comes to having an organization's ability to adapt based on new information and constant changing, changing things around us, it's really, really important that we have something to anchor to, and that is your capabilities. So capability in a box, as I said, was something that inspired this series. It is something that we've spent the last several years working on and have actually really enjoyed seeing the clarity that teams see when they realize that no, payroll doesn't belong in this part of the business, or maybe these aspects don't belong here, they belong in people and culture, or maybe the risk and compliance is better brought together because of the size of an organization. In reflecting on this mini-series that I hope you've enjoyed, we talked about what capability actually means. We talked about the difference between capability and capacity. As I said earlier, most people get capability confused and think it's about people, skills, and abilities, but it's much more than that. We talked about why projects themselves don't equal capability and how capability ownership shapes governance, why regulation depends on capability, and why ultimately operating models must be capability-led. Together, these ideas point to a simple conclusion, and that is the organizations themselves don't succeed simply because of the structure or the activities within the organization, but because they have the capabilities clearly defined that allow them to deliver the outcomes reliably. Remember, capabilities is what an organization does, and understanding the capabilities in your organization will make it a lot easier for your organization to redesign itself, to manage itself and improve itself over time. As this is the end of our capability unbox series, you are more than welcome to join us in May for our live webinar event where we will take you through all things capability powered by the AMO Way. The link details will be both on our website and also in the show notes. So thank you so much for being part of this journey with me and talking all things capability, and I welcome any questions that you have. Thank you so much for listening to this podcast. Please share this with someone or rate it if you enjoyed it. Don't forget to follow us on social media and to stay up to date with all things agile ideas. Go to our website, www.agile managementoffice.com. I hope you've been able to learn, feel, or be inspired today. Until next time, what's your agile idea?