#187 | The Execution Gap: Why Capability Is the Missing Layer

In this special episode, we explore one of the most common organisational challenges: the gap between strategy and execution.

Many organisations invest heavily in transformation, governance, delivery frameworks, and planning — yet execution still breaks down. Decisions stall, ownership becomes unclear, delivery slows, and teams become overwhelmed.

At the centre of these recurring challenges is something many organisations talk about, but few define clearly: capability.

In this webinar recording, Fatimah Abbouchi unpacks why capability is often the missing layer between strategy and delivery — and why organisations that misunderstand capability frequently struggle to operationalise change sustainably.

Rather than viewing capability as simply skills or headcount, the discussion reframes capability as the organisational ability required to reliably deliver outcomes. Fatimah explores how capability connects governance, operations, delivery, and transformation — and why fragmented capabilities create friction that no amount of additional process or resource can solve.

The session also examines how capability gaps emerge inside planning, governance structures, operating models, and transformation programs, often without organisations realising until execution begins to fail.

If you work in strategy, PMOs, transformation, governance, or organisational leadership, this episode offers a practical lens on why execution struggles persist — and what organisations need to do differently to build sustainable delivery capability.

In this episode, I cover:

2:35 The Real Questions People Ask 

6:53 Capability Versus Capacity Explained 

13:40 When Shared Tech Breaks Accountability 

15:32 Regulatory Work Spans Many Teams

24:10 A Transformation That Builds the Wrong Shape 

32:27 Three Diagnostic Questions to Take Away

39:51 CIAB and Making the Seams Visible 

And more...

Learn more about the Capability Clarity Consultation:
 👉 https://quiz.agilemanagementoffice.com/capabilityclarity

Read more insights from AMO on capability, governance, and execution:
 👉 https://agilemanagementoffice.com/blog/ 

Transcript

Welcome And A Quick Check In

Fatimah Abbouchi 0:00

You're welcome to Agile Ideas the Podcast, hosted by Fatima Buschi. For anyone listening out there not having a good day, please know there is help out there. Welcome. Hopefully everyone can hear me okay. And if you can, um just someone give me a thumbs up in the chat, please, just to make sure that I can hear you all. Sorry, that you can hear me all. And also I'd love to know for those joining us as you join, where are you joining us from? Where in the world are you from? And we've had people join for all our webinars from all over the place. So please do let me know in the chat where you are joining from. So thank you so much for joining us today. Um, thank you for being here. Let's get into what we're going to cover today. One thing I wanted to say up front that this isn't a Capability 101 webinar. It's actually a little bit of a diagnosis of a pattern I'm seeing all organizations across different industries. And I'm going to be sharing with you insights that I've seen firsthand when working with organizations directly and some practical changes for what to do about it as well, you know, tomorrow, the next day, and coming into next week as well. What we'll be covering is why most capability problems aren't actually capability problems. This is one of the things I talked about recently in a blog, and it seemed to generate some good questions. So some of those have come through today. We'll talk about the layer between strategy and delivery that no one owns, and I'll also share some diagnostic questions that you can ask of your own organizations as well tomorrow. Now, for those of you that don't know me, just a really quick note. Um, I've spent over 20 years across a number of different industries. I've lost count of how many industries at the moment. I've spent a long time in financial services, a heavily regulated organizations, and also have worked across the chasm of projects, programs, PMO, transformation. Um, and at the moment I'm doing a lot of advisory work and delivery work at the C level. The work that I do sometimes is called consulting, but the description I like to give it is um people usually work with me when they actually want to make sure something lands, and the patterns that I'm going to share with you today will come from the work that I'm seeing firsthand, not from sort of theory or anything like that. And thank you so much for everyone joining us. I can see some people from Melbourne and Perth and others coming in. So again, welcome and let's get into it.

The Real Questions People Ask

Fatimah Abbouchi 2:35

So when you registered, we asked you to submit some questions. And I read all the registration responses, and there was three things that came through repeatedly. And those three things were around practical execution, practical being the key word, governance without bureaucracy, which has come a lot from my PMO audience, and then how the PMO fits in general. So we'll touch a little bit on that as well, but we'll touch practically about the execution side and about the governance layers as well. And a lot of this capability stuff will relate back to adaptive governance and governance in general. One of the things that really was interesting to me was the fact that one of you asked, have you seen organizations successfully assign ownership to the seams? Um, and it's interesting because in the blog I wrote, I talked about like the seams, the connective tissue. And we'll talk a little bit about that in a different example in just a minute, because that's effectively where we're going with this conversation. So the last thing I want to say about the questions, and these three are three of the ones that came through, but there was about I think 15 or 16 different questions. They all have something in common. First of all, they talk about you know the how of doing things, but they also took talk about um a lot of the time questions come up about leadership or persuading leaders or um trying to just survive in the daily challenges we have in our organizations, but what they all have in common is visibility, and so the invisibility in the layers in organizations, the the things that are mostly unseen because everyone's focused on their areas is one of the layers that we're going to talk about today.

