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

WEBVTT
00:00:00.239 --> 00:00:05.599
You're welcome to Agile Ideas the Podcast, hosted by Fatimah Abbouchi.
00:00:05.599 --> 00:00:10.400
For anyone listening out there not having a good day, please know there is help out there.
00:00:10.400 --> 00:00:14.880
Thanks so much for joining today.
00:00:14.880 --> 00:00:24.559
Today we're here to talk about regulatory programs and why they stall after approval and how to design ones that actually run.
00:00:24.559 --> 00:00:34.320
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.
00:00:34.320 --> 00:00:40.880
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.
00:00:40.880 --> 00:00:46.640
For those who don't know me, I'm Fatimah Abbouchi, the founder and CEO of AMO, Agile Management Office.
00:00:46.640 --> 00:01:01.759
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.
00:01:01.759 --> 00:01:20.959
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.
00:01:20.959 --> 00:01:36.959
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.
00:01:36.959 --> 00:01:42.480
A couple of quick housekeeping notes, other than being recorded, so that we can share the link afterwards.
00:01:42.480 --> 00:01:47.120
Nothing I'm sharing today is legal advice or obligation interpretation.
00:01:47.120 --> 00:01:54.719
This is more about execution and operating model rhythms, cadence processes, more about that conversation.
00:01:54.719 --> 00:01:58.879
So on that note, let's uh dig into it.
00:01:58.879 --> 00:02:02.239
Let me take you through what we're going to cover.
00:02:02.239 --> 00:02:08.240
So we're going to talk about the core problem that we're seeing and what breaks after approval.
00:02:08.240 --> 00:02:19.520
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.
00:02:19.520 --> 00:02:26.879
Some of them have long-standing programs, but often the effort that goes into getting to that point sort of drops off after.
00:02:26.879 --> 00:02:28.080
So we'll talk about that.
00:02:28.080 --> 00:02:41.120
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.
00:02:41.120 --> 00:02:45.680
And once again, nothing here is intended to be shared as legal advice.
00:02:45.680 --> 00:02:50.240
So, uh, what breaks after approval?
00:02:50.240 --> 00:02:55.680
So let me start with a question that I want you to hold in your mind throughout today's session.
00:02:55.680 --> 00:03:14.639
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.
00:03:14.639 --> 00:03:19.840
So just have that in your mind as you think about the things that I'm going to share today.
00:03:19.840 --> 00:03:38.000
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.
00:03:38.000 --> 00:04:02.159
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.
00:04:02.159 --> 00:04:14.479
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.
00:04:14.479 --> 00:04:22.319
Most organizations will typically focus on the approval process and not actually focus on the operational processes.
00:04:22.319 --> 00:04:25.519
So this is in turn where we find a gap.
00:04:25.519 --> 00:04:45.199
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.
00:04:45.199 --> 00:04:49.839
And that's in turn where a lot of the challenges lie for customers.
00:04:49.839 --> 00:05:06.399
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.
00:05:06.399 --> 00:05:21.600
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.
00:05:21.600 --> 00:05:24.000
Now, why is that important?
00:05:24.000 --> 00:05:29.040
In particular, when we think about the first element of who actually owns what.
00:05:29.040 --> 00:05:42.800
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.
00:05:42.800 --> 00:05:51.600
What's not clear is when you disperse your centralized program, what actually happens for accountabilities around that?
00:05:51.600 --> 00:05:56.639
Because most organizations are structured in a more of a silo and hierarchical way.
00:05:56.639 --> 00:06:02.560
And so if you don't think through how that trans that accountability model transitions, it can cause some challenges.
00:06:02.560 --> 00:06:07.120
So this is why the key gaps that we see is around accountability.
00:06:07.120 --> 00:06:25.839
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.
00:06:25.839 --> 00:06:40.079
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.
00:06:40.079 --> 00:06:55.759
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.
00:06:55.759 --> 00:07:12.720
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.
00:07:12.720 --> 00:07:22.319
I worked with an organization that had, you know, really clear, detailed evidence matrix, hundreds of controls mapped, everything was documented beautifully.
00:07:22.319 --> 00:07:26.959
But six months after they went live, only 40% of the controls were maintained.
00:07:26.959 --> 00:07:27.680
Why?
00:07:27.680 --> 00:07:36.879
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.
00:07:36.879 --> 00:07:42.399
But then when the program shut down and nobody was asking for that, they just neglected it.
00:07:42.399 --> 00:07:51.120
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.
00:07:51.120 --> 00:08:02.639
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.
00:08:02.639 --> 00:08:11.519
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.
00:08:11.519 --> 00:08:17.040
The reason why is this is super relevant for some of the work we're doing over the last um few years.
00:08:17.040 --> 00:08:21.360
And so a fine an AFSL is an Australian financial service license.
00:08:21.360 --> 00:08:28.959
It's a license that allows a business to provide regular regulated financial services in Australia.
00:08:28.959 --> 00:08:40.559
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.
00:08:40.559 --> 00:08:52.879
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.
00:08:52.879 --> 00:08:55.919
And here's the critical thing when we think about this.
00:08:55.919 --> 00:09:04.799
Even though you might get to a point where you're ready to apply and submit your license, it doesn't guarantee ongoing compliance.
00:09:04.799 --> 00:09:17.200
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.
00:09:17.200 --> 00:09:19.759
And every organization does that differently.
00:09:19.759 --> 00:09:22.240
So I won't go into the specifics there.
00:09:22.240 --> 00:09:38.159
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.
00:09:38.159 --> 00:09:41.200
So, first of all, when we think about controls.
00:09:41.200 --> 00:09:52.799
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.
00:09:52.799 --> 00:09:55.200
But in this example, a regulatory obligation.
00:09:55.200 --> 00:10:00.639
And so they might be designed well at the beginning, but over time they begin to weaken.
00:10:00.639 --> 00:10:09.120
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.
00:10:09.120 --> 00:10:16.879
There's program races, there's lots of models we'll talk about shortly that really make sure that those controls are not neglected.
00:10:16.879 --> 00:10:22.799
But unless it's really clear how they feed into daily execution, it become can become a problem.
00:10:22.799 --> 00:10:33.519
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.
00:10:33.519 --> 00:10:40.080
And so as a result, one control might have someone accountable for it, but they have to coordinate with multiple areas.
00:10:40.080 --> 00:10:43.120
And so again, there in turn becomes the challenge.
00:10:43.120 --> 00:10:47.360
So you having to think about this earlier can help save the pain later.
00:10:47.360 --> 00:10:49.600
The other thing around ownership.
00:10:49.600 --> 00:11:06.320
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.
00:11:06.320 --> 00:11:18.000
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.
00:11:18.000 --> 00:11:20.000
And sometimes they might be small.
00:11:20.000 --> 00:11:27.840
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.
00:11:27.840 --> 00:11:35.279
And this is why it's super important for us to understand what the ownership structure is moving forward post-approval.
00:11:35.279 --> 00:11:36.559
Evidence.
00:11:36.559 --> 00:11:40.480
So as I mentioned earlier, evidence tends to decay over time.
00:11:40.480 --> 00:11:48.559
What you put in in terms of effort to get to application starts disintegrating after application.
00:11:48.559 --> 00:11:51.200
Document libraries aren't maintained.
00:11:51.200 --> 00:11:57.759
Approval processes to get socialization across key artifacts sometimes falls off the wayside.
00:11:57.759 --> 00:12:04.240
And also as staff turnover in organizations, that loss of knowledge, if not documented, is also lost.
00:12:04.240 --> 00:12:24.799
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.
00:12:24.799 --> 00:12:34.240
So on that note, um, the key risk here, um, hopefully is clear, is it's not an obtaining the license.
00:12:34.240 --> 00:12:41.519
Anyone can go and apply for a license, doesn't mean they get approved, but it's the risk of operating under it.
00:12:41.519 --> 00:13:08.639
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.
00:13:08.639 --> 00:13:20.320
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.
00:13:20.320 --> 00:13:31.360
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.
00:13:31.360 --> 00:13:44.399
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.
00:13:44.399 --> 00:13:48.559
Everything lives and breathes around governance, and there's multiple layers to that.
00:13:48.559 --> 00:14:01.840
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.
00:14:01.840 --> 00:14:06.320
By any means, there's actually a lot more emphasis on good project management up front.
00:14:06.320 --> 00:14:11.919
Um, they're actually the ones that probably did better than than most on getting to an approval point.
00:14:11.919 --> 00:14:23.600
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.
00:14:23.600 --> 00:14:31.759
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.
00:14:31.759 --> 00:14:40.720
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.
00:14:40.720 --> 00:15:14.240
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.
00:15:14.240 --> 00:15:23.200
The onus of governance in projects, programs, transformation is far different to that of a BAU environment.
00:15:23.200 --> 00:15:29.120
So I ask you to take a moment and think about four key questions.
00:15:29.120 --> 00:15:34.159
First, is evidence produced continuously without project support?
00:15:34.159 --> 00:15:44.639
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?
00:15:44.639 --> 00:15:50.320
And is there a process for how evidence gets developed, reviewed, approved, and so forth?
00:15:50.320 --> 00:15:56.159
Are first line owners named, trained, and accountable in BAU?
00:15:56.159 --> 00:16:08.960
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.
00:16:08.960 --> 00:16:23.679
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.
00:16:23.679 --> 00:16:25.279
Outsourcing.
00:16:25.279 --> 00:16:28.559
Is outsourcing oversight visible and documented?
00:16:28.559 --> 00:16:36.240
There are a lot of instances where organizations have outsourcing partners and agreements and frameworks and models.
00:16:36.240 --> 00:16:46.559
And this is really important to be clear because as the regulatory landscape changes, so too may your relationships with outsourced partners as well.
00:16:46.559 --> 00:16:52.320
And then can business as usual or BAU withstand thematic reviews?
00:16:52.320 --> 00:17:00.000
AFSL is one of the many examples of where audits are expected and will happen.
00:17:00.000 --> 00:17:05.920
I'm not sure how frequently they happen, it depends on the organization, but they are inevitable.
00:17:05.920 --> 00:17:12.640
And just like internal audits are inevitable, external audits in this environment are also inevitable.
00:17:12.640 --> 00:17:19.519
And so, could you withstand the review and scrutiny that comes from having auditors on site in your organization?
00:17:19.519 --> 00:17:22.000
That would be a key question to think about.
00:17:22.000 --> 00:17:29.519
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.
00:17:29.519 --> 00:17:32.400
And they seem like simple questions, and they are.
00:17:32.400 --> 00:17:36.880
And if we can't answer them honestly, then you probably do have a gap.
00:17:36.880 --> 00:17:49.200
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.
00:17:49.200 --> 00:17:52.640
And so that includes the positives as well as the negatives.
00:17:52.640 --> 00:18:06.160
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.
00:18:06.160 --> 00:18:15.519
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.
00:18:15.519 --> 00:18:21.200
Let me take you through thinking back about your own teams.
00:18:21.200 --> 00:18:34.480
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.
00:18:34.480 --> 00:18:36.480
There's lots of different ways of doing it.
00:18:36.480 --> 00:18:49.839
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.
00:18:49.839 --> 00:19:01.200
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.
00:19:01.200 --> 00:19:17.759
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.
00:19:17.759 --> 00:19:22.960
And that's why a lot of the time obligation-led thinking helps distribute tasks.
00:19:22.960 --> 00:19:30.559
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.
00:19:30.559 --> 00:19:44.799
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.
00:19:44.799 --> 00:19:53.920
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.
00:19:53.920 --> 00:20:04.160
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.
00:20:04.160 --> 00:20:22.240
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.
00:20:22.240 --> 00:20:32.240
Most organizations I work with have obligation-led thinking and they have that thoroughly defined, designed, understood.
00:20:32.240 --> 00:20:44.000
But I feel like many few stress test the capabilities that helps them to endure their obligations into BAU long term.
00:20:44.000 --> 00:20:55.680
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.
00:20:55.680 --> 00:21:06.640
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.
00:21:06.640 --> 00:21:12.960
So consider the differences between obligation-led thinking and capability-led thinking.
00:21:12.960 --> 00:21:20.799
Remember, capability isn't about the people, it's about the ability for an organization to do A, B, C, D, E, etc.
00:21:20.799 --> 00:21:39.759
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.
00:21:39.759 --> 00:21:44.079
And this is something super important that we need to think about as well.
00:21:44.079 --> 00:21:51.680
If we don't, then we do not have the necessary endurance to sustain whatever it is that we've actually introduced.
00:21:51.680 --> 00:21:59.839
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.
00:21:59.839 --> 00:22:04.160
Perspective, but capability lens is sufficient from an executive perspective.
00:22:04.160 --> 00:22:07.440
Because at the end of the day, you're running an organization.
00:22:07.440 --> 00:22:14.000
And so this is really important and something that I've seen quite a lot of recently that I thought would be really relevant.
00:22:14.000 --> 00:22:20.640
So let me take you back to what approval mode looks like.
00:22:20.640 --> 00:22:26.400
And this will help because I'll then talk to you about what changes once you know you secure a license.
00:22:26.400 --> 00:22:39.519
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.
00:22:39.519 --> 00:22:52.160
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.
00:22:52.160 --> 00:22:59.039
Everyone knows the stakes stakes that are involved of not securing a license or meeting a regulatory obligation.
00:22:59.039 --> 00:23:01.359
The executive attention is elevated.
00:23:01.359 --> 00:23:12.160
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.
00:23:12.160 --> 00:23:13.440
They've translated that.
00:23:13.440 --> 00:23:15.599
Manual effort is tolerated.
00:23:15.599 --> 00:23:39.920
The controls themselves are also supported because you're having so many cross-functional conversations, unlike traditional silo-driven environments.
00:23:39.920 --> 00:23:42.160
Apologies about the train in the background.
00:23:42.160 --> 00:23:52.559
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.
00:23:52.559 --> 00:24:04.880
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.
00:24:04.880 --> 00:24:07.359
And so the work is optimized.
00:24:07.359 --> 00:24:13.200
You get to a point where you know you can demonstrate your controls, you can demonstrate your obligations and all of those things.
00:24:13.200 --> 00:24:14.559
Now that's okay.
00:24:14.559 --> 00:24:24.400
But what it's not appropriate for is long-term sustainability.
00:24:24.400 --> 00:24:29.599
Because at the moment, what we're doing is we're actually just looking at things from a temporary lens.
00:24:29.599 --> 00:24:32.000
Projects are temporary after all.
00:24:32.000 --> 00:24:37.119
Um, the executive attention on this initiative is not going to be sustained into BAU.
00:24:37.119 --> 00:24:46.880
Um, manual effort is tolerated, and then also the fragility of trying to build the plane um while flying it is all okay.
00:24:46.880 --> 00:24:52.240
But what changes when you have a license approval?
00:24:52.240 --> 00:25:02.799
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.
00:25:02.799 --> 00:25:19.839
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.
00:25:19.839 --> 00:25:25.039
The program is no longer the owner, the program disappears just like it traditionally does.
00:25:25.039 --> 00:25:36.480
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.
00:25:36.480 --> 00:25:54.559
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.
00:25:54.559 --> 00:25:58.400
Regulatory work will now then compete with commercial priorities.
00:25:58.400 --> 00:26:16.799
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.
00:26:16.799 --> 00:26:27.279
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.
00:26:27.279 --> 00:26:43.359
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.
00:26:43.359 --> 00:27:02.559
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.
00:27:02.559 --> 00:27:12.880
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.
00:27:12.880 --> 00:27:28.160
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.
00:27:28.160 --> 00:27:41.759
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.
00:27:41.759 --> 00:27:54.480
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.
00:27:54.480 --> 00:28:01.440
So let's move in now to talking about where post-approval risk actually emerges.
00:28:01.440 --> 00:28:42.319
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.
00:28:42.319 --> 00:29:02.160
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.
00:29:02.160 --> 00:29:06.240
And the signs themselves might start being very subtle.
00:29:06.240 --> 00:29:17.119
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.
00:29:17.119 --> 00:29:23.440
Or maybe you start to see confidence waiting in the data that was coming out of the system that you're using.
00:29:23.440 --> 00:29:30.319
Maybe the activity starts accelerating, but the control owners are not really clear on how their control has changed.
00:29:30.319 --> 00:29:45.680
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.
00:29:45.680 --> 00:29:53.759
So the evidence exists, it's somewhere, but people aren't really clear where it is and um how to bring it together.
00:29:53.759 --> 00:30:10.640
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.
00:30:10.640 --> 00:30:14.640
But again, there's only so much individuals can do on their own.
00:30:14.640 --> 00:30:20.559
And so, overall, what that means is you've got higher costs from an insurance perspective.
00:30:20.559 --> 00:30:28.559
You might need more effort internal from an internal audit, internal audits may become more frequent for your division or your area.
00:30:28.559 --> 00:30:36.400
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.
00:30:36.400 --> 00:30:47.359
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.
00:30:47.359 --> 00:30:57.039
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.
00:30:57.039 --> 00:31:10.559
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.
00:31:10.559 --> 00:31:39.119
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.
00:31:39.119 --> 00:32:02.319
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.
00:32:02.319 --> 00:32:08.400
So to diagnose this early is to intervene as early as possible.
00:32:08.400 --> 00:32:13.920
Intervening early is thinking about it well and truly before you get to a point of approval.
00:32:13.920 --> 00:32:26.559
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.
00:32:26.559 --> 00:32:30.160
Start having monthly compliance checks in that process.
00:32:30.160 --> 00:32:33.279
Make it something that is part of the day-to-day.
00:32:33.279 --> 00:32:36.720
Just like when we are reporting, we talk about risks.
00:32:36.720 --> 00:32:38.960
Let's make sure we don't neglect compliance.
00:32:38.960 --> 00:32:46.000
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.
00:32:46.000 --> 00:32:59.519
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.
00:32:59.519 --> 00:33:06.160
And so again, you're continuously eroding the trust that you've built with stakeholders, particularly if you ran the program very well.
00:33:06.160 --> 00:33:12.559
So, what does conscious of time sustainable operation look like?
00:33:12.559 --> 00:33:23.440
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.
00:33:23.440 --> 00:33:29.440
As I said, it having a sustainable operation doesn't mean you'll never ever have any breaches.
00:33:29.440 --> 00:33:38.319
It actually is about making sure you're aware of what sustainability looks like, not just feels like.
00:33:38.319 --> 00:33:40.079
It has to be observable.
00:33:40.079 --> 00:33:52.000
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.
00:33:52.000 --> 00:33:56.079
So you've got that traceability, super helpful if you ever get audited.
00:33:56.079 --> 00:34:04.319
We need to make sure that we have clarity around our outsourcing models when it comes to ownership and governance.
00:34:04.319 --> 00:34:09.519
We need to make sure that the right things are documented, the right things are in place, and they're maintained.
00:34:09.519 --> 00:34:28.480
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.
00:34:28.480 --> 00:34:33.199
And then that document register, that process, the capability around that just disintegrates.
00:34:33.199 --> 00:34:50.480
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.
00:34:50.480 --> 00:35:01.119
From an ownership perspective, it's explicit that first line ownership is there and that it has to be visible at all times.
00:35:01.119 --> 00:35:09.039
And you need to think about um making sure that even when a role changes within your organization, that it doesn't break things.
00:35:09.039 --> 00:35:22.400
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.
00:35:22.400 --> 00:35:26.960
So about the roles is relevant, but not the individuals themselves because people come and go.
00:35:26.960 --> 00:35:38.480
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.
00:35:38.480 --> 00:36:08.000
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.
00:36:08.000 --> 00:36:23.280
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.
00:36:23.280 --> 00:36:32.559
And so you find that new obligations start to get either deprioritized, disregarded, forgotten, and not ingested into the workflow.
00:36:32.559 --> 00:36:34.880
So having a workflow for that is really important.
00:36:34.880 --> 00:36:44.800
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.
00:36:44.800 --> 00:36:48.000
It means that the operating model has some gaps.
00:36:48.000 --> 00:36:52.719
So it's just important to make sure that you're paying attention to those things.
00:36:52.719 --> 00:37:06.159
So on that note, just to ramp us down, think about these key questions when thinking about whether your organization is ready.
00:37:06.159 --> 00:37:19.039
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.
00:37:19.039 --> 00:37:37.360
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.
00:37:37.360 --> 00:37:49.119
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.
00:37:49.119 --> 00:38:15.119
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.
00:38:15.119 --> 00:38:17.199
But I want to leave you with something practical.
00:38:17.199 --> 00:38:19.440
So here are four diagnostic questions.
00:38:19.440 --> 00:38:28.320
They're questions I'll use when I sit down with an executive team to assess their regulatory operating model, some of many.
00:38:28.320 --> 00:38:29.679
Think about this.
00:38:29.679 --> 00:38:36.719
If a program was stood down tomorrow, which controls would fail quietly, not loudly, but quietly?
00:38:36.719 --> 00:38:39.519
Um, which ones would stop being maintained?
00:38:39.519 --> 00:38:44.239
Which ones would people forget about for six months until an audit comes knocking?
00:38:44.239 --> 00:38:55.599
How are new obligations and regulatory requirements ingested and allocated without reactivating a project structure?
00:38:55.599 --> 00:39:09.519
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.
00:39:09.519 --> 00:39:16.000
But do you have a process for ingesting these things or are you constantly moving and suggesting new projects and programs?
00:39:16.000 --> 00:39:20.320
Can every material obligation be traced to a first-line owner?
00:39:20.320 --> 00:39:23.840
And does it have a defined evidence cadence?
00:39:23.840 --> 00:39:36.239
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.
00:39:36.239 --> 00:39:45.280
And then thinking about AFSL specifically, would the resignation of one of your responsible managers immediately expose a capability gap?
00:39:45.280 --> 00:39:48.320
There are a number of different questions to ask.
00:39:48.320 --> 00:40:01.119
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.
00:40:01.119 --> 00:40:03.920
And if you can answer all four with conference, great.
00:40:03.920 --> 00:40:10.719
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.
00:40:10.719 --> 00:40:16.400
So now that we've come to the closing section, I hope these key questions will help you.
00:40:16.400 --> 00:40:26.320
I'm happy to take questions, reach out to me on LinkedIn or leave some comments on the video that you'll see.
00:40:26.320 --> 00:40:36.719
As a closing thought, be aware that there is definitely a science and an art to how to make sure you execute well.
00:40:36.719 --> 00:40:45.280
And so if anything of what we've covered today resonates with where your organization is, let me briefly share how we can help.
00:40:45.280 --> 00:40:56.559
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.
00:40:56.559 --> 00:40:59.280
And so there's three core offerings in this space.
00:40:59.280 --> 00:41:12.880
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.
00:41:12.880 --> 00:41:16.480
This is more of an executive briefing, not a legal briefing.
00:41:16.480 --> 00:41:19.519
Number two is the foundations diagnostic.
00:41:19.519 --> 00:41:30.719
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.
00:41:30.719 --> 00:41:39.199
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.
00:41:39.199 --> 00:41:42.639
And the third one is the A for Sale delivery design.
00:41:42.639 --> 00:41:53.760
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.
00:41:53.760 --> 00:41:59.840
We'll give you guidance on the people, process, structure, and governance that you would need to have in place.
00:41:59.840 --> 00:42:05.119
And that will really help to support the organization to make sure that they can be successful.
00:42:05.119 --> 00:42:09.039
If you're not sure what you need, there's a couple of suggestions here on screen.
00:42:09.039 --> 00:42:12.159
If you're not sure, start with the one day on site.
00:42:12.159 --> 00:42:15.599
If you're unclear on your scope, start with the diagnostic.
00:42:15.599 --> 00:42:22.159
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.
00:42:22.159 --> 00:42:28.480
But if you have any questions about anything we've covered today, please do reach out.
00:42:28.480 --> 00:42:29.840
And that's the session.
00:42:29.840 --> 00:42:33.119
I want to leave you with the same question that I opened with.
00:42:33.119 --> 00:42:42.400
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?
00:42:42.400 --> 00:42:54.400
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.
00:42:54.400 --> 00:43:07.840
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.
00:43:07.840 --> 00:43:21.840
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.
00:43:21.840 --> 00:43:27.519
Anyways, if you'd like to continue the conversation, um, my contact details are in the email that you'll be sent.
00:43:27.519 --> 00:43:30.159
And we'll also share with you the link to the video.
00:43:30.159 --> 00:43:35.440
Thank you so much for write it out.
00:43:35.440 --> 00:43:41.599
Don't forget to follow us at social media at the adult ID.
00:43:41.599 --> 00:43:47.360
Go to our website www.atal management.com.