#184 | Why Regulatory Programs Stall After Approval - and How to Design Ones That Actually Run

In this special episode, we explore a challenge many regulated organisations face but rarely articulate clearly: why regulatory programs often struggle long after approval has been secured.

Most regulatory initiatives don’t fail because the obligations were misunderstood. They fail because the delivery model was never designed to operate sustainably once the program transitions into business-as-usual.

Using AFSL regulatory programs as a practical reference point, Fatimah examines the structural patterns that repeatedly undermine regulated change. From delivery models optimised for approval rather than operation, to obligation-led planning that fragments accountability across teams, the episode highlights why governance structures that work during a program often collapse once responsibility moves into BAU.

Rather than focusing on license interpretation or legal frameworks, this discussion centers on regulated delivery — the operational system required to embed regulatory obligations into how a business actually runs. Fatimah explores the difference between approval readiness and operational execution, why capability ownership must extend beyond the program lifecycle, and what minimum governance and delivery cadences are required to keep regulated change stable over time.

If you work in regulated industries, transformation programs, governance, or PMOs supporting compliance initiatives, this episode offers a practical lens on designing regulatory programs that reduce rework, avoid fatigue, and maintain execution long after approval has been granted.

In this episode, I cover: 

2:35 The Problem After Approval 

13:25 Obligation-Led vs Capability-Led Thinking

22:00 Drift to Breach and Early Signals

26:10 What Sustainable Operation Looks Like

31:00 Four Executive Diagnostic Questions

And more...

• Learn how AMO can help you uplift capability in your organisation.
• Download our Executive Guide 'The AFSL Execution Gap'.
• Watch the recording including accompanying slides.

Transcript

Welcome And Purpose

Fatimah Abbouchi 0:00

