Over the years and after learning from almost every mistake possible.
I have come to appreciate that there are some fundamental steps to any successful IRM implementation.
Context (The why?)
Why is someone implementing Integrated Risk Management? What has motivated an organisation to change how they work and institute a formal enterprise risk management process?
The context is important as it will shape not only your discussions but also the goals and objectives.
For example:
- Is the company worried that they do not understand their risk position and have no visibility or where they need to focus their attention?
- Is the organisation striving for compliance to complex regulations and needs a way of tracking and showing that they are?
- Has the organisation just been audited and found lacking?
The context of why you are engaging with these people is paramount in understanding the journey.
This will be the starting point but as you know an IRM(IRM) journey is a 3 -5-year marathon, not a sprint. Which means you also need to understand:
- The long-term goals and vision
- Where do they want to be not just what do they need today
- The context will allow you to chart their maturity and the roadmap in front of them.
Scope (The what and the who?)
So, you understand why a customer is talking to you, now comes the hard part.
The scope can have a major influence on the success or failure of a project.
- Try to do too much too fast and you will overwhelm the userbase.
- Try to do too little and the project will not show any ROI and will wither on the vine.
When starting an IRM project, the first phase of the project is the beachhead.
The business in general is used to how they work and are not eager for change, this first phase is about showing how things will make life easier for them.
Surprising or not, this is not about technology, it’s about people.
Organisation change will determine if this project is a success or not.
The WHAT of the first phase needs to show the value, so pick a part of the business that is willing to embrace change or the most valuable crown jewels of the company and show how that area can connect with the why in the context.
The WHO comes from the data.
Good data can make projects run smoothly, bad data can increase the length of the project and drastically reduce its impact.
- Do you know WHO owns the objects in the WHAT?
- Can we assign the WHO risks and controls to manage?
- WHO oversees the processes and needs to be a part of it?
Understanding the data that will drive the process ahead of time will make the project run much more smoothly.
Visibility
The last pillar is understanding the HOW.
How do they currently report, what reports do they have and are they required going forward?
How does the information need to be presented, what different levels of visibility are there?
Does the entire organisation need to see the information or is it a small set of people?
Working back from what the board need to see and then what the lower levels need to see, you can understand what needs to be in place from day one.
That makes setting up metrics and indicators, reports, and exports easier if they were already in architecture from the beginning rather than trying to retrofit things later.
Conclusion
Like any good architect, engineer, or scientist, having a clear vision of what they are trying to achieve is key.
The lunar lander Eagle on Apollo 11 was perfect for landing on the moon but would be terrible for any other purpose.
Taking the time to understand what we are trying to do before rushing in and building will save you many hours of suffering and help lead to more successful projects.
While not the only keys to success they have helped me on many occasions.
Disclaimer: This content was not produced using AI but it the random outpouring of my brain which I hope was of use to someone.
