Opinion: Risk management in the agile world

Recently I was attending a sales conference and introduced myself as being from risk and compliance to which one salesman responded “You mean the business impediment team.” There needs to be much more to risk management than simply saying “no” to things, and the age-old five-step approach is long overdue for transformation.

The disconnect between risk management and innovation

Leading businesses are changing the way they develop both new and existing products and services. There are countless books, TEDTalks and training courses available today that are designed to help businesses revamp their waterfall project groups and restructure them into agile cross-functional teams in order to produce faster, superior results. Innovation is not just a buzz-word anymore - it is fast becoming the default way of working for businesses across the globe. In order to remain relevant in this ever-changing environment and also to reduce tension that is fast growing with the rest of the business, risk management needs an overhaul.

Start with recognising a need for time-adjustment

I’m going to be a little controversial now: Risk management takes too long to be effective. Or more accurately, traditional risk management processes that we know, use and promote today do. Within a truly innovative business the risks evolve on a daily basis and by the time the traditional risk management steps have been undertaken, the results are already out of date. The time it takes to get through the five steps diminishes the overall value of the process.

It’s not just about the duration of these processes though, which could be sped up by building efficiencies into the way the steps are undertaken, but also about the reflective nature of the process itself. Risk assessment reports and registers are useful for painting a picture of a specific point in time in the development of a product, but add no value to the innovation cycle itself. If risk management aims only to provide information to senior management on the risks that have already been taken, then the processes is effective. But if the purpose of risk management is truly to identify potential problems before they occur so they can be treated, then risk managers need to find a way of communicating continuously with the agile teams.

Location, location, location

One of my perpetual frustrations throughout my career revolves around the separation of much of the risk management function from the rest of the business. I do not believe the three lines of defense model provides the value it is purported to, but instead I feel that having a large second line risk management team only serves to perpetuate the “us versus them” dichotomy with the business.

In a truly agile cross-functional product development team, every team member is empowered to do what needs to be done to create the best user-centric product imaginable. Decisions on the direction of the product are made right there in the room where the team develops, tests, deploys, reviews and then redevelops. Risk managers have no choice then but to change the way they execute in order to ensure that risk is considered within these processes. To do this, either the risk manager must be in the room, or someone in the room must learn to be the risk manager.

Risk managers need to expand their skillsets to ensure that they can add value if they are brought into an agile team. They also need to stop just saying that everyone is a risk manager, and start teaching colleagues how to think like a risk manager. If people from different roles and backgrounds are taught how to identify and properly consider risks in their own area of expertise, then reviewing risks after the fact can be left to Internal Audit.

The question of appetite

The Risk Appetite Statement (RAS) of a business outlines the tolerances within which the business can operate. It directs staff to what they are allowed to do and acts as a constraint on the way they may conduct business in order to meet the company’s strategic goals. For a business that is content with remaining the same as it has always been, this approach is naturally appropriate.

Innovative businesses, however, should aim to use risk appetite not as a constraint but as an opportunity by creating a principle-based statement that agile teams can use to guide their experiments. This statement should cover not only downside risks, but opportunity risks including the kinds of opportunities the business has an appetite to explore. Risk managers should test if their RAS is holding their business back from innovating by considering whether or not it is providing a series of rules for staff to follow rather than principles for them to interpret. If it is the former then chances are the RAS needs an overhaul.

Using a principle-based approach will enable the development teams to challenge the risk settings previously held by the business as it pushes the boundaries of what the business does. It will also help to flag areas of concern as new risks are discovered and defined throughout the innovation process. Enabling teams to ask themselves “Why can’t I?” when entering into new arenas encourages innovative yet mindful thinking within the teams.

Taking a leaf from the technology book

If you agree that the traditional risk management five-step process is out of date and no longer adding value, then you may be asking yourself which framework to replace it with. I believe this is where our technology colleagues can help. Cyber security as an industry is largely kept separate to general risk management, and therefore many businesses manage technology risks separate to their general business risks. One of the downfalls of this approach is that neither industry is effectively learning from the other.

The National Institute of Standards and Technology (NIST) run by the U.S. Department of Commerce is leading the way of managing cyber risks by developing the NIST Cyber Security Framework. This framework outlines five activities that should be undertaken to manage cyber risks. Conveniently, these five activities can also be applied more broadly.

• IDENTIFY – Identify the business context of the activities being undertaken including what assets and boundaries you are working within so that risks can be identified. In order for this to traverse more than just cyber security elements, risk managers need to educate all team members on how to identify broader risks such as those relating to brand and reputation.
• PROTECT – Develop and implement the appropriate safeguards to prevent the risk from materialising (or not materialising if it is an opportunity risk).
• DETECT – Too often there is an imbalance between the effort put towards mitigating a risk and the effort put into detecting if an incident has occurred. Having the ability to detect an incident is just as important as trying to prevent it, especially in this increasingly digital world.
• RESPOND – Plan for events and build the business response capabilities. Incident managers should be educating innovation teams on their processes so they can both work within them and challenge them as innovation stretches beyond the existing frame of reference.
• RECOVER – Focus on building resilience into the business across all facets of product management and development. The focus should be on recovery planning and communications both internally and externally. If resilience is a focus of the teams when the products are being built, then it should also be a result of the eventual product.

Not another report…

On the surface the above may seem like just a revamped version of the five step process currently within risk management, but I argue there are two distinct differences that will deliver measurable results.

First, the process is forward-focused rather than reflective. These activities are undertaken at the time the risks are created rather than at the end of the process. To ensure they are being recorded appropriately, the risk managers’ role should shift to ensuring discipline remains in the way the team manages risk.

Second, there is no value in producing a product risk assessment or register. You may have walked past a project room and seen rows and rows of post-it notes or coloured cards sorted all over the walls. Chances are these cards include details of individual features of the product being developed, which have been meticulously prioritised by the team to ensure they are always working on the feature that brings the greatest value to the project at that time. Relevant risks should be recorded on each card to ensure they are ranked and evaluated at the same time. Risks will then be considered and addressed as the products themselves are created.

Reporting to senior management on the risks being discovered and managed will still be required, but no longer will risk managers need to call separate workshops that waste time in order to produce these reports. They can simply monitor and record the risks that are captured on the cards.

Reputation of risk managers

I believe businesses that focus on making the above changes will improve the reputation of their risk management division in the eyes of their colleagues. By joining the teams working on building the future of the business, the “us versus them” dichotomy will diminish, and risk management will become a genuine partner in the efforts to bring strategic business outcomes to fruition.