You're welcome to Agile Ideas the Podcast, hosted by Fatimah Abbouchi. For anyone listening out there not having a good day, please know there is help out there. Thanks so much for joining today. Today we're here to talk about regulatory programs and why they stall after approval and how to design ones that actually run. And to just give some additional context, we when we think about um, well, actually, one more thing I should just remind everyone that we are recording. So if there is any concerns or issues, just be aware that this is being recorded and you'll also have access to the video. For those who don't know me, I'm Fatimah Abbouchi, the founder and CEO of AMO, Agile Management Office. We work with executives who are accountable for complex regulator regulated change and help them see the gaps that they have, regardless of industry and size, and help them to close the gap between getting approval and actually operating sustainably. We're going to dig in today using a specific case in point, an example that would be really relevant for those of you online today, and that is all associated with Australian Financial Services License, which is some changes that are going to be really applicable in the Australian market coming up soon. But the patterns I'll talk about will be also really relevant for those operating a regulatory operating environment, but also those that are involved in some way, shape, or form, regardless of the obligations or the regulations, regardless of what country you're in. A couple of quick housekeeping notes, other than being recorded, so that we can share the link afterwards. Nothing I'm sharing today is legal advice or obligation interpretation. This is more about execution and operating model rhythms, cadence processes, more about that conversation. So on that note, let's uh dig into it. Let me take you through what we're going to cover. So we're going to talk about the core problem that we're seeing and what breaks after approval. A lot of the time organizations spend a lot of time, energy, and money delivering projects and programs so that they can secure whether it be a license or meet a regulatory obligation. Some of them have long-standing programs, but often the effort that goes into getting to that point sort of drops off after. So we'll talk about that. The mental model and how that misleads, what materially changes, what happens actually post-approval that creates risk, and what's some things to consider when we think about sustainable operation. And once again, nothing here is intended to be shared as legal advice. So, uh, what breaks after approval? So let me start with a question that I want you to hold in your mind throughout today's session. Having a think about any of the organizations you've worked in, especially when you've either been around or involved in a major regulatory approval or compliance milestone, think about hitting that milestone or seeing that milestone achieved, and then what happened in the months after that. So just have that in your mind as you think about the things that I'm going to share today. In my experience, it often looks like the program gets stood down or the project gets stood down, and like traditional projects, the project team disappears, the project manager is reallocated, people are happy, we tell the steering committee, we're live, but then slowly but surely things start to slip. Often you're left with a lot of project tech uh project debt and technical debt, and it's not because people are being um negligent or because they um you know don't care, but it's often because the controls that were designed for the organization post-approval, post-hitting that milestone, are actually not set up correctly or maybe not set up at all. And so every organization itself has different ways of approaching this, but when we think about it, we're talking about the approval processes, the operational processes, and how structurally important they are for your organization. Most organizations will typically focus on the approval process and not actually focus on the operational processes. So this is in turn where we find a gap. Now, when we think about approval, getting approval for a license, uh, whether it's a banking license, a financial service license, a credit license, whatever it is in your particular industry, it will help you to validate that you're ready, but it won't actually help you sustain what you have put in place. And that's in turn where a lot of the challenges lie for customers. When we think about the programs and projects that are set up, particularly in the higher regulatory based environments, like banking, for example, there is often three things that get exposed after a program has delivered and gotten to that milestone. So it's who actually owns what, whether the evidence is being produced unless someone asks for it, and whether the operating model has the capacity and the capability to sustain the changes and the obligations long term. Now, why is that important? In particular, when we think about the first element of who actually owns what. The challenge here is that in a program, you typically have your program RACI and your governance structures, and they're embedded into the organization, and it's really clear who is doing what, how things go up to the steering committee, and so forth and so forth. What's not clear is when you disperse your centralized program, what actually happens for accountabilities around that? Because most organizations are structured in a more of a silo and hierarchical way. And so if you don't think through how that trans that accountability model transitions, it can cause some challenges. So this is why the key gaps that we see is around accountability. Now, evidence cadence, one of the things when we're working towards getting approval in a regulatory environment, there's a lot of emphasis put on that because without having those, having that evidence collated up front, you won't secure a license or meet your obligations. So people get together and work hard to try to find, design, uplift, and produce the relevant artifacts needed for the evidence that helps readiness ready them for audits and so forth. The challenge we have is if you don't think about the structure for how evidence will be captured, identified, and integrated into BAU or business as usual operations long term, it causes another gap. And so then in turn becomes a lot more manual effort because if it's not thought about before the program goes live, you spend a lot of time after the program goes live, and there's so much cross-functional coordination needed that it actually creates quite a lot of manual overhead. I worked with an organization that had, you know, really clear, detailed evidence matrix, hundreds of controls mapped, everything was documented beautifully. But six months after they went live, only 40% of the controls were maintained. Why? Because during the program there was visibility at the CERIN committee level, the matrix was in the appendix, appendix of the PACs, and so forth and so forth. But then when the program shut down and nobody was asking for that, they just neglected it. That causes problems, particularly for these organizations where you might actually end up getting audited, and then you have to scramble at the last minute to try to produce that content. So keep in your mind when was the last time your organization went through a major regulatory approval or compliance milestone and think about what happens and see if any of these things are relevant for you as well. Now, I did say I was going to talk a little bit about AFSL, and I just wanted to really, really simply provide an explanation. The reason why is this is super relevant for some of the work we're doing over the last um few years. And so a fine an AFSL is an Australian financial service license. It's a license that allows a business to provide regular regulated financial services in Australia. And to get one, ASIC, our governance body, assesses whether the organization has governance, has the people, the systems, the controls to actually operate it sustainably. So again, it's one thing to be able to secure a license, but it's also another to be able to sustain it because ASIC, the governance body, will continuously monitor and oversee that long term. And here's the critical thing when we think about this. Even though you might get to a point where you're ready to apply and submit your license, it doesn't guarantee ongoing compliance. And this is why there are a number of tactics and techniques that are used by organizations to continue to assess the way that they are maintaining and continuing to meet their obligations. And every organization does that differently. So I won't go into the specifics there. But what I did want to emphasize is that there are a number of failure patterns, and these often neglected, is where we find that transition itself from a program or a project into BAU is often underestimated. So, first of all, when we think about controls. So a control is something that you need to meet, and that usually ties back to an obligation, a regulatory obligation or something internally that is required as well. But in this example, a regulatory obligation. And so they might be designed well at the beginning, but over time they begin to weaken. And that's because, in, as I mentioned earlier, in a program or a project, there's visibility on the controls and who owns them. There's program races, there's lots of models we'll talk about shortly that really make sure that those controls are not neglected. But unless it's really clear how they feed into daily execution, it become can become a problem. As an example for a specific control that an organization needs to continuously meet, it may touch finance, it may touch risk areas, it may touch people and culture. And so as a result, one control might have someone accountable for it, but they have to coordinate with multiple areas. And so again, there in turn becomes the challenge. So you having to think about this earlier can help save the pain later. The other thing around ownership. So ownership blurs around who is responsible, and this not only pertains to the controls, but even how you identify and define new regulatory scope that comes into the business as usual environment. One of the challenges I see with organizations is sometimes regulatory compliance obligations are significant enough, they need to stand up a program or a project to deliver it. And sometimes they might be small. And just like in traditional project environments where we have small projects, medium, and large, we need to make sure that we don't neglect those things. And this is why it's super important for us to understand what the ownership structure is moving forward post-approval. Evidence. So as I mentioned earlier, evidence tends to decay over time. What you put in in terms of effort to get to application starts disintegrating after application. Document libraries aren't maintained. Approval processes to get socialization across key artifacts sometimes falls off the wayside. And also as staff turnover in organizations, that loss of knowledge, if not documented, is also lost. And so everything supporting the ability to maintain controls, ownership, and evidence is the scaffolding, scaffolding rather, that you should be focusing on at the beginning and making sure that you have that in place and it's solid to see you through to the end of the program and then into BAU as well. So on that note, um, the key risk here, um, hopefully is clear, is it's not an obtaining the license. Anyone can go and apply for a license, doesn't mean they get approved, but it's the risk of operating under it. When you look at um a lot of the news where there has been in the media, for example, a lot of uh news stories where um regulatory bodies have fined organizations, it's often not because they did something wrong in applying for the license, but actually they weren't maintaining it or having the right resource structure, processes, oversight controls to actually sustain and maintain it. And um AFSL is a really good example of that because it's becoming uh more prevalent and relevant because of changing um regulatory uh environment, at least in the landscape here in Australia. So, on that note, let's have a think and a little bit more of a deep dive using um the structural gap between approval and operation. And the reason I say structural gap is because everything really is around governance, the governance spine of an organization, the way it operates, whether you're running projects, um, projects and programs or BAU. Everything lives and breathes around governance, and there's multiple layers to that. What I want to highlight here is something that is quite counterintuitive, and it's not that the it's the organizations that struggle most with approval and not the ones that did the bad did bad work up front. By any means, there's actually a lot more emphasis on good project management up front. Um, they're actually the ones that probably did better than than most on getting to an approval point. But what actually ends up happening is you bring in specialists, you bring in SMEs, you have all of this talent that comes in to support these programs and projects. Executive attention is focused on getting approval, they understand the new obligations that they're going to have to meet, that the board needs to adhere to. And you spend all this time and energy working on a project or a program, yes, you integrate business as usual resources and operational staff throughout the journey. But unfortunately, if the program does not embed correctly throughout the life cycle of the program with the VAU teams, which requires rhythm and cadence and good governance structures, what will end up happening is that the cadences that you put in place in a program, being daily, weekly, uh, monthly, steering committees, quarterly board meetings, decision forums, all of these sorts of things, they are very structurally different to what happens in a BAU environment, in an operational environment. The onus of governance in projects, programs, transformation is far different to that of a BAU environment. So I ask you to take a moment and think about four key questions. First, is evidence produced continuously without project support? This is really relevant because if you didn't have the project to sustain you and to provide the structure, will your teams be able to continuously produce the evidence necessary? And is there a process for how evidence gets developed, reviewed, approved, and so forth? Are first line owners named, trained, and accountable in BAU? And this is really important because most organizations have different models around risk management and compliance that involves first line, second line, internal audit, external audit, so forth and so forth. But your first line is effectively your team, your day-to-day team who are accountable and responsible for making sure that once you have these obligations in place, that you can sustain them and continue to meet the controls necessary. Outsourcing. Is outsourcing oversight visible and documented? There are a lot of instances where organizations have outsourcing partners and agreements and frameworks and models. And this is really important to be clear because as the regulatory landscape changes, so too may your relationships with outsourced partners as well. And then can business as usual or BAU withstand thematic reviews? AFSL is one of the many examples of where audits are expected and will happen. I'm not sure how frequently they happen, it depends on the organization, but they are inevitable. And just like internal audits are inevitable, external audits in this environment are also inevitable. And so, could you withstand the review and scrutiny that comes from having auditors on site in your organization? That would be a key question to think about. So if any of these questions that I asked created a moment of uncertainty, then that's effectively the gap that we're talking about. And they seem like simple questions, and they are. And if we can't answer them honestly, then you probably do have a gap. So think about the key thing here, it's not the intent, the failure in intent, but it's actually making sure that you don't have a design problem because whatever you do in the program carries into BAU. And so that includes the positives as well as the negatives. And so to make sure we sustain and are compliant at all times, we need to make sure we have the structure needed, not just in uh before we get approval, but in the transition and then post-approval as well. So let me take you through, and feel free if you have any questions to put them in the chat and we'll cover them towards the end. Let me take you through thinking back about your own teams. When we think about sort of the mental model that shifts organizations and helps them to think about how to best structure the way that they are going to make sure that they meet their obligations. There's lots of different ways of doing it. And a lot of organizations will tend to focus on the regulatory obligations they need to meet, and so forth, so therefore, they will progress programs and projects and directly think about it from an obligation-led lens. Now, I understand that to a degree because it is very easier to map what you need to meet and adhere to, and it's really easy to distribute tasks off of that. It's really easy to break that down and actually define what needs to happen, whether it's your policies, your controls, um, what roles you might need, the evidence you need, all of that is really easy to trace back to an obligation. And that's why a lot of the time obligation-led thinking helps distribute tasks. But one of the models that we've been thinking about is the capability-led thinking, which we spend a lot of time talking about. So, where obligation-led thinking might talk about what must be in place, capability-led thinking is what is the capabilities we need to have in our business to enable us to endure these obligations long after a program is gone. When we think about who signs off, it's not who signs off, but actually who owns it in BAU, who owns the capability into BAU. When we think about evidence, it's not about the evidence that we're submitting, but the rhythm and cadence of securing, identifying, and delivering evidence moving forward. And then when we think about control design, so there's a lot of emphasis on designing the right controls, but how much emphasis is on designing the controls in a way that it can be sustained operationally and also have the necessary capacity to move you forward as well. Most organizations I work with have obligation-led thinking and they have that thoroughly defined, designed, understood. But I feel like many few stress test the capabilities that helps them to endure their obligations into BAU long term. And this is evident because I won't mention names, but um recent news of large organizations being hit with fines because they didn't meet their regulatory obligations. They probably did meet them at the beginning to be able to secure a license, but they probably let it lapse when the license was secured and people got a bit too comfortable. So consider the differences between obligation-led thinking and capability-led thinking. Remember, capability isn't about the people, it's about the ability for an organization to do A, B, C, D, E, etc. When we think about organizations that are progressing down a path where they're about to introduce new services, new structures, new integrate new businesses, secure new licenses, like this example, they have to also think about what are the new capabilities that we're introducing into our business. And this is something super important that we need to think about as well. If we don't, then we do not have the necessary endurance to sustain whatever it is that we've actually introduced. And this is why, from a mental model perspective, thinking about it just with an obligation lens, yes, that might be sufficient from an auditor perspective. Perspective, but capability lens is sufficient from an executive perspective. Because at the end of the day, you're running an organization. And so this is really important and something that I've seen quite a lot of recently that I thought would be really relevant. So let me take you back to what approval mode looks like. And this will help because I'll then talk to you about what changes once you know you secure a license. Again, I am using AFSL as an example because it's very timely, but you can change that and put any other regulatory requirement that you've been involved in, whether it's AML, PCI, DSS, it doesn't really matter. So when we think about the context of what is necessary during the approval phase, it's important to think about the fact that often the environment, the operating environment, is quite artificial. Everyone knows the stakes stakes that are involved of not securing a license or meeting a regulatory obligation. The executive attention is elevated. Case in point, having a steering committee or a board meeting, you have sponsorship right at the top, you know, legals always across it, understands what the obligations are. They've translated that. Manual effort is tolerated. The controls themselves are also supported because you're having so many cross-functional conversations, unlike traditional silo-driven environments. Apologies about the train in the background. And what you're doing in that situation is you've got this buffer because, you know, if Jenny over here doesn't pick up on something, Sally over there might or Mike. And so you've got like this buffering that supports you and provides that, I guess, that preventative risk lens that you might not see in your particular scope. And so the work is optimized. You get to a point where you know you can demonstrate your controls, you can demonstrate your obligations and all of those things. Now that's okay. But what it's not appropriate for is long-term sustainability. Because at the moment, what we're doing is we're actually just looking at things from a temporary lens. Projects are temporary after all. Um, the executive attention on this initiative is not going to be sustained into BAU. Um, manual effort is tolerated, and then also the fragility of trying to build the plane um while flying it is all okay. But what changes when you have a license approval? So let's say you get to a point where you have secured a credit license, a banking license, a financial service license, uh whatever it is. Once you've got that, it actually then provides um clarity around what was once provisional owners in the project or program based on the delivery leads involved or the SMEs allocated, becomes actual personal accountability. The program is no longer the owner, the program disappears just like it traditionally does. And at this point, when we think about evidence, it needs to continue to be continuously delivered on and is no longer uh hypothetical, it's no longer illustrative. What that means is you're providing evidence as part of you meeting your ongoing controls, whether it's providing um input to finance as part of their risk assessment quarterly, um, or whether it's um providing input to internal audit as part of their annual compliance assessment. Regulatory work will now then compete with commercial priorities. And even though in the program compliance is a priority once you go to BAU and the license is live, there's a lot more pressing priorities like meeting revenue targets and headcount pressures and all these other things that just detract from meeting our obligations and meeting our controls and continuously maintaining those. What we also find is the manual workarounds that were accepted and maybe celebrated during a program to get the job done to get us to our go live can become structural risks for us. So, you know, your spreadsheets that temporarily log and manage everything, yeah, they're great until there's a change in position and that person who was managing all that forgets to save it or potentially doesn't hand it over and it becomes a key person risk. Um, when we think about um the ambiguity in organizations that are traditionally set up in silos, uh, the functional ambiguity that was accepted in a program and tolerated because we had cross-functional teams working together to deliver the outcome, that becomes regulatory exposure. There's also a distraction around who owns what part of an obligation or a control, because as I mentioned earlier, it can touch multiple parts of an organization. And without a central overarching governance structure and program management, project function, overseeing all that, like it was during delivery, it ends up being fragmented and you end up having gaps in your accountability and the problems come from there. These are really specific examples of things that I've seen firsthand in numerous in engagements and environments from the healthcare space to banking to retail. These are not unique, they are very common, and if they're not factored in in the structural piece that you're doing before you close the project and program, you actually can find that they'll cause more problems later. So let's move in now to talking about where post-approval risk actually emerges. So now we've got our um our program our programs delivered where we're live, we we've got um adherence to our AML policies or our PCIDS or whatever it might be, and that's when you start hearing, and you probably hear this in the news, I've been seeing it quite a lot, particularly um in certain industries, you start hearing about a breach over here and a breach over there, and one after the other, you continuously hear about all these breaches, and the breach usually ends up meaning fines, um, maybe warnings, it can even lead to um other more serious um challenges. Now, when I think about um referencing this, the reason I'm mentioning it is because a breach is effectively uh begins as a drift, so you know, drifting away from what you had endorsed, agreed, and put in place when you got approval, and then you start to drift away from that. And the signs themselves might start being very subtle. You might start seeing delivery effort increasing for something that maybe took, you know, took a few hours a month, might start taking a couple of weeks. Or maybe you start to see confidence waiting in the data that was coming out of the system that you're using. Maybe the activity starts accelerating, but the control owners are not really clear on how their control has changed. You start to see more reporting demands because obligations and controls touch multiple areas of an organization, and you might still start finding HR requesting information and the aboard requesting information and legal requesting information. So the evidence exists, it's somewhere, but people aren't really clear where it is and um how to bring it together. You find that the only reason why you're minimizing the risks or reducing the breach is because you've got, you know, change champions that are actually in the organization that heavily involved in the programs or actually just um drive themselves forward to actually close the gaps that they are seeing. But again, there's only so much individuals can do on their own. And so, overall, what that means is you've got higher costs from an insurance perspective. You might need more effort internal from an internal audit, internal audits may become more frequent for your division or your area. Um, you may end up getting a tap on the shoulder, and you might have a regulator coming in and actually doing their own audits. And then over time, you start eroding the trust that you have with stakeholders and with regulators because the accumulated drift actually starts to create a greater divide. And then what you find is it's not that you're not being compliant, it's that your operating model wasn't sustainable enough for you to avoid those failures. And it's really important to distinguish the two because if you diagnose it as a compliance failure, people will typically go and add more compliance activity, and adding more compliance activity is not going to solve the problem. You can add more people, you can run more audits, build more frameworks, but if the underlying pattern is the structure, the governance spine and the structure of an organization and the unclear accountability, the operating rhythms, the sustained capacity gaps, all of that is still a problem, and you add additional compliance activity on top, you're just continuously further eroding your operating model that your um your organization is based off. And so it adds cost, it adds burden, and you just find that most organizations have, rather than just projects and programs, an ongoing um uh allocation of funds specifically to deal with compliance and these sorts of situations because they're never-ending, first of all, and also they just find they have a never-ending backlog as well of things that they need to address. So to diagnose this early is to intervene as early as possible. Intervening early is thinking about it well and truly before you get to a point of approval. One of the things that I see that works really well that does help is every organization typically does monthly reporting and/or stereo code reporting, board reporting, whatever it might be. Start having monthly compliance checks in that process. Make it something that is part of the day-to-day. Just like when we are reporting, we talk about risks. Let's make sure we don't neglect compliance. I think it's something that is a behavioral change that will help an organization, and this is why it's important to be factoring factoring on that. Often we find that organizations tend to produce a lot of reporting, takes weeks to compile, it's full of data, but it doesn't actually articulate what the problems are that it's actually existing in the organization. And so again, you're continuously eroding the trust that you've built with stakeholders, particularly if you ran the program very well. So, what does conscious of time sustainable operation look like? And again, I'm referencing a specific example here, um, being AFSL, but just remove that terminology and add anything else in there that you want. As I said, it having a sustainable operation doesn't mean you'll never ever have any breaches. It actually is about making sure you're aware of what sustainability looks like, not just feels like. It has to be observable. We have to make sure we get to a point where we can clearly articulate that we've got the right evidence, and the evidence is generated through consistent workflows that is followed by all. So you've got that traceability, super helpful if you ever get audited. We need to make sure that we have clarity around our outsourcing models when it comes to ownership and governance. We need to make sure that the right things are documented, the right things are in place, and they're maintained. One of the biggest gaps in uh regulatory compliance environments is you have a phenomenal amount of documentation that is carefully tracked and managed, hundreds and hundreds of documents, and they go through full reviews and cycles, and they come out the other end and they're all approved. And then that document register, that process, the capability around that just disintegrates. And then you lose track of evidence, you lose track of all of the things that you had agreed with partners when you when you've got um them in place, you lose visibility, visibility around accounting models, uh, all of those sorts of things if it's not sustained into BAU. From an ownership perspective, it's explicit that first line ownership is there and that it has to be visible at all times. And you need to think about um making sure that even when a role changes within your organization, that it doesn't break things. And so this is why I talk about making sure that organizations themselves have always got a focus on making their processes around and making their processes around the capabilities, not about the individuals. So about the roles is relevant, but not the individuals themselves because people come and go. So you want to make sure having that capability structure actually ensures that you can um sustain it long term as well, despite changing people in your teams and things like that as well. From a governance perspective, linking your reporting back to obligations as well as capability and having that visibility and making sure that that's traceable, making sure that your operating model enables you to have a repeatable mechanism to intake new obligations, assess them, get them endorsed, defined how you're going to deliver them, how you're going to make sure that you provide the necessary updates, and that is also all without referring back to being in a program. And one of the most important things I think is that, because in programs we typically have a pipeline process or a demand management process, but what we don't have is something like that usually in the regulatory space. And so you find that new obligations start to get either deprioritized, disregarded, forgotten, and not ingested into the workflow. So having a workflow for that is really important. If every time a new regulatory development triggers a project and a steering committee and all of that, it means that the operating model isn't absorbing the change well enough. It means that the operating model has some gaps. So it's just important to make sure that you're paying attention to those things. So on that note, just to ramp us down, think about these key questions when thinking about whether your organization is ready. Now you may be mid-flight through a regulatory change or a compliance program, and you may have had some things that have come to mind as a result of today's webinar. And as you go through the coming days and weeks, uh, and if you do get a chance to go back through what we've talked about, I ask you to take away these four key questions and think about them from the perspective of your organization or your team. As I said, we all have a part to play when it comes to being mitigating risks and making sure our organizations stay compliant, but the role that we play will very much differ depending on where we sit. As a program, we need to make sure that we have set up operations for success and doing so long term, and doing so, making sure we bridge the gap between approval and live and post-live, post-approval, to make sure that the organization is set up for sustainability and long-term longevity, sorry. But I want to leave you with something practical. So here are four diagnostic questions. They're questions I'll use when I sit down with an executive team to assess their regulatory operating model, some of many. Think about this. If a program was stood down tomorrow, which controls would fail quietly, not loudly, but quietly? Um, which ones would stop being maintained? Which ones would people forget about for six months until an audit comes knocking? How are new obligations and regulatory requirements ingested and allocated without reactivating a project structure? People often bring in projects and programs because they want a sense of control, and that is necessary when they find that there is significant gaps, as I suggested earlier, that a program might be necessary. But do you have a process for ingesting these things or are you constantly moving and suggesting new projects and programs? Can every material obligation be traced to a first-line owner? And does it have a defined evidence cadence? So this isn't a function or a team, but actually the named person within the schedule that is required to meet this specific material obligation, the one that's accountable for driving it forward. And then thinking about AFSL specifically, would the resignation of one of your responsible managers immediately expose a capability gap? There are a number of different questions to ask. These are probably four I would start with, not to alarm you, but more to give you a starting point to think about the conversation from the perspective of what do we need to think about for our operating model design or changes to it. And if you can answer all four with conference, great. But if any of them give you uncertainty, that's also valuable information because it can give you a lens on where to start as well. So now that we've come to the closing section, I hope these key questions will help you. I'm happy to take questions, reach out to me on LinkedIn or leave some comments on the video that you'll see. As a closing thought, be aware that there is definitely a science and an art to how to make sure you execute well. And so if anything of what we've covered today resonates with where your organization is, let me briefly share how we can help. As I said earlier, AMO works with executives who are accountable for A-Bersell outcomes to make sure that execution is real and sustainable, both before and after licensing. And so there's three core offerings in this space. First and foremost, a one-day on-site with an executive team to help them make sense of what they need to understand to really truly understand what their genuinely accountabilities will be from an AFL perspective. This is more of an executive briefing, not a legal briefing. Number two is the foundations diagnostic. So this is our structured diagnostic to give your decision great clarity and it helps you to identify what you need to operate, evidence, and sustain into BAU long term. It is not a report for the shelf, but a clear picture of where your gaps are and what needs to change so that your teams can take that forward and actually implement. And the third one is the A for Sale delivery design. If you're preparing for an application similar to this, or you're already licensed and you know your operating model needs work, this is where we'll design how the change can be delivered without breaking the organization. We'll give you guidance on the people, process, structure, and governance that you would need to have in place. And that will really help to support the organization to make sure that they can be successful. If you're not sure what you need, there's a couple of suggestions here on screen. If you're not sure, start with the one day on site. If you're unclear on your scope, start with the diagnostic. And if you know what your scope is, and maybe you've had a strategy paper put together, you might decide to move into delivery design. But if you have any questions about anything we've covered today, please do reach out. And that's the session. I want to leave you with the same question that I opened with. So what happens in the six months after your next approval, either for something that you've experienced recently or for something you've got coming up? That specific answer will be that answer to that question can be determined and help you to understand where you are and where you maybe need to uplift. It talks about enabling you to see where you maybe need to change accountability, your evidence built into workflows, your capability structures, and making sure that you understand that operating a license is not a project. Securing the license maybe, but actually enduring and having an operating model that withstands all of these new changes to your organization will continuously help you to grow and avoid the very breaches that you don't want to be called out for. Anyways, if you'd like to continue the conversation, um, my contact details are in the email that you'll be sent. And we'll also share with you the link to the video. Thank you so much for write it out. Don't forget to follow us at social media at the adult ID. Go to our website www.atal management.com.