2002 Product Development Management Columns

Those old enough to remember when TV was black and white will recall Joe Friday, the nothing-but-business Los Angeles police detective. When interviewing witnesses, he went straight for the facts with no social intercourse and no embellishment or elaboration.

Perhaps Friday’s style didn’t win him many friends, but had he been a product developer, his projects would have been completed on time, on budget, and met customer requirements. Joe would have been a master at both identifying the risks lurking within a development project and formulating plans to resolve them before they spoiled his project.

Project manager Guy Merritt and I have been exploring leading practices in managing project risks while preparing a book on this subject. Three essential characteristics of effective risk management stand out. One that is quite apparent is that risk management must be proactive in order to identify and resolve risks while one still has advantageous options available. Secondly, risks must be viewed cross-functionally, because few of them are solely technical. The third characteristic of effective risk management, however, being fact-based, is less obvious.

Unfortunately, risk is a concept about which each of us already knows too much. Due to our personal experience with life’s risks, we each operate from our own presumptions and biases. This means that when you assemble a cross-functional team to identify and manage your project’s risks, each team member will operate from a different script. You will have great difficulty agreeing on which risks to counteract or how to counteract them. Worse, you may uncover so many real and imagined risks that you scare yourselves and management into believing that your project will never succeed.

Facts about your project’s risks are the solution to these difficulties. Initially, when you are brainstorming with your team to identify possible risks, facts about them would amount to judging, which clearly runs counter to the rules of brainstorming. At this stage, Joe Friday’s single-minded style inhibits imagination and the free flow of ideas. However, you will all need to know some facts about your project, such as its scope, target customers, and areas of innovation, in order to suggest pertinent risks.

Friday enters once you have a list of risk candidates to work with. Now you have to get tough on these candidates, asking probing questions, such as, “What makes you believe that this might happen?” If you can’t come up with some compelling facts—which we call drivers—to support your risk, then you have only an imagined risk, which you can then discard.

But this is just one of the benefits of identifying these drivers. Drivers are what you use to quantify your risk and assess it. Drivers allow you to estimate the likelihood of the actual occurrence of a risk—and if one does occur, what its consequences will be. Furthermore, drivers form the basis of understanding about a risk, so that the team can agree on the seriousness of the risk. Without the underlying facts, attempting to reach agreement among the team on something as intangible as probability of occurrence becomes nothing more than a debating match.

Most importantly, your drivers will guide you toward effective ways of mitigating the risk, what we call risk resolution plans. Many people develop such plans to counteract the risk itself, but this is treating the symptom rather than its causes. Effective risk resolution plans target the underlying facts that could cause the risk to occur. In fact, the way we prefer to formulate such plans is to consider a separate plan to address each listed driver. In short, if you would like to neutralize those unseen gremlins that threaten your project, don’t concentrate on the gremlin itself, but instead on the facts that lead you to believe in the gremlin.