Strategy Without Checking The Tracks

Fatimah Abbouchi 4:22

So let's start with a question. How many strategies has your organization written in the last five years? And how many times has anyone asked whether the track, proverbial track underneath them would actually hold? This is this is the gap that I want to talk about today. Strategies are written in every organization of every size. As a small business, we write them as well, maybe more frequently. But the the important layer that sits underneath the strategy to make sure that it actually can be executed, or the the tracks, as I like to call it, are often not checked. And this is a really good example I'll give you of a recent organization that I have worked with in the last few years. As per a lot of the larger businesses, they go out and they spend a lot of money on bringing together some top-tier consulting firms to write a strategy paper. Strategy paper is usually 100 pages long and it articulates all these amazing things. It's like the Rolls-Royce of the strategies. With one of our clients as an example, they had the Rolls-Royce strategy put together for them, as they do all the time. As the program evolved and they actually stood up a program to deliver, what we found several years later is that the strategy they had envisaged at the beginning didn't actually take into account the maturity, the context, what was happening in the organization at the time. It was external facing and looking at the external environment and what was happening in industry. But internally, how that actually worked day-to-day, they didn't actually factor that in. So what ended up happening is not only is that strategy not being applied today in its entirety, in fact, I probably argue maybe 50% of it is actually happening and coming to fruition. But a lot of the problems they are facing now, nobody called them out when they spent all that money on the strategy. So that's just one example that I thought would be really relevant. But have a think about your own organizations and uh how many strategies and strategy resets and quarterly plannings and annual plannings that we do around strategies and how many of them actually stick. I can tell you as a small business, we rewrite our strategies frequently and we have to adapt. So imagine the larger organizations as well.

Capability Versus Capacity Explained

Fatimah Abbouchi 6:53

So capability itself doesn't live inside the functions of the organization. I believe it lives in the handoffs between them. And the handoffs between the functions is the layer that no one owns. That's that's that's what I'm suggesting here. Every time we look at this and every time we think about it for the rest of this conversation, I want to think about that practical layer for what we do about it. I also want to say, because in some of the questions that came in in the registration, is that capability isn't capacity. Capacity is how much you can do, your team, your department, your organization. Capability is whether you can actually deliver. And in order to deliver well, you need to be aware of the handoffs between the functions, which is where I think we'll spend a lot of time talking about today. Now, most organizations will probably, and most of you on the call today, will probably go, Well, we've got capability. And I appreciate that. But I want to be honest about something. Uh there are enough webinars out there and conversations about this is broken and this is dead and all of that fun stuff. This is not about your organization is broken. Every organization that exists exists for for various reasons, and they're still standing for various reasons, and that's because they've got you know brilliant people doing things, mature functions a lot of the time, sound strategies, sometimes some areas weaker than others, yes, that's normal. But what I do find is that it's not that they're missing the capability necessarily, although sometimes there are some gaps, especially when organizations, for example, we've got one client who in recent years has acquired another business, and so they're bringing in new capability. Remember, capability is what your organization does. But what they're missing is the layer that connects the capability they already have. A lot of organizations I find, especially when we go in and do diagnostics and discovery, they have the things in the business. They just may not be organized very well. They'll have functions running, they have mature um functions in a lot of instances. You know, they have the right people, but those people are capable most of the time. I find there's usually just a few bad eggs. The strategy that they put together, as I said, especially when they're spending a lot of money on it, um, I find that the connective tissue that sits between and the hand offs between the functions, thinking about it, um, the visibility across silos, you you see and hear a lot of content that talks about silos, silos, I lo silo. Well, when you think about organizations themselves and the way they've they've been established, they they're gonna forever and a day have silos. You you can't get away from that necessarily. So the the piece that's missing is the thing that connects it all together. Now, the connective tissue, the bit that holds everything together, no single function owns handoffs. It's not like something that exists today. And so, therefore, no single function fixes it. And so that's the gap. And when you can see that gap clearly, it's actually something you can solve for. And that's something that I want to spend some more time talking about.

The Train Analogy For Organizations

