Risk management implementation projects are not easy. When they are done right, though, they create a new view into your organization. My earlier posts talked about the importance of establishing overall expectations and managing the data that you will be collecting. This post talks about two additional foundation steps to get your implementation project off to a solid start.
Develop reasonable project steps
The project must be divided into manageable steps. It’s not realistic to believe that an organization can identify every risk during a single brainstorming session. The topic is far too broad. Instead, the project must be divided into specific risk assessment areas.
An organization has the option to proceed top-down or bottom-up. There are advantages to both.
A top-down approach consists of identifying high level activities along with their associated risks. These high level activities could be grouped around clearly defined strategic objectives. Alternatively, they could be organized around general categories such as financial reporting activities, legal and regulatory compliance activities, manufacturing activities, etc. In highly diversified organizations, it might make sense to focus on the unique top-level objectives and risks for individual business units.
A bottom-up approach consists of focusing on very specific activities and associated risks at the lowest level of the organization. This can be easier to define because an organization can simply point to a specific department within a specific area or, even, a specific individual in order to identify objectives and associate risks.
Regardless of how you divide the project, the goal is to identify what each particular area is attempting to accomplish and the things that could go wrong (the risks). This consists of interviewing management and consulting other resources to assure that all of the activities and risks are reasonably identified.
Critical Implementation Requirement
Decide on a top-down, bottom-up, or hybrid approach to breaking down activities and identifying risks.
Determine how the implementation project will proceed through the organization
An implementation project could start at a high level, focusing on identifying strategic risks first, or at a lower level focusing on procedural risks, or somewhere in between. The question, now, isn’t where the project starts. Instead, it’s the direction and extent to which the project moves from area to area.
If the project starts at a high level focusing on, say, 8 strategic categories and associated risks, then it might move down into each next-level subsidiary organization and determine how each subsidiary addresses those 8 same strategic categories adding whatever additional associated risks that might uniquely apply. Or, perhaps the project addresses only a single next-level subsidiary. In turn, the project could then dive deeper into that single subsidiary’s divisions, and departments, to get increasingly specific in terms of the processes and risks that support those strategic categories.
On the other hand, if the project starts at a low level focusing on specific procedures and risks in a single department, it might move to other departments within the same division. This would develop a view of practical risks that eventually encompass a particular business unit. Or, perhaps, the project next moves to a similar function in a different division. With this approach, the project builds a broader sense of risks within a single function (e.g. “cash management”).
Critical Implementation Requirement
Decide how the project should move through the organization. It must be methodical. But by selecting one approach over another, the project will be aggregating its knowledge in different ways throughout all of the interim steps.
This finishes the discussion of the foundation for a risk management implementation project. Next, I’ll offer what I think are reasonable (and unreasonable) expectations for a risk management implementation project.