ValueShepherd.com: Thoughts on R&D Management

 

Commentary

 Home

About

Contact

Risk Management

Summary
Executives responsible for new product development should have a particularly strong interest in risk management for two reasons:

  1. A project's risks offer the greatest opportunity for creating additional value (or for ensuring that a product realizes the value in its business case).
  2. Risk management is a discipline that can start small and grow incrementally.

Taken together, these two reasons mean that the potential ROI of improving risk management is high. Some basic attitudes and one particular simple practice can create enough momentum to establish effective risk management throughout an organization.

The Plan, and the Anti-Plan

“Plan the work and work the plan”. This is just one more popular saying that, taken literally, could not be more foolish. Why? Because there is a flip-side to the plan that requires at least as much attention as the plan: I like to call it the anti-plan.

No one can afford to ignore the anti-plan!

The anti-plan is all the problems that threaten the success of a product—problems like unproven technology, ignorance of the market, and divisive behavior. The anti-plan is shifty. Crises evaporate; trivialities expand into real threats. The anti-plan sometimes features problems of little value, and at other times obscures issues that can kill a product. Figure 1 illustrates the idea:

The literature refers to the forces in the anti-plan as “risks”, and calls our efforts to control them “risk management”. There is a well-developed theory of risk management; however, I've come away with two important practical lessons from managing risks.

The Lessons

First, the anti-plan is a rich source of work. One book on risk management says "If a project has no risks, don't do it." [1]. What the authors are saying is that the uncertainty in a project makes it an attractive investment to begin with. Products with little risk in their development tend to have a lot of competition and yield little profit.

And once you've decided to invest in a project, the place to look for opportunities to create greater value is in the project's risks. The anti-plan is such a rich source of opportunity that executives should make it their main focus and leave the plan to project managers and team members.

Second, one need not implement all of the risk management theory to have effective risk management. Instead, there are some key attitudes and one simple practice that plant the seed for successful risk management and encourage it to spread throughout an organization. Risk management can be an integral part of management from day one: there's no need to establish a separate risk management process.

It's a bit of a leap for many executives to stop cheerleading the plan and begin asking about the anti-plan; however, based on the performances of successful NPD executives that I've worked with, I'm convinced that doing just that is essential to succeeding as an NPD leader.

Basic Theory

There are five steps to effective risk management, at least according to theory. They are:

  1. analyze the sources of risks
  2. identify risks
  3. carefully evaluate risks
  4. remove valuable risks
  5. learn from removing each risk

There is more information on each of these steps in an appendix below.

However, the theory of risk management presents some management challenges, such as:

  1. executives and managers must be as interested in hearing about risks in the anti-plan as are they are in cheerleading the plan. How can we establish an interest in risks on a management team?
  2. people must communicate openly about their concerns. How can managers make people not just comfortable but aggressive about articulating problems?
  3. everyone on a product initiative must contribute to managing risks. How can a management team weave this new way of thinking into everyones' activities?
  4. the volume of work and paper that risk management produces can equal or exceed the volume for managing the plan. How can we keep additional work to a minimum?
  5. implementing all the risk management theory in one step sounds like implementing TQM--an all or nothing proposition. Is there a way to implement risk management incrementally?
  6. people who are only vaguely associated with a project, for example those involved in partnerships or market scanning, must articulate risks that affect the project. Their input is critical for finding risks caused by a lack of awareness. How do outsiders get involved?

Fortunately, risk management can grow incrementally, and there are some lightweight practices that not only establish a foothold but persist even on large projects. One product team that I was fortunate to work on exemplified effective, evolving risk management, and I'll use it to illustrate how one effective executive addressed the issues above.

From Theory to Practical Risk Management: A Case Study

The project was a 350-person 2-1/2 year project to deliver an innovative high-volume color printer for Xerox. We delivered the printer and the rest of the whole product on schedule and with superb quality. The printer and its follow-on product generated billions of dollars in revenue for the company, and soundly beat our competitors who were also attempting to produce production-speed color printers.

I've thought about this project a lot, and reflected on what made it so successful. Of course, there are many reasons, but of all our management practices, our risk management really stood out. At the core of our approach was a constructive attitude about process and problems, and we built on that core with a single, simple practice that encouraged people to focus on the anti-plan.

The Constructive Attitude