Fatimah Abbouchi 10:12

But let me give you a practical example. I want to use the train analogy. I was thinking about what sort of analogies I've worked in about 25 industries, and I didn't want to pick one that was too too broad, um, but something that I think we can all relate to, especially with cost of living. A lot of more of us are catching the train these days. So for a minute, humor me and think of your organization as a train. Now, most people, when they hear capability problem, will probably point to one of the carriages. You know, say that you work in the um in the sales and marketing team, or let's say that you work in the growth team, or you work in IT, it doesn't matter which function you work in or where your team rolls up. Most people, when there's a problem, will actually point at a particular function. They'll say things like um customer service is the problem, or it's tech, tech always gets blamed, tech's always the problem, or uh it's group risk and compliance that's the problem. But when I walk into organizations, especially those are well established that are more mature, then maybe they realize, it's not that the carriages are the problem. The carriages are typically fine, and of course, there's always room for improvement. The carriages themselves, um, using this train analogy, are full of capable people and they're doing capable work. What's broken is in between the train connecting the carriages is something called couplings. There's a lot of other names for it, but the couplings that actually hold the train carriages together. So when you think about that, you've got your couplings that hold the trains together, not owned by any one function, and then you've got the train tracks or the rails. And the rails themselves, to me, are the enabler functions that support an organization being able to meet its strategy. So using the train analogy, your functions are the carriages, the couplings are the handoffs between those points, and then the rails are the enabler functions. The enabler functions are those that contribute significantly in various ways. And as I spend a lot of time in projects as an example, you have dedicated SMEs that provide input from Legal, Reg, HR, RISC, etc. So capability isn't the carriages. The carriages are usually fine, as I said. It's the couplings and the rails. So if I use the train analogy again, the capacity is the number of trains at this Flinder Street station, and the capability is whether they'll actually arrive to where they're supposed to be going. And so this these two parts, the connective tissue, the couplings that sit between the carriages and the rails, are the two most neglected parts I've seen in all the organizations I've spent time in. And as I said, they're not usually owned, particularly those kind of connective tissue, the coupling points, they're not usually owned by a person, a particular function. Now, if I think about some of the reasons why, well, when you think about you know traditional documented functional organizational structures, even when we look at sort of their accountability matrices, your roles, accountabilities, your responsible, you know, your races, these land on functions. And then when you think about job descriptions, they're typically tied to functions and teams. Performance reviews are tied back to functions and teams. So it's the default assumption for us not to really pay attention to the couplings that hold the train carriages together. And when we think about the enabler functions, often they're a little bit neglected as well, is because they're treated like carriages.

When Shared Tech Breaks Accountability

Fatimah Abbouchi 13:40

And so a good example of this a few years ago, probably about five or six years ago actually, with the big rise of agile ways of working that at least happened here in Australia, there was a number of large banking and financial service organizations that undertook a very, very similar approach in terms of their agile transformation. Why do I say that? Because I've not only seen firsthand what they were delivering to, uh, having coming in after the fact, but also the blueprints that they were using were very similar. And what they found was after they had designed their organizational operating model and they put this overarching structure in, their lines of business change, the way that they group things, their terminology, all of that fun stuff, they came to head with the problem. Now, one of the banks I was talking to found that a lot of the work that they do around their payments, this payment side of their business and the payments technology, they all centered on what they referred to as the payment switch. And so without getting into technical details, one of the carriages was the owner of this payments technology. But the payments technology was used by so many carriages. And what they found was with so many carriages leveraging that technology, the person that owned one of the carriages wasn't actually getting the visibility, and therefore how couldn't they be held accountable? So they introduced a number of different models. One of the ones that was very common was they introduced a concept that went horizontally across their organization. And they did that after realizing that there was a problem. And so they actually introduced enabler functions after the fact. It was just something that I seen in banking that I thought was quite interesting, and I'm sure there's many other examples of that. I want to give you another really relevant example.

Regulatory Work Spans Many Teams

Fatimah Abbouchi 15:32

