Blog

Can You Manage Risk While Innovating?

Anticipating and Mitigating Risk

Risk Management Matrix

What Is the Tool? Risk Management Matrix

The Risk Reduction Matrix is an elegant way to anticipate, manage, and mitigate product development risks. A common myth is that you can’t take the risk out of invention, but in reality you can significantly reduce risk even in the most inventive programs by anticipating it. The benefit of this new approach for risk reduction is that you can use the entire cross-functional team to create the matrix. Although you may have used a similar tool before, the benefit of this methodology is that there is a specific risk trigger point (a quantitative threshold) as well as a mitigating action plan if you exceed that threshold. When combined together, they make this approach much more effective than the more subjective prior approaches.

The matrix consists of a list of risks versus criteria and assumptions. The risks themselves are in the first column and act as headers for each row, which teases apart each risk. The column headings consist of risk attributes such as likelihood, consequence, and its measure. The likelihood and consequence are on one-to-ten scales, with one being essentially impossible and zero impact respectively. The measure is a quantified metric of the risk parameter (or an indicator of risk). The remaining headings are the risk threshold, the date by which the threshold should be equaled, and finally a short phrase that outlines the action plan.

The cross-functional team creates the matrix in a workshop fashion. The project manager usually leads the session and plans ahead by creating the bones of the matrix where they list some of the likely risks and fill out the rest of the attributes and risk management factors. The project manager can often derive those risks from the list of boundary review conditions. The creation of this matrix should take place during the first 10-15% of a project’s duration.

After creating the tool, you can use it on an ongoing basis by quickly reviewing it at the weekly team meetings. The goal is to walk through any of the critical metrics, add new metrics as they occur, and remove the old ones if their risk has been eliminated. When a trigger point occurs, it is time to review the action plan and put remediation in gear. Based on new knowledge, you may update and modify it. The secret, however, is to act and not wait for “things to get better” on their own because they rarely do.

What’s New?

The new parts of this approach are the use of quantitative trigger points and the creation of an action plan in the clear light of sanity far before the raging red lights start flashing when you have to deal with a risk item that blows up. In addition, by including the entire team (typically five to 15) in the formation of the Risk Reduction Matrix, you get a more robust matrix and team buy-in as a by-product.

Benefits

• Identification of risks before they occur
• Reduction of risk impact due to early detection
• Quantitative metrics that help inhibit the knee-jerk reliance on the subjective
• Accelerated actions because of the clear thresholds and the agreement to follow the process

Which Business Problems Do We Solve?

You might consider risk management the evil twin sister of innovation. Ultimately a break from the past, innovation inherently brings with it additional risks, which you can still manage. One way to manage those risks is through micromanagement, but this obviously quenches innovation. The other way, consistent with the increasing desire to delegate authority and empower teams, is to have the team manage risk on their own. Another way to reinforce autonomy is to line up the risk thresholds with the boundary conditions, which are the summary of the agreement between management and the project team on the critical aspects of the program. If the team does not cross the boundary limits or violate the risk conditions, then they can and should operate independently from micromanagement.

From a larger business perspective, having a risk management system in place helps improve project execution because it can help the team anticipate, prevent, and mitigate risks, which can result in delays or additional project expenses. The team often blows their budget or gets delayed when unanticipated risks fall in their path, and then it is “all hands on deck”. Unfortunately, while the team solves the problem, the schedule marches on and the project expenses go through the roof. By minimizing or avoiding risks, you can minimize or avoid delays and budget overruns.

What Else Should You Know?

The Risk Reduction Matrix is only as good as the inputs in its initial formulation. Having the right cross-functional participation and functional specialists when you create the matrix is essential. Teams often add one or two principal engineers for this exercise to help them come up with a deeper, more comprehensive, and more thoughtful list of risks. While it is important to have the right people and follow a process to fill out the matrix, the assignment of values to likelihood and consequence (or impact) can get out of hand. It is important that you mainly try to identify the high- and medium-impact risks that can possibly happen. If you get stuck in assigning values, try pairwise comparison and cross-check the values you assigned.

Once you generate a quality matrix, your next concern will be the real-time monitoring and updating of that matrix. As time goes by, you should remove the risks that are unlikely to happen. Conversely, you should add new risks when needed to reflect a more current perspective.

The seduction of hope is probably the biggest risk in the application of this tool. Don’t be a “prisoner of hope” because there is an often false belief that the risk will just go away on its own or will be worn down by working harder. Make sure that when a risk trigger is crossed, you take action immediately. Remember when you had a clear perspective at the beginning of the project. What has changed? It is likely that nothing has really changed except that you are now under pressure to deliver and have many issues to worry about.

Case Study

WebCo is about to kick off a multi-site next-generation home finance project that leverages all of the geographies in important ways (and for the first time). Brian, the project manager, and Molly, the product manager, got together after agreeing on the importance of doing a risk management exercise. Their first step was to create a rough draft of the Risk Reduction Matrix. The first draft included teamwork and example likelihood and consequence ratings. Using this as a starting place, they called a team meeting with a global teleconference and invited two architects to participate as well.

The team reviewed Brian and Molly’s initial work before the meeting and came prepared. After an hour and a half, they listed the following risks on this initial round: team communication, server responsiveness, data integrity, usability, and financial partnership agreements. The initial table had the following trigger metrics and values: meeting frequency (2x per week), server responsiveness (250ms with a load of 100 users), screen data integrity (100% of screen data acquired no matter what error message), and financial partner signup frequency (15 partners signed per week).

The project team put the matrix on their wiki site and reviewed it on a weekly basis. Although we don’t know yet how the matrix impacted the project’s final outcome, we can say that, six weeks into the project’s design phase, the requirements for the home finance software included mobile device compatibility as well. The team added this requirement to the risk matrix after they had an out-of-bounds review, which would impact the schedule unless resources were added to the team. We can say that both the matrix and weekly review have kept the team’s communication sufficient for this new global approach and also indicated that the new mobile requirement is on schedule.

Visualization

Below is a risk matrix for the case study illustrated above. The “impact and “likelihood” columns are on scales from one to ten, where one indicates zero risk and absolutely no impact on the project. A rating of five in the case of impact means that the risk has one half of the largest negative impact conceivable, such as a two- to three-month slip for a nine-month program. Similarly, a five on the likelihood scale means one half of the typical likelihood, which would be on the order of 50%.

The “metric” is the measurable quantity associated with the risk. The “threshold” is the value you must hit by the time you ship (unless otherwise stated). The “date” is the time by which the performance must equal or exceed the threshold value unless it is the date by which you are monitoring the metric. Finally, the “action plan” column indicates the high-level objectives of an action plan. It may refer to a much more detailed action plan, which should be sufficiently described so that a reader of the Risk Reduction Matrix has a sense of what will take place if you trigger a threshold.

Tags: Best Practices, Product Development Best Practices