Date: Tue 07 Sep 2021
Title: Principles of Successful ERM Implementation
How can we best ensure an Enterprise Risk Management regime that is readily accepted and endures? Answer: by mastering the principles of program success, which will set you apart as an administrator.
In our last episode, we focused on maintaining a light footprint, as ERM should not be an extraordinary administrative burden. Now let’s continue the story of successful implementation by employing the success factors shown in studies.
1. clear goals and objectives – how to formulate them?
2. senior executive support – how to secure meaningful exec support?
3. staff buy-in – how to get take-up on the part of employees?
4. program adequacy – how does bad design scuttle the program?
5. adequate resources – support people’s efforts to take up the initiative
6. program champion – a necessary role for organizational change
7. incremental implementation – many new management practices fail in a monolithic imposition
“Master the principles of program success that have already been studied, and really apply to all administrative programs, all management initiatives — not just ERM.”
(E. Robertson 2016) Solving the Enterprise Risk Management Puzzle: Secrets to Successful Implementation
Program implementation — failure and success factors: please see the resources I listed in
[edited for clarity]
This is Episode 5: the principles of successful enterprise risk management implementation.
In this episode we try to answer the question of how to ensure an enterprise risk management regime roll-out that is readily accepted, and that actually endures and continues to deliver value. The answer, in short, is to a master the principles of program success that have already been studied, and really apply to all administrative programs — all management initiatives, not just enterprise risk management.
I’ll put links in the show notes to some sources. Right now, we’ll just consider a distilled list of success factors for program implementation. For each one, I’ll discuss some of the likely implications for your enterprise risk management program.
[01:25] The first one is clear goals and objectives. This might sound a little strange, but it’s actually the lack of clarity of goals and objectives that is often responsible for program failure. Now, a goal is the major accomplishment towards the ultimate aim; the objective is a milestone along the road to the goal. Just as we recommended employing the acronym of SMART goals (specific, measurable, actionable and so on) to the planning itself of the organization, we want to use the same logic to set out the goals and objectives of the enterprise risk management program itself.
This doesn’t have to be too elaborate, and it doesn’t have to be very long-term, either. It has to be clear though. So look at it this way: If we start the enterprise risk management initiative with a series of trial exercises, trial risk ID sessions with different groups, we have to have criteria in mind by which we can assess whether we’re making progress or not. And it’s very simple: if the practitioners are saying positive things; if they’re saying: “this is starting to make sense of our planning… we’re starting to get better clarity on our own goals and objectives in our designed programs… we’re starting to get better cooperation from various team members… we’re started to get a unified spirit and vision on the strategic aim of the organization….” — things like that, then you can say, all right, we’re making progress.
[02:45] Of course the most obvious initial result that we’re looking for is that people report back that they’re Identifying the uncertainty — identifying the risk — that they did not see before, that is inherent in their plans for action.
So I recommend that you make something like this your first objective in the initial stages of enterprise risk management: What is the practitioner response? and Is it moving the organization forward? You can get specific answers with regard to planning clarity and identifying risk… but also leave it open, so that people can report back their various responses. That way you’ll be able to circle back around and correct and improve the program.
You can see that a lack of discipline at this part of the implementation can really mess you up, because if you’re not clear, even on some modest goals that you’re after an initial stages, then the risk is that the the program will sort of go on… it’ll sort of drag on, without any clear positive result. People get more and more discouraged [regarding] what the whole thing is about, and It reflects more and more poorly on your own ability as an administrator or program implementer — whereas, stopping operations to go back and fix what was not working will establish the necessary foundation for the success of the rest of your implementation.
[03:58] The second principle for program implementation success that we wanted to discuss is that of senior executive support, which is I think a familiar issue to most people. I think the way it’s often interpreted is that [we think we have it] if we have nominal support, at least, from a senior executive — if they become the sponsor, or they sign off on the program, or make a kickoff speech to the rest of the group, and so on.
Now that sort of activity can be useful to give the program an official status, or to give it an air of credibility, but strangely enough, it’s not sufficient to make the program successful!
[04:32] What really makes the program successful with regard to executive support is if that support is participatory, if the people in the executive ranks are actually participating in the program; they’re contributing; they’re actively involved in the new program. Now, this doesn’t have to be onerous. It doesn’t have to be such an extensive involvement that it imposes some sort of burden. Let me give you an example. If they actually participate in a strategic planning exercise — or, I should say, risk identification exercise on the strategic plan — then, so much the better. On the other hand, all they need do is say: “For the next project or for the next budget, we need to see a risk assessment attached to the document, and that’s the only way we’ll accept it… so that we’re able to review the risk profile, and also give you some feedback on how you’re actually conducting risk ID.”
[05:25] That means that not only are people getting the impression that senior executive are taking seriously the idea of doing risk identification for major projects and program plans, but the senior people will be able to give feedback on how the risk ID was conducted; whether the categories of analysis were sufficient; whether there was a sufficient number of views around the table; whether the granularity of the analysis was appropriate to the business; and so on.
So you can see that that kind of approach really constitutes meaningful senior executive support that is bound to make the program successful.
[06:00] The next element of program success is staff “buy-in”, or employee support. This could be the subject of the most frequent complaints of program failure. And it’s very frustrating for people who have investigated or studied a certain issue; designed a program to bring to the organization, to help move it forward and to solve certain problems, and yet they find that staff is just not interested. They might have given it even nominal support at the outset, but when it comes to actually practising and doing the thing, they don’t adopt the new habit — and it’s extraordinarily frustrating for a program implementers to run into that problem.
Keep in mind, this applies to all kinds of administrative programs.
So, it might be the employee group that we’re concerned about, or actually take-up by some other constituency, some other intended beneficiary. And the problem could actually be compounded if the lack of take-up or interest in the new program on the part of the intended participants takes different forms, such as avoiding, or actually working around, or sabotaging, or pretending to comply… and so on.
[07:04] We already started to solve this problem by our method, which is to use trial sessions with small groups of participants at the outset, and to ask their feedback. What that implies is that real support is gained only when staff can see and prove to themselves that the new program in question actually helps them get their job done more efficiently: it helps them meet their deliverables and improve the quality of their output, and solve their day-to-day business problems. That is really the secret to getting people to support a new program!
You can’t get there by imposing a solution on them. They have to participate in the design and development of the new program in question. You know, I don’t think this golden rule of implementation — that is, getting staff support in the proper way — is really widely understood. I say that, because what I see people doing quite commonly is to persist in, first of all, the old “command-and-control” methods, where they just impose an edict that says it must be done this way.
Or If they’re more benevolent, they sort of think in the back of their minds: “You know, since this is logical; since this is the right solution (we’ve researched it, we know what the right answer is) — somehow the employees will agree to it!”
Whereas, the employees did not go through that thought process. They don’t really have the same mindset with regard to the new “solution”.
[08:21] Last — I’ll mention mentioned this briefly — you don’t want to get software in place, [that is] you don’t want to have a huge spend on a new software application and installation to try to induce people to take up enterprise risk management, because it simply won’t work that way. No, you might successfully automate, or I should say semi-automate, the process of risk identification, and so on, at a later stage — but it has to be the principle of ownership that is operating at the beginning stage.
That is, people have a sense of ownership in the new practice, because they help build it; they like it; it helps them get their job done — and they’re proud of it.
[08:58] Well let’s talk about success factor #4 now, it’s called program adequacy, or program design.
That just means that the design of the new initiative, the new program in question, is not [may not be] really adequate to the task of solving the originally identified business problem. Now this reason for program failure has been mentioned in the studies; it’s come up in public policy; it also is [present] in the case of enterprise management, I think. People do risk assessment in a way that is not rigorous, that doesn’t have a real structure or method to it, and that’s not really adequate to the task of doing risk identification, and having an actual risk management regime.
But really we already solved that problem by implementing what I call High Quality Risk Assessment, so just check back in prior episodes if you missed that. Let me just make a sidebar remark here that just occurred to me: You know, this list of program success factors which we are considering in regard to your enterprise risk program — of course, I’m sure this has occurred to you — can be brought to the table at any risk identification session, on any given program or project.
[10:00] The next principle of program success, #5 adequate resources. Programs can fail in a variety of ways that are connected to simply having inadequate resources to support people’s activity in the new initiative. In enterprise risk management, I think mostly involves the idea of having, first of all, an intellectual resource, some program champion — ERM champion — who can speak to the logic and the rationale for the new program, and also supply the tools, the templates, the policy, and so on.
[The champion gives] people a place to start, to make sure that they don’t develop things that don’t end up converging upon the company standard.
The other important aspect of resources with regard to ERM roll-out is to recognize that we’re going to do skills transfer. We want the ERM champion, in cooperation with the program leads, to do this experimentation and to develop the risk identification method, and to hand it over to the program leads.
[10:58] That leads us to factor #6, which is the program champion, that is the enterprise risk management champion or risk champion. Having the champion in place just obeys the principle that you need someone to spearhead the program, when it comes to a new initiative in the organization.
The chief reason is not only just the understanding of the benefit, of the rationale, but it’s actually to help people adopt new habits. So if you don’t have a program champion — even if this person is just doing it part time — then you’re expecting people to adopt a new practice, to change their habits, to experiment with a new methodology, and to incorporate the whole rationale in their minds for doing so. And it’s just not going to go very far. You really need that person to inspire and lead the initiative.
[11:44] The last success factor that I want to discuss today is #7 incremental implementation, or gradual implementation. We’ve already implied that this is our working method (that is, gradual implementation) because we’re not going to impose the whole program at once. We’re going to do those trial sessions in the initial stages.
You know, that might sound obvious, but so many programs have failed because people tried to implement in a blanket or monolithic fashion. They want to impose the new management practice all at once, and expect people to take it up, you know, in an instant, at nine o’clock on Monday morning.
The benefits of gradual implementation, though, are really just so profound. You get the chance to stop, fix what’s not working, and then by virtue of doing that you start to get the buy-in. You start to get the ownership that we were talking about before. Not only that, but you haven’t wasted an extraordinary amount of resources, time and effort, and you haven’t put your own reputation unduly at risk as ERM champion or administrative lead.
[12:44] Well that’s a discussion of very common reasons for program failure. But you know, you can add to that. You can actually benefit from the idiosyncratic, unique experience that you have in your own organization, and compile a list of the success factors that reflect the particular work that you do.
So you make notes, and compile lists as you go along, and perhaps make all of this available in a document share facility, so that as people do risk identification on various projects and programs in your organization, they can draw on this list of risk criteria that is really specially developed for their own particular business.
[13:20] Well let’s summarize what we covered today.
I made a distilled seven-point list of success factors, or principles of program success, drawn from the literature, which you can apply to your enterprise risk management program. Now, for that matter, you can use this list, as I mentioned, as risk criteria to bring to any risk ID, on a program or project within your organization’s business. Of course, the very same applies to any initiative that you might lead in any domain in your future career.
The success factors are:
#1. clear program goals and objectives;
#2. senior executive support that is participatory in nature;
#3. staff buy-in that leads to ownership;
#4. program adequacy, the initiative in actually solves the originally identified business problem;
#5. adequate resources;
#6. program champion; and
#7. incremental or gradual implementation.
In the next episode, I’m going to discuss in more detail common challenges to enterprise risk management programs, and how to solve them.