So I've spent a lot of time in regulatory and compliance environments, especially when you work in banks and financial services, the aviation industry, there's a lot of regulation. Every business has it. In our small business alone in the last month, there's been like three new regulatory obligations we need to meet. So using this as a using this example, when you think about something new that comes in, so new regulatory obligation comes in from you know any any um any jurisdiction, any relevant obligation, whether it's um payday super or whether it might be a new law about remote working or whatever it might be. This obligation comes into an organization and most people will assume that it's owned by a regulatory team. Now, realistically, I have not seen in any of the organizations I've worked in a regulatory team as such. Really, they've got multiple teams or multiple carriages that are contributing to regulatory compliance management. You've got legal, who usually interprets the obligation, operational risks manages the controls, you've got the BAU teams that operationalize it, you've got technology who build the system change. There's just so many components. And all of these different carriages hold team members and functions that do this work. So you've got six different perspectives, you've got six different priorities, you've got six different strategies, and none of none of them are held together, typically because the couplings aren't clear. And when they are held together, um it's done pretty loosely and without really um a concerted effort on how those two connect. Where I see it that is very different, and this is where I do see it more practically. Running regulatory transformation programs, as a program manager, you actually do need to go into that detail and you do need to make sure that the couplings are there. So I find that projects and programs do it a little bit more than BAU, who are usually focused on their individual area. You know, think about like how many times some of you may have sat in a steering committee or in an executive meeting or received an email that notified you that there was a regulatory problem, and what and what if effectively was the outcome. I'll give you an example of something that happened in recent years. So we were working with one of our clients, and the CFO was notified of a very serious breach of something that they should have been compliant with, and they weren't. So the CFO then messages the general manager, and the general manager then messages the heads of, and then the heads of the departments manage message the senior managers, and then the senior managers message the um their teams. And by the time it sort of filtered down, you've got legal going off and figuring out something, you've got Operus doing, you've got tech looking at the technology, you've got that everybody is off distributed trying to solve for this one problem. So when you've got six different teams trying to work to solve one problem, you can understand why productivity wanes, why you have more challenges, why there's more gaps. And that's because there isn't a single regulatory team to bring it all together. Now, think about the same breach with this example I gave, but imagine this time people aren't scrambling. You already know which carriage it came from, you already know which coupling between the carriages was the failure point, you already know who owns the response, whether it's to the regulator, internally, to a group, um, to a board, whoever. Why? Because you've mapped all of that up front. You know that before it happens, not after. And that's a faster response. It's more visibility, going back to the question we started at the beginning, and it's greater clarity. And that's a different kind of organization. And when you apply that lens, which is what we do with Kayab, which I'll talk to you about, that builds and provides so much more clarity and the necessary governance layer and the necessarily integration points between the functions. And it is amazing when you go into an organization and you start talking to them about the challenges they are having. And I can tell you for a fact that the challenges that you may be having in your organization are probably very similar to almost every other organization. It's the industry context that changes. But the biggest challenge, as an example, in all of the organizations that I've worked with, at least as a consultant in the last 10 years, has always been around the demand management pipeline management front door process of how work gets triaged and then distributed. And that is common in every single organization. Almost, I'd say, maybe 80% of them based on our think it was like 70, 76% of the ones that we've worked with, that that's their problem. That's not unique to their organization. What's unique is the management of it and how that gets resolved. So, like I said, I think it's really important for us to think about the couplings of how we bring those carriages together. I I am going through these quite fast, and I am very happy to take questions throughout. So if you've got questions, please put them in the chat. Otherwise, if we don't get don't cover it during today's webinar, which I do have a lot more content coming, then I will make sure I reach out to all of you within the next 24 hours to give you a personalized response on your question. So please feel free to put any questions you have and we'll try to get to them. So this is an interesting stat.

What Healthcare Handoffs Get Right

Fatimah Abbouchi 21:11

So this is from the Australian Commission of Safety and Quality in Healthcare. I spent a bit of time working in the private in the healthcare sector, both in the NDIS space, but then also in private um private hospitals. And it was really interesting because the Australian Commission on Safety and Quality is a body that tracks psychentinel events in the Australian hospital landscape. And so that is tracking the most serious things that can happen in a hospital. And what they found was that over 60% of those events, serious, very serious events, involved communication failures, predominantly at the handoff points. And what the Australian healthcare industry did about this is they named the handoff as part of the failure modes that were applicable, and they Made it, they made it into some national standards. So I won't pretend that I know the standards inside and out, but there is a couple of standards that they developed, and they are standards that are now applicable across all Australian hospitals. And it's so interesting because as I was doing some research in the lead up to this webinar and reading about some of the standards, one of them is called ISOPAR. And in reading through the standard, and it talks about a couple of steps, and I just thought this was relevant because it puts into context if you've ever been into hospital for any unfortunate reason, you'll probably relate to this. So in this example with this methodology that they've put in place, you typically, as the practitioner, you'll identify yourself and the patient, you provide context on the situation, you provide this is all at the handover point, you provide your observations, which is a factual baseline of where you are, you provide the background and also the agreed plan, being it the next steps for that day, that hour, whatever it might be, and then you provide a readback, which is um summarizing. Now it's interesting because when I recall going to hospitals and I see, and I've got a lot of nurses in our family as well, and you watch um when the shifts change, you see this pattern actually recurring, and it makes for such an efficient way of handing over between teams. And we don't do anything like that in corporate. Most regulated organizations haven't even named the handoff as a failure point yet. In fact, like I couldn't really see that much to actually articulate it in any other way than to try to use this analogy of the trains. So anyway, I just thought that was really interesting. And it's so interesting because in Australia now they've got like a national accreditation for this whole handoffs piece because they understand how important it is. Um, and it's really important for us as well. I'm curious, have anyone has anyone come across anything else that relates to handoffs, whether it's a methodology or whether it's a standard or anything like that? If you have, please put it in the chat. I'm always curious and always keen to read these sorts of things.

