I wrote this article in 2012 for a foreign speaking engagement. It gives a short overview of risk management evolution in the Belgian federal government.
When speaking about risk management, many people assume that the main drive started in 2004, after the publication of the long awaited COSO ERM. Quite often, public sector practices tend to run behind the curve of private sector initiatives, often by as much as 10 years. For Belgium, however, this was the exception. By the time of COSO ERM publication, we already had one federal government service which had performed an entity-wide strategic assessment in 2002 and a operational assessment on one of its core activities in 2003. This federal government service was Mobility & Transportation, whose risk management practices were recognized in 2009 as the best Risk Management approach in European public sector bij Strategic Risk, a think tank of leading risk managers from across Europe.
Some history
Risk management was not adopted in Belgian federal government services because it was the next management fad. We started to develop this out of pure necessity. At the back end of the federal reforms of the late 1990’s and early 2000’s, aptly named Copernicus for the great turnaround they were aimed to achieve, came the realization that more autonomy for public sector entities meant there was a need for a higher level of control in the processes. However, with no significant increases in the number of public servants, more had to be done with the same number of people, and in most cases even with less. Where before controls were placed where possible, the new focus was to manage key exposures. But in order to manage key exposures, you need to be able to identify these key exposures.
The Copernicus reform had developed a theoretical framework, ORCA, which in practice turned out to be difficult to implement. Mobility & Transportation, itself subject to a major overhaul of one of its key departments, air transportation, learnt us the hard way that in order to be able to implement risk management, you needed a methodology that allowed for a pragmatic approach.
Its president, Michel Damar, in close collaboration with its audit committee, charged its internal audit division, then three people strong, to put audits on hold for a while and focus on the development of the approach. From 2002 until 2009 the federal government service invested time and means in becoming a leading practice in risk management. The risk management function was firmly embedded in its day-to-day activities. While a significant number of aspects of the initial approach have developed almost beyond recognition as compared to the initial structures, key elements to this day still remain. Rather than take you through the entire approach, let me illustrate what helped MobiRisk to become a mainstream element of management.
I will discuss four elements which have really contributed to our risk management approach to become an obiquitous tool for management and a basis for further development in other federal government services, such as Public Health, and even beyond.
Open development
Relatively soon after the first drafts of the methodology had been developed, we started presenting the approach to other federal government services, such as Finance, Justice and Personnel & Development. The approach was also presented to the Finance Inspection. Each of these presentations led to an, often informal, exchange of views and ideas which were incorporated in the methodology. Thus, rather than developing an approach in an ivory tower and only testing it during implementation, the development was open.
This openness extended to the public servants of the federal government service during implementation. They started developing their own solutions on top of the core methodology, leading to an application in air safety and an application in rail safety developed by engineers enthousiastic about the opportunities for quantification the approach offered.
The first lesson is that many different points of view made any errors in the development shallow. This finding is completely in line with findings in other areas, such as collaborative software development. Someone somewhere often had the solution for what was bothering someone else. These lessons were directly incorporated in the methodology.
Tone at the top
While a significant amount of development had been done by the middle of 2004, the project continued at a more leisurely pace throughout the years afterwards, up until 2008-2009, when the responsibility for risk management was transferred from the internal audit department to a dedicated function within management control. Throughout this long period, support from the subsequent presidents in charge of the federal government service was unwavering.
This was very important because after the first risk analyses ran, the results were discouraging. There were risks everywhere and not enough risk controls. This is often more the rule than the exception. The risks had been there all along, they were just never adequately identified. Good leaders see this as an opportunity rather than a threat.
The second lesson is that a supportive tone at the top combined with a real strong champion is essential for making this type of project a success. Even when the results turn out to be bad at first, and they will, this type of initiative needs to be supported.
If it is not broken, it need not be fixed
A key technical aspect of the methodology says that once a full risk analysis and risk management cycle has been executed, it provides a comprehensive view on the risks. As long as no risk influencing events happen and the indicators remain within their limits, no additional actions need to be taken other than traditional monitoring.
This was an important departure from traditional risk management methods which required a regular re-assessment, whether or not anything had changed. Our approach deems such efforts to be futile, irrelevant and even irresponsible. On the other hand, the initial assessment needs to be done in-depth, which takes a considerable investment. However, once the initial “static” (initial) assessment has been executed and risk management systems have been put in place and monitored, only new and no longer relevant risks require a new risk management initiative, aptly named the dynamic, recurring phase. Key efforts go to monitoring the risks and new risk occurrences, rather than refocusing again and again on known and understood risks.
The third lesson is that risk management efforts, often used as a reason not to go down the path of comprehensive risk management development, need not be overly time- and effort intensive. Rather, if the initial assessment and risk management is performed well, significant time and effort can be saved in the longer run because the risks are known, understood and monitored.
A common language
The last, but not the least important aspect of the methodology was the development of a comprehensive risk identification model. This model is both a dictionary and a tool. We noted quite early in the project that people were using the same words with slightly or even fundamentally different meaning. This led to misunderstandings, to loss of time and on occasion to a complete failure to adequately address the risks.
We decided to make a comprehensive list of all possible risks that could be encountered with regard to its responsibilities. The more than 800 risks initially identified where gathered in so-called risk types, groups of similar risks that could be described in a coherent fashion. These were in turn gathered in risk categories. Categories relate to where risks could occur: in the environment of the organization, such as budgetary limits, in its operations, such as process optimization issues and human resources aspects such as motivation, or in its decision taking, such as risk related to lack of correct performance indicators. We ended up with about 80 risk types in three distinct risk categories. To date, these have managed to describe about 95% of all risks encountered.
All participants have access to this risk identification model and can “translate” their risks to the risks as present in the model. The model is dynamic in that it is regularly reviewed for further adaptations and refinement. A public sector provider of software services to mainly social security related organizations for example has recently adopted the approach and added a full section on project risk management.
The model can also be used as a checklist during risk management meetings, to make sure all relevant risks have been discussed or treated.
The fourth and last lesson is that in order to be able to execute risk management, you need to speak the common language of risk. Risk identification models have dual purpose in that they provide you with a vocabulary and with a tool to check completeness of risk treatment.
Exploring The Black Box 