Here we were at Xerox, a citadel of process and a recent winner of the Baldrige National Quality Award, and the executive team asked me to define my process for getting my job done. This was in a company with one of the most thoroughly documented product delivery processes in history, the vaunted Xerox PDP, yet they wanted me to describe how I would do my particular job. They understood the need for situational process.

This executive team didn't prescribe, they inspected. They asked me to create two things and then thoroughly reviewed them:

  1. a simple flow chart showing the major steps in my work process through launch. This had to fit on one page.
  2. a list of the people outside of the project whose cooperation I needed to succeed.

All the managers created these charts, and it was the foundation for effective risk management, among other things, on the project. The executive team put the burden of proof on us to show that we knew how to do our jobs (item number 1).

This is certainly not unusual, but right away they were also looking for risks, in this case risks due to lack of coordination and commitment (item number 2). And, to follow through, from day one they responded with solutions to the risks I identified. For the rest of the project I knew that if I exposed a risk I'd get help, and that if I either overlooked or, much worse, hid a risk they would at best ignore me. The executive team anted up the first time I reported to them, and continued their constructive approach throughout the project.

The Simple Practice

To reinforce their interest in risks, the executive team ended every review with one question: "what are your top problems?" My answer to this question outlined the top three to five tasks I intended to focus on during the following month: some of them already in the plan, some of them risks. The reviewers then carefully assessed my response, judging the value of each task and discussing whether there were other, more worthy tasks.That's it--it's a simple but very effective practice.

At first glance, this practice probably seems insignificant; however, it had these effects:

  1. it invited me to ask for help.
  2. it gave me a chance to demonstrate leadership.
  3. it gave the executive team a chance to add to the list.
  4. it revealed what I was focused on, which was often very different from the plan.
  5. it aligned the the executive team and me on the most important work to do next.

Of course, once I got the hang of this I began asking my own group the same question, thus this practice naturally spread throughout the project. There were no separate risk management meetings, risk brainstorming, special presentations, risk management training, or any other activities specific to risk management. Identifying and evaluating risks became a built-in part of our jobs because of the executive team's attitude and the top problems discipline.

We all became so good at identifying risks that the V.P. running the project created a good news award just so he could hear about something that was going well once in a while. How ironic that such a great project would be so conscious of its problems, until you consider that the value in new product development is in coping with the anti-plan, not mechanically executing the plan. Our V.P. understood that.

Of course, we also tabulated our risks and tracked them at each review, but all of that was routine and mechanical. What was different about this project with respect to risk management was our regular and energetic exercise: "what are your top problems?"

Responding to the Risk Management Challenges

I listed six management challenges above regarding implementing risk management. In the case study, the combination of a constructive management attitude and the top challenges exercise addresses five of the six issues. The sixth, getting input from people who are only remotely involved, was handled by a standard procedure in the Xerox PDP: peer review by people outside the project.

Lessons from the Case

So, what can we learn from the successful risk management on this particular project? Here are some ideas:

  1. Executives can kick-start good risk management by asking people to identify risks related to cooperation and commitment.These are the risk areas that executives can do the most about, and when they ante up with solutions they send a strong message: "tell us about your risks and we'll help mitigate them."
  2. Risks to a plan are interesting, but risks to a process are much more interesting. First align on a sound process and then look for risks to the process, not to the plan. That is one more perspective that can help find the most elusive risks in the anti-plan, those in the team's blind spot.
  3. Effective risk management is a forward-looking discipline, so make looking ahead at risks the last part of project reviews, periodic meetings, and group problem solving sessions to align everyone on the work ahead. What happens in the reviews is less important than knowing what is at the top of the project members' minds' when the review is finished.
  4. Use peer reviews, partners, consultants, and other outsiders to find awareness risks. Focus domain experts on expertise risks and managers on coordination and commitment risks.
  5. Reward people who find valuable risks.

I've used the top problems discipline in every organization I've managed since. It is a very powerful practice, and one of its best features is that it is very hard for someone to finesse it. Consider how you would answer your boss's question "what are your top problems" if you just wanted to evade the question:

  1. You could say you don't have any top problems, which would signal that you are clueless.
  2. You could mention some really lame problems, which would make you look, well, lame.
  3. You could make up some very serious-sounding problem, in which case your boss will jump right in and help you!
  4. You could mention someone else's problem, which would give your boss a reason to follow up with that other person to talk about you--probably not a good idea.
  5. etc.