A Transformation That Built The Wrong Shape

Fatimah Abbouchi 24:10

So, using that example, um thinking about um one of my clients in the energy sector as well, I thought I'd give you a practical example of something that happened for them. So I went into an organization, an energy sector, in the energy sector, and when I went in, they had already attempted a transformation, and they their words, their words to me was that the transformation had failed for a couple of reasons. One of the reasons was they outsourced it entirely to a third-party consulting firm and they didn't actually leverage a lot of their internal teams. And secondly, also because the structure that they put in place, really, when I think about it, they built a carriage out of something that was supposed to be a track. And I'll give you an example of that in more detail. So, in this energy retailer, they had sort of about three or four, I think maybe it was three or four, maybe five capabilities running end-to-end across their whole customer life cycle. So, from someone signing up to become a customer of theirs all the way through to paying their bills and then maybe dropping off offboarding later. And in that process, they had defined regulatory and legal stuff. So it was really the legal team, but they were doing the regulatory work and they actually popped it on the back end of their train, their proverbial train, and they listed that train as a carriage. Now, legal and regulatory, I think we all can understand and agree, doesn't sit at the end of a customer journey. They sit across it. So does HR and RISC and finance. They're not carriages, they're more like the rails that the train runs on. And so they thought that they had a capability ordering problem at the way that they structured it, but it actually was a structural misclassification problem. And what they'd done is they'd built a carriage out of something that should have been a track. Pictured on the left-hand side as an example. So what we found was that as long as legal and regulatory was treated like that, the handoffs were never going to work. So even regulatory obligations that they needed to meet that touched every single carriage in this proverbial train wasn't working. It actually not only was it getting, was things, were things stalling, but they also weren't even getting their time and attention deserved. The second thing I'll say about it is what other thing we notice, and the other reason this was a problem, unlike in every other carriage or function of this organization, when things came, when it came to regulatory obligations, 99.9% of the time, they're not optional. You don't put them into a backlog and decide if you're going to do them. You have no option. It's just how you make sure you've got the freed up capacity to deliver. And so that was another challenge as well. So what we had to do is actually take the regulatory legal component off the proverbial train and actually put it, put it underneath as a rail. Now, um pictured on the right-hand side is HR, risk finance, regulatory legal. Now, these are layered effectively on top, they sit all the way across horizontally because they're what I call enabler capabilities. And I've just pictured them next to each other just to give that example. But what we found is that by embedding regulatory legal as an enabler capability from the start, it aligned decision making, it was faster, it was clearer accountability and shared responsibility. And it actually meant that work flowed faster. Not only did work flow faster, but as an example, the whole structure itself, not just that one change, but by introducing this flow and connecting the trains and the um couplings between them, it meant that product teams, for example, instead of spending weeks, they went from spending two weeks trying to socialize the product and product design with the broader stakeholder groups. We were able to reduce that to two days. Their enterprise PMO in this organization took a little bit of time to get to where they needed to be, but they basically had to flip the way that they operated. They had to, I hate to say the word modernize, but modernize and become more of an adaptive governance oversight function and support them in a better way. So rather than the governance driving everything, they actually supported delivery across all of these functions better. We also removed categories of work. So at one point they had sort of 15 different categories of work. They were able to consolidate that to seven. And also the best thing that I found was one of the most rewarding for this organization, which was about 500 people. They were able to rotate people around between carriages a lot better. And so they had people that were cross-skilling faster and in a more consistent way. Why? Because they had clarity around how the capabilities worked for their organization. So faster learnings, easier to deploy, and easier to plug capacity gaps when they brought people in as well. All in all, it was a really positive outcome that I think the organization itself saw. This happened several years ago, I'd say about four years ago, and I stay in touch with all previous clients, and I can say that this exact model, with maybe about 20% tweaks, has continued to withstand the same amount of change.

