Project Tracking Risk Frameworks
Risk management at an enterprise level sits in several states of completeness.
There is the 'before state' where risks might be controlled by business unit staff but the management of them is not specifically formalised.
To think about this differently, Risk Framework Architects and consultants generally Design, Build, Operate and then Transfer their work outputs and, they should be tracking 'completeness positions' across their projects. The tracking of risk management coverage and the subsequent reporting of this to stakeholders will improve the harmony between management, the business and the risk department.
When executive management decide to formally engage in the development of a risk management framework, they have to accept that it takes time to complete this work. Simply saying we have chosen to deploy an enterprise wide risk identification, assessment and treatment program doesn’t mean it’s done, until it’s really done. There are also a lot of risk managers out there that fail to set, project manage or track Key Performance Indicators around the deployment of their risk systems.
We have to be a little bit real here for a moment because departments in an institution aren’t going to stumble into the risk management program by accident and simply deploying a risk software package on an intranet doesn’t make the risk management framework complete. Staff won’t know what is required of them and risk management policy will inevitably be applied unevenly across the target business.
This divide between impatient and often unrealistic stakeholder expectations, coupled with the failure of a risk manager's ability to track performance on their own work and in a ‘project like’ manner, is sound basis for dispute.
It doesn’t have to be this way, especially when ISO 31000 lends itself well to being project managed. Clause 5 of the ISO 31000 standard is a set of steps, individual pieces of work if you prefer that are interlinked but can be deployed across a business in discretely packaged units of work.
In the diagram above, we can see the position of completeness for each element of Clause 5 of the ISO 31000 standard and for each department in the deployment plan. We also have to accept that business units have day to day work to do and risk managers can’t expect a single department to go from no formalised risk management practices to full internal compliance in a day, it takes time.
As a risk manager, if you want a harmonious relationship with your stakeholders, I seriously recommend you manage risk deployment programs as if they are a project and report current positions of completeness.
Finally, flagging a department as fully complete on the risk coverage map or management stating they are operating all aspects of a risk framework effectively, does not translate to a department having zero risk. This should be obvious but it is very concerning to hear anyone in an organisation say we are fully compliant with the risk management procedures and consequently we don’t have any risk. This is ridiculous when risk is in effect uncertainty on objectives and uncertainty will nearly always prevail in much of what we do, process, control or trade.
