are risk registers obsolete
the journal of Michael Werneburg
twenty-seven years and one million words
I founded the risk management function at PortfolioAid—a provider of technical solutions to the financial industry—just as the firm was entering a period of aggressive growth. The mission of the risk function was to eliminate uncertainty in continuity of business, releases of our software product, and operational stability across the board. To manage operational risks, I designed a process that centered on a risk register. The register listed those risks to operational success that were identified in the routine course of business. One by one, new risks went through a process of identification, classification, and prioritization. Where a risk was to be mitigated, actions were identified and assigned to owners with the skills and the authority to see them through.
In our first year, eliminated several “risks” in a flurry of activity, fixing potential problems in every corner of the firm’s operations before they happened. It felt like we were making an impact, and our auditors were happy with the process and the results.
But after that initial period, things began to change. The list of “risks” in the register was no longer turning over with the same speed. Attendees of the quarterly operational risk meetings seemed to lack the businesslike energy they brought to other activities, but couldn’t enunciate any improvements. When I implemented some reforms on my own, eliminating likelihood and impact ratings (I’d been reading Douglas Hubbard’s The Failure of Risk Management), it didn’t even garner discussion.
At that point I took notice. In my experience, changes to business processes that are truly key take a lot of work. At PortfolioAid, I’d instituted a variety of other procedures, including release management, incident management, and an IT steering committee. I’d also implemented a procedure of internal control with documents for all processes, and self-assessments carried out by the functional managers on a quarterly basis. All of these had increased the firm’s workload, at least initially, but each had found early and repeat success and all had eventually found broad acceptance. But none could be simply reformed with the snap of a finger.
I began to wonder about our operational risk management methodology.
I started to notice changes in the nature of the “risks” being tracked. For one thing, they were fewer in number. In general the new risks seemed to lack the clarity and urgency of items from the first era. In some cases, there was a great deal of dependency between different risks, and even listing the risks in a spreadsheet in a clear fashion was hard. In other situations, risk was clearly present but their severity was variable. To slot these situations into a risk register would have required several entries with nearly identical descriptions, distinguished perhaps on one or two variables, but primarily on their different degrees of impact. For instance, how to slot all of the potential outcomes of developing a new software platform into a risk register?
The breakthrough
The breakthrough came when I realized that as a firm, both our thinking about risk and our means for dealing with remedies had already moved beyond the risk register.
The planning discussions held by the management team now involved more analysis of risk. This led to better understand the range of possibilities resulting from the company’s undertakings, and to make decisions involving risk at a more appropriate point in the planning process without the stilted confines of a risk register.
At the same time, the internal control function had matured to the point that each area of the business had mapped its processes not only to objectives but to risks; and from those risks to controls. Processes had all been assigned an owner, who reviewed their documentation annually at a minimum. These practices had virtually eliminated unwanted variability in our operations. Gone were the uncertainties of process, roles and responsibilities, and questions of adherence to standards. Gone were new “risks” for the register resulting from process change, because any areas of uncertainty were being ironed out by the process owner as they were found.
Finally, our firm had established a program management office (PMO). The risk register, with its list of tasks, was increasingly redundant to the project tracking function of the PMO. Instead of chasing people up around the organization, metaphorically waving my risk register around, I could simply sponsor projects for the PMO to prioritize and see to completion.
I was still pondering all of these moving pieces when I received an email from Matthew Leitch, a British researcher into risk management who publishes some of the best guidance I’ve found in the field. In a series of posts, he had laid out review of what he calls “risk-listing” that help me understand what I’d been wrestling with. Leitch writes extensively on the short-comings of the risk register approach, which treats risks as tangible items outside of normal business management “science”. He rejects the methodology soundly for many of the same reasons I outline above and many that I hadn’t considered. With extensive support based on industry research, I found his arguments both revelatory and motivating. For anyone using a risk management process based on a risk register and wondering how well the whole thing is working, I strongly recommend Leitch’s work.
So is the risk register obsolete?
I now look at a risk register process to the training wheels on a child’s bicycle. Kids today are taught from day one to ride on a bike without pedals that teaches balance and momentum and the joy of real riding. They start off unencumbered, and I think that’s the way to go with a new risk management function. If I ever encounter a risk register approach in the future, I’ll advocate for the stronger tools of risk-aware decision-making, a strong internal control process, and a streamlined relationship with the PMO.