Fixing IT With A Clear Front Door

Fatimah Abbouchi 29:42

Another example to give you in the renewable energy sector, also energy in the renewables space, we worked with a US client who originally came to us with a problem. They thought that they needed to introduce some sort of agile project management office. When we dug under the surface, we realized actually that's not what they needed. What they actually needed was to restructure their IT. And what they had is again, they had their IT. So again, the capability or CIAB works regardless whether we're talking about a function, a division, an enterprise. It's layered. But as we went and worked with this function, this IT function, what we found was the carriages that they had in their IT function, actually, there was no handoff points. There was actually duplication happening across the board. And it was reliant on individuals rather than the processes and the structure. So we worked with the teams to actually change the way that they operated. So we had a clear front uh front pathway into IT that didn't exist before. That streamlined information coming in and also the opportunity for this the tech engagement manager to work with the business to uh clearly articulate what was needed of technology before the carriages got to work on anything. Changing that model was really, really important. And so I think that it actually enabled um some significant improvement. This exact client reached out probably about a month ago, and I think I posted a uh a testimonial from them. But the point I bring up is the things that they put in place several years ago, they're now continuing to revise and revive. So again, when you build out your capabilities and the model that you put in place for your business, you want it to be not based on the individuals because people come and go, but based on the functions themselves. I can see a question has come in from our group. So, can you clarify how is this different from value stream mapping? So ever I think everything um everything that we do um leverages like good practice that's out there already. Now, the value stream mapping concept, and some people refer to it in different ways in different acronyms like BSM and other things, these things about like workflows for sure, and it helps to map that. When we think about CIAB, it provides the layer that shows the accountability and a number of the things around it that support the system as a whole. So it's not just the value mapping of the work itself, but actually the accountability, the governance structures, the cadence, the system, all of the things that underpin it as well. So there's a little bit more, but whoever sent that question through, I'm very happy to have a separate chat to talk through the more details with you if you need to.

Three Diagnostic Questions To Take Away

Fatimah Abbouchi 32:27