There really isn't a good answer to "what are your top problems?" except for the truth. Now, compare that to your options when your boss asks "are you on schedule?" Why, of course you are, and you're 90% done, right?

The top problems discipline encourages people to think clearly, declare themselves, and ask their employees to do the same. It is an effective practice for both structured reviews and informal hallway conversations.

The Bottom Line

A new product development executive who takes the investor's perspective must focus on risks--that's where the value is. Invest in a process the project managers can customize, ask for a plan for each project to set a baseline, and then focus on risks from day one of each project. Leave the plan to the project manager; focus executive attention on the anti-plan.

And, a very simple and effective way to focus on the anti-plan is to ask the question

what are your top problems?

 

Appendix: A Theory of Risk Management

To elevate awareness of the anti-plan and mitigate risks, an executive team must make sure that its organization is:

  1. analyzing the sources of risks
  2. identifying risks
  3. carefully evaluating risks
  4. removing valuable risks
  5. learning
Sources of Risks

Where do risks originate? Primarily in two places: technology, including development capability, and the market [2]. Technical risks are those we think of most naturally. Will the product work? Can we learn fast enough to build it? Will a new standard emerge and render our design obsolete?

Market risks are equally important. Are we meeting the customers' requirements? Have we identified the whole product? Is a new technology about to replace ours?

Regardless of where a risk originates, what causes it is ignorance or inaction. Technology and the market are the raw materials of the anti-plan. Ignorance and inaction bring it to life. After all, if we knew everything and acted on what we knew there would be no uncertainty.

Not wanting to imply that anyone else might be ignorant or unable to act on all of his or her risks I'll speak only for myself, but I've experienced risks arising from four causes, i.e. a lack of:

  • Awareness. Also known as blind spots.
  • Expertise. I was aware of these risks, but initially lacked the expertise to remove them.
  • Coordination. I knew of these risks and could remove them, but hadn't because doing so required some cooperation that I hadn't yet created.
  • Commitment. I was capable of removing these risks with no more than routine action but hadn't yet allocated the resources to do it.

Combining origin with cause yields eight types of risks that inhabit the anti-plan. To illustrate the eight types of risks, the table below lists eight well-known companies, technologies, or products each of which was particularly vulnerable to one type of risk.

 

Technology

Market

Awareness

SmallTalk, of Java

Iridium, of consumer tastes

Expertise

Go Corporation, handwriting recognition

Xerox Star, perceptions of innovation

Coordination

Challenger space shuttle, assessment of o-ring failure

AOL/Time Warner, media and content

Commitment

DEC, to personal computers

CP/M, to mainstream partners

Table 1: Famous Companies, Technologies, and Products that Suffered from Particular Risks

Note that a risk can be either an outcome that you would like to avoid or the absence of an event that you are counting on. Assumptions about favorable outcomes are a rich source of risks--the "Market" column in Table 1 provides some good illustrations.

For example, Xerox was counting on people recognizing the innovations in the Star workstation, one of the projects I worked on.  We knew that Star was a bit slow, and also limited to running only Xerox applications, and that it might at first seem expensive, but still it really did offer a revolutionary leap in office productivity, and we were sure people would see that. But I met people who were making Fortune 500 IT purchase decisions who just couldn't see that the Star embodied many of the major innovations in the computer industry of the following 20 years! The value of the product's innovations just didn't register at all. Oh, and they thought the mouse was odd, too. Ouch!

The products and companies in the table above are (or were) superb, yet they suffered from serious, costly risks. How can a company identify such important risks?

Identifying Risks

Probably the most common practice for identifying risks, after just using intuition, is brainstorming. You can add some structure to brainstorming by focusing on the schedule, the process, key success factors, or lessons learned from past projects [3].

This targeted brainstorming is a good approach to finding risks that a project team can conceive of. A problem is that a project team cannot identify risks caused by a lack of awareness--those risks are in the team's blind spot.

An approach that augments structured brainstorming and does a better job of probing for awareness risks is to focus on a specific type of risk and use practices suited to finding risks of that type. Table 2 lists some candidate practices to use in addition to brainstorming. Identifying risks is part of many common management practices:

 

Technology

Market

Awareness

Tracking standards, technology partnering, technology scanning, inspection.

