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 a 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 in 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.
Consider the example risk management matrix below. In the first column, they identified poor communication, week-to-week, as a risk for their project. They rated the impact of poor communication as middling (4), but the likelihood was pretty high (7). They decided that meetings per week was the best and simplest metric. They looked back over the past few months and saw that a rate of 2.5 meetings per week was working, but that if it backslid to 2 meetings per week then that would be too little communication. The team set the threshold value for their metric as 2 meetings per week, and if the number of meetings fell to two or fewer per week, then the team would take action. They discussed investing in videoconferencing equipment or changing incentives to encourage participation in meetings.
This tool is not a silver bullet. It’s a leg up on risk management. It is especially useful for the process it puts the team through. Its most useful aspect is that it invites the team to think risks through, to make public, concerns that in many cases had previously been private. It takes each team member’s concerns and makes them team property. Making conscious the nagging concerns in the back of the minds of team members is liberating. It frees up the energy to concentrate on innovation, as it draws on the wisdom of the team to begin to solve predictable issues before they occur.