So here's some questions for you. Thinking about it, take a second and um see if you can think about these um three questions. The carriages, first of all. So in your most important program right now, and I can see from this the registration, there's a lot of people involved in projects. Can you name three to five capabilities that your program actually depends on, and the single accountable owner of each? Now, anyone who knows a good racy or responsible, accountable, consultant, informed um tool, decision tool, it always um stresses you only have one person accountable. So have a think about that first question yourself, and could you answer that? The second question to think about and again to take away, and I will say we are recording this so you'll have access to this after as well, is the couplings. So for each handoff between those capabilities, who owns the handoff itself, not the function on either side, but the scene between the two. So going back to the question of the beginning, the scene that holds the two together. Now, typically, when you're involved in projects and programs, we know that there is a handoff point to BAU. And often, um, sometimes you've got BAU embedded throughout the process, so it makes it a lot easier. But while you're delivering, while you're executing the work, thinking about the handoffs points between that. Who owns the handoff itself? Can you think about that for your organization? And how does it connect to those other carriages? And then the third question: the rails. So, which of the things that you currently call capabilities are actually enablers? As I used the legal regulatory example before. These things that should be running underneath every capability rather than as one carriage among them. And these are probably more obvious to you, perhaps, than maybe some of the others. As you ponder those questions, I think what I what I want to come back to is what I started with. And that is a lot of organizations are blind to the couplings, the things that hold the carriages together. So what we're trying to do here, and what I'm trying to do here by talking about this, is to make that visible and then help to make that work owned. And this is effectively the whole point of why it's important to do what's required to make sure that the capabilities are fit for purpose for an organization and actually can not only ensure that everyone's clear on the carriages, the couplings, and the rails, but actually how it all works together in the system of work. And so um I think realistically, if you've answered those questions in your mind just now, you might think about even the second question, almost always it's not really anyone. And I say that because I feel like from seeing and speaking to people, as I said, the problems and challenges that organizations typically are facing are almost very similar. It's just the context and environment that changes. And it's very rare for us to actually spend time talking about these components between the carriages and have someone realize that actually they were doing that all along. It's often the gap that is neglected. Going back to the six functions, just as one example, they focus on their area. And I understand and I appreciate that, and that's really um honorable to think about that because that's where, as a team, um, as a manager, as a department head, where my KPIs are tied, but I think some more work can be done to actually bring together the carriages. So in your organization itself, I think that there are some subtle signals that might already be present. And I think that a lot of the time we think that the organizations are missing more data, or we need more information, or we um are missing something when it comes to that. But it's not, we don't need more data to tell us these gaps exist. They exist already. I mean, the fact that you've got a national health body who's actually got a standard associated with handoffs just shows you how important it is. The 60% statistic of problems arising as a result of communication. Well, communication between handoffs is one of the biggest gaps I see when we do undertake discovery and diagnostics with clients. We had a client recently who we were working with who was making changes within their finance division. And as they were making changes in the finance decision, they were neglecting to think about what was happening to the carriages behind and in front of them. And so there's lots of data in organizations. You've got your post-implementation review, your audit report, your compliance, your external assurance, all of these things, but they sit in the individual carriages. What's missing, I think, is the structure that maps the rails that sit underneath the whole train of your organization, your team, your function, and shows you which couplings are about to fail or have problems or have gaps or are needing some uh maintenance, if you like, before they break. And effectively that's what we've been doing with CIAB and helping clients to kind of see that and focus on that. It's not a sexy part of the business, really, when you think about it, but it's so empowering when you see the functions themselves realize that coming together and actually solving for that makes a really big difference. And sometimes it's as simple as talking about those accountabilities. So looking backwards, when you think about programs and projects, which going back to sort of my roots, you know, you have your post-implementation review, and I can say for one, I've done many of those, and a lot of the time they're neglected. Strong PMOs will actually make sure that the learnings are embedded and at least taken into consideration of any similar project or program if you fought. Unfortunately, not all organizations do. Looking forward, when we think about strategies, as I said, if you are responsible or involved in writing strategies, not only developing the best strategy you can, but think about whether or not the track that sits underneath that enables your organizations to succeed can actually support the strategy that you're putting in place. If you're working with your third-party consultants, um, even working as being both on the on the consultant side and being on the client side before, I implore you to make sure that they've taken that into consideration. Now, depending on the scope of work, they may be able to take that into consideration a little or a lot, but I think it's really important. Otherwise, you'll end up having a strategy that just gathers dust. So we need to think about both backwards and forwards, and those two things together will help you reduce the rework and effectively um increase the productivity of your teams. And that's what we're trying to do, prove more of and test more of. As I said, a lot of what I'm sharing is just insights, and I'm continuously learning and sharing those insights in you know our blogs and other things like that.

CIAB And Making The Seams Visible

Fatimah Abbouchi 39:51

So effectively, that's what CIAB or Capability in a Box is for. Um effectively looks simple because it is. On the surface, it's very simple. But what's underneath all of these things is effectively what is the work that needs to be done to help bridge those gaps. It's think about it this way it's the functions, organizational design, the way that businesses are structured typically, that hides the couplings and it hides the handoffs points. And we need to actually take a look and dig out, dig under the service to bring those up to fruition. And what we need to do is make sure we understand how to coordinate between them. So that way the couplings actually become named, they become owned, and they become monitored. Now, let's not assume they are, because I can tell you they're often not, more often than not, but having a process to work collaboratively to tease that out and actually do that is super, super important. And so just going back to the value stream mapping comment, there's a component of that for sure, the value stream component, but the CIAB actually gives you the capability, the accountability, and actually has a regulatory line of sight. So it's factored in all the way from the starting point. And that's just because of a lot of the learnings in terms of the um, in terms of the regulatory landscape. You can't say to a regulator, like that breach example I gave, um, sorry, we you know we made a mistake because you know Jimmy was on holidays. Like it has to be really clear who owns what part of every process. And so when we think about um CIVE, we help to bring that together. As a sort of deeper example, this is like an overview of what's inside the proverbial box. It's not a tool or a platform, it's a structured way of like looking at organization. Um, what I've seen over the last couple of years is that the simplicity comes from recognizing these patterns. And some of the people in these organizations can see it, but don't necessarily have a way to solve for it. And other times they've tried to solve for it, but maybe they don't have, going back to the questions at the beginning, that sponsor support or the clarity that the capability um provides. And so this is why within the 30, 40, 50, I think we're up to 50 plus engagements in these environments, it helps to tease out the signals that you may already be seeing and actually helps you to make sure that the output that you then decide to introduce is practical. It gives you the plan that you can then run immediately on a Monday and you own that change instead of outsourcing it. And that's another thing that's really important. You need to own the couplings, the rails, the functions themselves. So I think it's really important, and it's something we're doing a little bit more pilots about because we want to learn more and get some practical feedback. So if this is something that sounds relevant or interesting, um, let's keep the conversation talk uh happening. And also, as I said, um, we can share some of the patterns we're seeing repeatedly, uh where the handoffs typically fail, um, where those sometimes there's some misrepresentation of where they apply, why things are happening and how often they're happening. Because I think sometimes when you see what's happening in other similar organizations and industries, it really does help to put into context what's happening in yours. So let me ask you a couple more questions that I want you to take away from today. So, where do you see the handoff failures most often in your organization? I think that these three questions are something that you could take away and start to address and think about with your own teams. The second one, have you ever named a handoff as a failure point or has it always been pinned on a function? That breach example, we articulated very clearly that there was a disconnect and there needed to be a better solution. And so there's some work that's been done to actually address that as we speak. The next question is what would it what would it take to make capability visible? Visible in your operating model. I hope that by the point we are now that you can see that we're not just talking about capability being people, we're talking about capability as a whole. We're talking about not only the processes, the tools, the systems, the whole capability model involves all of that, but with an emphasis on the handover points, the handoff points between those couplings that I keep referring to. So I tell you to take these three questions and think about them. As I said, I appreciate there's probably going to be questions that may come up after we wrap up today. So I would love for you to share those questions with me after the fact as well.