Strategic partnering, reviewing research reports, prototype selling.

Expertise

Benchmarking, prototyping.

QFD, Kano analysis, customer testing.

Coordination

Walkthroughs, peer review.

Launch walkthroughs, market testing.

Commitment

Technology and product roadmapping.

Industry structure analysis.

Table 2: Exercises that Reveal Risks

Note that many of these practices introduce something quantitative (QFD, market testing), something demonstrable (prototyping, prototype selling), or an outside perspective (partnering, benchmarking). All of these outcomes help in evaluating risks.

So, I don't think that brainstorming or even structured brainstorming is sufficient for identifying the important risks for a product. To achieve good risk management an executive team must build risk management into many of its ongoing practices, both within projects and at the executive level.

Evaluating Risks

Most of the risks in an anti-plan are not worth investigating. A risk has value just like any other investment, and merits investigation only if the benefit of mitigating it is adequate compensation for the cost and uncertainty of allocating resources to it. Like an investment, mitigating a risk should produce an economic profit.

Two variables determine if a risk is worth mitigating: the likelihood of its occurrence, and the impact if it does occur [3].  Figure 2 illustrates the common idea of a risk value threshold:

In figure 1, each star represents a risk with a particular impact and likelihood of occurrence. For a risk to be worthy of investigation, its expected value, i.e. the product of impact and likelihood, must exceed some threshold, represented by the curve. In this case, the risks represented by red stars are worth investigating. They are valuable risks. Yellow stars represent risks that barely warrant attention, and green stars represent risks that have too low an expected value to merit attention.

At least, that's the theory.

More practically, our estimates of likelihood and impact are very likely to be wrong, but making those estimates is a valuable exercise anyway. Just attempting to estimate risk value creates valuable side effects: finding potential process improvements, improving partner and supplier relationships, clarifying roles and responsibilities, scanning the market, finding ways to simplify and speed up projects, etc. Perhaps the most important side effect is to establish some common metrics for evaluating benefit, cost, and risk so that, at the least, one can explain decisions more clearly.

Off particular importance is to thoroughly think through the value of mitigating a risk. Some elements of value that people often overlook are:

  1. Options. Mitigating a risk may create new opportunities.
  2. Learning. In addition to removing uncertainty, investigating a risk may add new skills, reveal a need for partnerships, etc.
  3. Resource concentration. Ruling out a path can help a team focus its effort.

Often there is more value to removing a risk than it seems at first glance, and much of the value can be in positive side effects.

Removing Valuable Risks

How can an executive know if his or her organization is removing valuable risks? The best indication is if the list of risks being investigated changes week-to-week, and that it has important risks on it.

In my experience, even on the largest projects, only the most obstinate risks remain on a hot list for more than a few weeks. In other words, if the list isn't changing, the project is stuck.

Knowing if the list is changing or not implies that there is a list. A simple action that encourages people to manage the anti-plan is to request a periodic summary of the top problems from every product initiative. Steve McConnell suggests a practical risk assessment table that would serve nicely as a project top problems report and a roll-up at the executive level [4].

And, speaking of roll-ups to the executives, one thing executives should insist on when a project mitigates a risk is effective learning.

Learning

There's a natural tendency to mitigate a risk and then move on. What a mistake! Just like at the end of a phase or project, the end of a risk investigation is an opportunity to learn, and in particular to identify:

  1. other risks in the anti-plan that the previous risk masked.
  2.  process improvements that could help prevent similar risks in the future.
  3.  tools, information sources, people, etc. that would make investigating similar risks easier.

Even a five-minute retrospective that covers the above three points is worthwhile. The additional cost of summarizing the retrospective as a part of each top problem report is very low, and it enables senior managers to spot common threads that can help them evaluate process improvement initiatives during portfolio reviews.

References

1. T. DeMarco and T. Lister, Waltzing with Bears, Dorset House, New York, 2003.
2.
P.G. Smith and D. G. Reinertsen, Developing Products in Half the Time 2nd Edition,  John Wiley & Sons, New York, 1998.
3. P.G. Smith and G. M. Merritt,
Proactive Risk Management, Productivity Press,
New York, 2002.
4.
S. McConnell, Rapid Development, Microsoft Press, Redmond, 1996.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright 2003, Peter Bradshaw. All rights reserved.