How to Manage Risk Proactively
Innovation means doing something that has never been done before. And that’s fraught with risk. In new product development, innovation may entail technical risk, market risk, risk relating to outside partners, or even political events far beyond your control. No new product development program can avoid risk.
However, much more than business-as-usual can be done to anticipate and mitigate risks proactively. With forethought and planning, teams can at least get a head start in identifying likely challenges and then creating the basics of an action plan should the risk become reality.
Risks are about the future, about probabilities. Even if we can anticipate risks, their consequences are rarely predictable. But product development teams are not powerless; they don’t need to merely hope for the best. Teams have an often untapped ability to anticipate what might go wrong, and to make educated estimates of what they might need to do to address the problem. This is a form of latent knowledge that cross-functional teams possess. What is required is a tool that coaxes out of the team this tacit knowledge.
We have used a risk management matrix as a part of a suite of product portfolio management tools. The risk management matrix is most useful in the early phases of a project, when no more than about 15% of the project is complete. Creating the matrix is part of a team or group exercise, where participants are asked to identify and capture risks as the first column of the matrix. The team leader may begin the process by filling in some of these risks. Product plans and project schedules and other artifacts may be used to explore different categories of risk, for example technical risks, risks related to resources, to communication and team interactions, etc. Then, in a group exercise, the team expands on this list.
The members then come to an agreement on the impact on the project of each proposed risk and the likelihood of it happening. These are rated on scale of one to ten, with one representing the lowest possible impact and likelihood. There may be some arguing and haggling over these risks, but the team should eventually come to an agreement. These ratings are subjective but that doesn’t mean they’re arbitrary. Your experienced team members have seen a great deal, and their wisdom is conveyed in how they rate these anticipated risks. Stark differences between how two team members rate the impact and likelihood may surface challenges in how different functions interpret their respective work on the project.
Next, the team agrees on a metric, a quantitative measure that would indicate that the anticipated risk has occurred. The team then agrees upon a threshold value for the metric that is used to trigger corrective action. For example, one team was depending on an outside partner to make a complicated component. As they scaled to market, they risked having unacceptable numbers of defects in these components. The team agreed that defects per one thousand would be the metric, and that if the number of defects rose to X number per thousand, then corrective action should follow.
The final portion of the process of creating the matrix is to agree on mitigation plans, i.e. what corrective action should the team begin to take if the threshold value is exceeded? These plans do not need to be too detailed. No sense wasting time thinking through too many details to manage problems that might not occur. But for each risk on the matrix, the team should have thought through a starting point for course correction should the risk occur