Where To Start And Pilot Options

Fatimah Abbouchi 44:46

So now's your turn. As I said, CIAB is something that we are spending a bit more time doing. And I want to take all of the insights I've just shared and work with organizations that are proactive and are interested in looking at things from this perspective. And I'm looking for a couple of pilot organizations that we potentially can work with this quarter and this coming quarter. And so if you are interested in learning a little bit more about it, then please reach out because I'd love to talk to you. If anything here resonated or you want to see what your own train looks like, what the carriage, what's on track, where it's not, then just book a conversation. Happy to have an obligation-free conversation. I think it would be very helpful just to have that initial chat, and then we can see if there's any alignment there or anything that would be useful. Just can see a couple of questions. Where would you actually start with this? And where is the first move exactly? So I think the diagnostic conversation would be the first best point. That would be where I would start, and the importance of that is just to actually see whether or not there's anything there and whether it actually makes sense. One of the other questions that relates to this is often the second question I can see. We're in the middle of a major regulatory program, just card work in fly. So you don't need to start with this at the beginning of anything. This can happen at any point in time. A good example of that is a recent customer who seems has just acquired another business and has realized that they've got a number of gaps. They're not sure how they're going to integrate their new business into the existing business because the new business that they're integrating is very different and operates very differently. So actually mapping out their train and actually figuring out the handoff points and helping them to assess of the new business they've just acquired what data process tools that they bring over and what they actually start with from scratch. And so I think from that perspective, um, to answer that last question, you can start anywhere. It's actually better to start while you're in flight of something because it's better to start in the middle of something and fix problems you have now than let a program, especially a regulatory program, go on for a long time and then cause more problems later. So there you have it.

Closing Takeaways And Next Steps

Fatimah Abbouchi 47:14

Thank you for listening. I, as I mentioned, we have recorded everything and we will share that with you all. So for those that would like the recording, we will send that through to you. Um just to close out, I think carriages are visible, um, the rails are not, it's a design problem. The organizational charts that exist in organizations typically show you carriages, but they don't show you how the train operates. When everyone owns the carriages, they often neglect the couplings that sit between them. Within this model, just like in your carriages and your functions, you'll have different metrics and things like that in place. The same would apply in those handoff points. And that is really important. The strategies that organizations are spending time and time again on are there to help you define your destination. Where is the train going and whether the train has the capacity? But the capability itself will help you design whether you will get there. And that's really important, especially for organizations that are scaling, trying to keep up with regulatory obligations, and just trying to do their day-to-day job. And remember, your functions are just trying to do their job. That's fine, but we just need to sort of look a little bit deeper. Um, and the cost of not naming the handoff can be really painful, especially in a regulatory-based environment. So I think when couplings get a bit more attention, maybe in budgets or in KPIs, they might get more attention, but for now, we are where we are. Thank you so much to everybody. That brings us to the end. Please feel free to reach out if you have any questions. You can follow our Agile Ideas Podcast, wherever you accept podcasts, and Agile Ideas on the YouTube channel as well. I appreciate that and um hope you um had some insight from today. Thank you, everyone. 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.agilemanagementoffice.com. I hope you've been able to learn, feel, or be inspired today. Until next time, watch your agile ideas.