By Greg Githens, PMP, NPDP

Catalyst Management Consulting

All good NPD program teams have a collaborative process for risk identification, analysis, and response. Figuratively, they have radar that looks out over the horizon watching for incoming threats. Once alerted to the threat, the organization can initiate effective countermeasures. Here is an example of how one individual, by asking a few simple questions, was able to create an awareness of risk that turned a possible disaster into an excellent result.

Wendy Chou was Project Lead for the Firebird project for Spectrum Corporation, a global information technology company (all names are disguised). Firebird was a software application development project that was integral to the technical and commercial performance of Spectrum’s product strategy.

Early one week, Wendy excused herself from a training class to attend a meeting with her functional manager, Elise MacDonald. Elise was a brilliant (sometimes egotistical) engineer, and often stubborn about her point of view. Elise wanted to explore adding a new set of features, which would offer the opportunity to attain proof of concept for another emerging technology.

As the week progressed, Elise’s interest in the Firebird project increased. Wendy became concerned that the new features and technology would cause a complete rethinking of the product architecture, but she kept her thoughts to herself. Elise determined it was time for a preliminary technical review meeting with the team. As the issues unfolded it became clear to all that the project was undergoing a major rethinking. Still, Elise confidently pushed forward with "Let’s do it."

Murphy’s Law had struck. Wendy got an awful feeling in the pit of her stomach. If she defied Elise, she would raise an unpleasant conflict. If she acquiesced, she would be assuring a difficult time-pressured scramble that would require heroic effort. Wendy looked at her team members, saw their trepidation, and knew she would have to summon the courage to confront the dilemma.

Remembering a technique that she had just learned; Wendy stood and walked over to a nearby flip chart. "OK, assuming this new product architecture is our direction, let’s jot down a few risks that we must accept or manage." Quickly her team members chimed in: "It will take more specialized resources, users will need added training, it creates a dependency on the work product of overseas units, there might be other unidentified stakeholders, and a delay opens a window for competitors."

Listening as Wendy and her team brainstormed risks, Elise’s eyes opened and she exclaimed, "Maybe we need to reconsider." She even added a few risk events of her own. Quickly everyone remembered that the project had started off with a deadline and a "just do it" attitude. It had no sound plan, just a list of dates, deliverables, and optimism.

Soon, the group realized that they lacked good market and customer data. They invited their marketing representative’s participation. He validated some of the risks, but also helped clarify the demands of the market (and opportunities). While the risk identification stimulated a lot of additional work for the team, they agreed that it led to one of the most successful project introductions in Spectrum’s history.

The Firebird project offers many lessons to other NPD projects. Wendy should be congratulated for taking the initiative by asking some simple and basic questions that stimulated risk identification. She was inclusive of her technical team, her director, and the marketing organization.

Firebird is not an atypical NPD project. First, unstable product concepts are a core reason for NPD project frustrations – often products are launched simply and then increase in complexity and scope, as the product becomes a remedy for all revenue growth and profitability needs. Second, many stakeholders are not initially considered, and their eventual outspokenness sparks many problems. Good projects perform an early stakeholder analysis. Third, organizational culture to "be positive, can do" often leads to poor decisions. Finally, "smart" people are often the most vulnerable to hubris (the Greek word for exaggerated pride or overconfidence). A common NPD situation is where individuals attribute any potential problems to others and not to themselves. But when every individual points their fingers at other parts of the organization, critical NPD risks are ignored or dismissed. People generally make choices that are logical for their own mental model. Many can identify the trivial details, but have huge blindspots that can lead to disaster.

Successful entrepreneurs and executives know that taking calculated risks is important to their success. No organization can make progress without taking risks, and the biggest dangers result from errors of omission, rather than errors of commission. An example error of omission is "not having the right people on the NPD team" whereas an error of commission is allowing a design review meeting to turn into a problem-solving meeting.

As the side article describes, Murphy’s Law was first noted millennia ago. Those teams who can anticipate risks are more agile and likely to succeed. Risk events occur early in the project, but risk consequences occur later.

The focus of this chapter is describing a team-based risk management approach. Exhibit 1 summarizes the 10 steps. The NPD program is like a tightrope walking team. If one person loses their balance, the entire team may tumble into failure. Each funambulist (Latin for rope walker) and each NPD team member needs to understand how their contributions fit into the balance, how to use the tools of their trade, and execute their roles according to their plan.

>>Insert Exhibit 1 - 10 step team-based process for risk management. <<

Because NPD performance success is based in cross-functional contributions, it is essential to perform risk identification collaboratively, not as individuals. The program manager needs to put people in a room for a day or more and help them through the process of identification, quantification, and response planning. While you’ll hear "I don’t have the time," remember that one risk event can easily cause weeks of schedule delay and overrun.

There are two essential things that the facilitator and the leader must do before the meeting.

• Do your homework – Typically there is considerable documentation and background that can easily suggest the source of opportunities and threats. From past project learnings there should be body of knowledge of common mistakes and problems, which typically include unstable or changing requirements, resource flux, unclear roles and responsibilities, and problems with interfaces. Before delving too deeply in a formal risk identification session, make sure the basics of NPD strategy and project planning are present.

• Communicate the purpose- Get the right people, allocate enough time, and make clear the purpose of the session. If people are new to actively identifying and managing risks, plan for at least a day. Leaders have to help individuals overcome their reluctance to raise NPD concerns that stem from their fear of being labeled as "not being a team player" or "not being positive."

Common language is fundamental to good communication, and two important terms for early understanding are risk and issues. Here are their definitions.

A risk event is a discrete occurrence and is describable as a cause and its associated risk consequence. There is a probability that the risk event will occur. (A practical criterion for recognizing a risk is: "maybe it will happen, or maybe it won’t.") If that risk event occurs, then there will be a consequence of that risk. All three elements (event, probability, and consequence) are necessary for a "concern" to be a risk.

Issues are certainties and are evaluated and managed differently than risks. If something has a 100% probability of occurrence it is not a risk, it is a certainty. So, if you’re sure it is going to happen, or if it has already happened, it is an issue and you want to deal with it proactively.

I always try to use familiar layperson-type examples before I get into more complex business and technical examples. Here’s a good example of a risk assessment: It is a start of the day and it is partly cloudy. You check the weather forecast and see there is a 50% chance of thunderstorms today. The risk event is a thunderstorm, you have an estimate of probability, and the consequence is that you get wet. Being prudent you decide to take an umbrella with you in case the risk event is realized. Your project plan has an identified contingency plan – the umbrella.

Now, let’s assume that you look out the window and see it raining heavily. The fact that it is raining is no longer a risk, but a certainty. It is an issue and you better actively manage your response. You can try to deny the issue, but you will only get wet. Failing to manage your program issues is just plain stupid! (And I can’t help but editorialize about the frequency which people in any kind of project deny the rain and go out hoping to dodge the raindrops in a downpour.)

Here is a technique that I have found helpful for orienting the team to terms: Draw a figure like the one on Exhibit 2 on a flip chart page. Use it to explain how the team needs to identify general concerns (which are sources of anxiety but are not often actionable) and subsequently resolve them into lists of risks and issues. You should illustrate with some commonplace examples like flat tires, computer crashes, or lost luggage.

As the team gets "level set" on terms, they will find it easy to thing about the NPD risks specific to the project at hand. You might try this question as a risk identification icebreaker to create a thoughtful state of mind, "What makes NPD projects fail or perform poorly?" Make sure that everyone understands and is focusing on those risks and issues linked to team success and failure.

>>Insert Exhibit 2 – Decomposing Concerns into Risks and Issues<<

In retrospect, it’s easy to recognize Murphy’s Law - "anything that can go wrong will go wrong". Prospectively, we NPD professionals need to anticipate the threats to success.

The goal in risk identification is simple: generate a list of risk events and a list of issues. Exhibit 3 presents a list of proven risk identification techniques. Some of these techniques are common and some are not, but all of them have a benefit of stimulating a different frame of reference that identifies individual and team blindspots. I also list a few advantages and disadvantages. (Note that there are common disadvantages to each of the techniques that include they take time to learn, time to perform, and create psychological discomfort that may result in interpersonal conflict.)

>>Insert Exhibit 3 - Table of Identification Techniques.<<

A cause and effect structure is helpful in understanding what is a risk. Of course, in the real world there are multiple causes and multiple effects. One difficulty for novices is the linking of causes to effect – where the effect becomes a cause of another effect. Diagramming techniques can be helpful for modeling the chain of cause and effect. A common question is: Which cause or effect do I focus on? The answer is to find the point where an individual has influence on the risk event’s occurrence. Use that event as your input to the quantification and assessment process.

Many people often see the difference between risks and issues as an unimportant fine point. Jeff Tucker, a Program Manager with Wavetek Wandel Goltermann, a manufacturer of test equipment for the communications industry supports this: "At first, NPD team members don’t see the relevance of separating risks from issues. No matter how many examples you give them to define risks and issues (e.g., a flat tire is a risk, and driving on a near-empty gas tank is an issue), people will still struggle with distinguishing between risks and issues." However, those program managers and teams who have clarified the differences find that the distinction is very helpful to them in managing their projects. Risk events are "discrete" and meet the criterion of: "maybe it will happen, maybe it won’t." Issues are statements, sometimes vague, of concerns that "have happened" or are "certain to happen."

Generally, early in the project you will find more issues than risks. However, as the team’s understanding gets better refined, they can better identify specific risk events. By getting the risks out in the open, the team can use more specialized risk quantification and response strategies.

Step 4- Classify

You now have a list of risks and a list of issues. The classification process helps the team to understand what they know, what they don’t know, so they can determine an action plan. One excellent technique for classifying risk is the RADIO technique described by Ken Ports of Intersil at the 1999 PDMA-IIR conference on Project Management for New Product Development. RADIO is an acronym for Risks, Assumptions, Dependencies, Issues, and Opportunities. The NPD team manages each of these categories differently.

Another useful classification strategy is labeling concerns as "strategic" or "operational". Strategic concerns are those that affect project selection or the ability of the project to meet the business objectives, such as profitability or customer satisfaction (one good way is to evaluate risk events is to test them against the customer value proposition). Operational concerns are those that affect delivery time and development expenses.

Avoid classifying risks by functional area (e.g., engineering risks, manufacturing risks, marketing risks because this practice perpetuates finger pointing and blaming others.

You often see a classic mistake occur during the classification of NPD risks. This is the inherent weakness of hubris: an unwarranted pride that people have in themselves and their work. The side article titled "Arrogance and Overconfidence" explores the fascinating topic of fallibility.

Step 5 – Analyzing Risk

The NPD team needs to estimate values for risk elements in order to calculate the riskiness of the concern. The assessment process helps to deepen understanding in the NPD team about which risks require more attention.

IBM has made project risk management techniques an important part of its NPD process. Says Nancy Whetstone of IBM in Rochester, Minnesota, "I tell teams to first establish your risk review cycle, (e.g., quarterly, monthly, at each development phase)". This helps to gain agreement on the visibility and benefits of risk management.

Next, Nancy advises, "The team needs to clarify what High, Medium, and Low mean for probability and impact. For example, the team may determine that High Probability means 80% or higher chance the risk event will occur." She also advises examining time, expenses, and targets in the impact analysis.

Exhibit 4 is a table for assessing NPD program operational risks (operational risks are those that affect development time and expenses) in four impact areas. It is important for the team to anchor impact ratings to their own business environment and scale them specific to each project (e.g., a 2-week delay may be unnoticed in some companies or projects and disastrous in others).

>>Insert Exhibit 4<<

Radical innovations need larger risk tolerances while incremental innovations typically have smaller tolerances. For example, a radical innovation might tolerate a 50% slip in schedule or budget whereas an incremental innovation would consider a 10% slip as high impact. Incremental products have less uncertainty, and thus more predictability.

Assessing the risk impact helps the project team to evaluate critical success factors. A classical example of a low probability and high impact risk was Intel’s experience with its Pentium processor. Intel’s engineers estimated that an average spreadsheet user would only encounter it once every 30,000 years, thus there was a low probability of the risk event's occurrence. The impact in terms of product performance was not significant, but the perception of a problem caused a massive recall and public relations problem for Intel.

Exhibit 5 lists several NPD project risk quantification techniques that the project team can use to understand the probability and impact at a deeper level. The analytical process develops a detailed understanding that assures good risk response planning.

>>Insert Exhibit 5<<

Consider using an external person to walk through the project risks. The team retains the responsibility for project performance, but gets an unbiased external perspective.

It is important to make an overall assessment of each risk event. This is done by multiplying the probability value by impact value to yield an expected value. For example a high probability, times a low impact results in a medium overall risk event. Exhibit 6 illustrates a risk map, showing six risk events arranged by probability and impact for overall risk. There is one "high" risk, four "medium" risks, and two "low" risks.

>>Insert Exhibit 6<<

NCR has an excellent approach to understanding opportunities and threats, called the Risk & Opportunity Assessment Model (ROAM) to evaluate new business opportunities. ROAM gauges a project team’s perception of the risk at the beginning of a project. The analyst examines elements of threats/hazards (such as low customer commitment, schedule urgency, requirements stability, the delivering organization’s capability, and technology maturity) and elements of opportunity (such as alignment with strategic direction, revenues/profitability, growth potential, new markets and technology, resource utilization, fit with needs, and value added). Then, the analyst plots the project’s ROAM score on a chart like that shown in Exhibit 7. (Please note that the underlying calculations are proprietary to NCR and cannot be shared in this chapter.)

>>Insert Exhibit 7<<

Terry Murphy, NCR’s Risk Manager is a veteran of hundreds of project risk assessments. He notes, "The shortfall with this or any tool that quantifies risk is that people "game" the numbers; they manipulate the input values to the outcome they want." If a sales person wants to secure a new account, they have a natural incentive to discount the threats and highlight the potential gains. The value in the analytical tool is in surfacing assumptions and recognizing biases.

A final and important point is to beware analysis paralysis! It is common for people to get lost in details and quibble over small, subjective numbers. I keep a plastic overhead foil ready labeled "the purpose of analysis is insight for improvement" whenever I see that the team has become bogged in trivia.

A typical NPD project can easily have hundreds of risks and issues, which is more than they can or should try to manage. The next step is for the team to prioritize the classified risks and issues, in addition to those prioritizing the risks and issues that fall primarily into their own functional area. There are a number of techniques available for prioritization: weighting is probably the most-common technique.

In prioritizing, always keep stakeholder risk tolerances in mind, as discussed in the side article.

As a frequent flyer, I know that most commercial airlines insert schedule buffers so that flights usually arrive on time. I have experienced occasions when the plane departs the gate 30 minutes later than posted and still arrives at the scheduled time. In addition to schedule buffering, pilots use response options (like flying faster) that allow them to meet their arrival times. Airlines manage customer expectations by setting conservative, buffered schedules, and then empower their pilots (who are analogous to a NPD program manager) with resources and authority to develop and apply responses.

Before delving into the practice of risk response planning, I want to discuss the too-common approach of "passive acceptance" of risks, which is defined as accepting the consequences of a risk by ignoring it or practicing wishful thinking. Bruce Horwitz, Director of Optical Technologies with Axsun Technologies is referring to passive acceptance when he says, "People tend to do the easy stuff on their projects first, and then they sweep problems under the rug. A good leader will focus first on the tough things." When NPD teams "sweep problems under the rug," they have passively accepted the risk event. Individuals are reluctant to ask challenging questions of themselves, because it will expose their lack of knowledge, raise the specter of conflict, and it will probably lead to more work for already-overwhelmed individuals. Generally, passive acceptance of risks is a culturally-mediated practice that permits psychological denial, workarounds, teams to stay in their comfort zone (which is often functionally siloed), weak self-responsibility, and weak NPD program managers. The effective program manager leads and encourages participation in initiating and sustaining the effort to manage program risks.

Risk response planning (Step 7) is the process of developing strategies for reducing threats to the intended project and product outcomes. The team takes their prioritized risk list and begins response planning for the top-ranked risk. There are four generic risk strategies that the NPD team should consider (see Exhibit 8), as revealed in the following series of questions:

• Risk avoidance - How could we avoid this risk event? Are the hazards associated with the risk event so significant as to justify canceling the project?
• Risk mitigation - How could we reduce the probability of the risk event happening? How could we reduce the impact (to the project’s success criteria) of the risk event?
• Risk transference - Could another organization better handle the risk? How could we contract out the risky work or the risk event?
• Risk acceptance - If we have to accept the risk, what contingency strategies are available to us?

>>Insert Exhibit 8_<<

>>Insert Side Article "Risk Response Experience"<<

Instruct the team to work through each risk and apply each response, even if the response does not initially seem feasible. The side article, "Risk Response Experience at NCR" by Terry Murphy of NCR provides examples of how he has applied the risk response strategies to his programs.

You will consistently find the NPD team will adopt the proactive strategies of avoidance, mitigation, or transfer. If they determine to accept the risk, they will have contingency plans for it. Ideally, the team should assess each and every listed risk, but in practice, they select a cut off level and address the risks above the cut off level.

Doing risk management well has a foundation in Step 2, "Level Setting on Terms." Recall that a risk is a discrete event with a probability and an impact, whereas issues are concerns that have already happened or are certain to occur. If the team did not do a good job of distinguishing and understanding the difference between risks and issues, they will get frustrated. Because an issue is a certainty, the NPD team is concerned not with whether it will happen, but how to resolve the issue to closure. Jeff Tucker comments, "As the teams work through the analysis, the risk-issue partitioning helps the teams see that they collectively own the responsibility for the success of the project. The risks and issues are theirs, and they can’t rely on wishful thinking." He goes on to add, "The process of listing risks and issues helps the program manager build an effective project plan that has buy in." Often, the team can resolve issues simply by documenting a work package and adding it to their work breakdown structure and schedule.

Management of project issues is straightforward. The team starts with the top-ranked issue and further clarifies it. They next determine an individual owner and establish closure criteria for the issue. The program manager can keep NPD team meetings productive by encouraging the off-line resolution of issues and then using the team meeting to confirm that the issue is now closed or needs to remain open.

Good NPD program managers make commitments to their management to achieve certain results for scope, time, and cost. The program team has to make some decisions such as: What are the stakeholder’s priorities? How much buffer should they allocate to each project element (time, scope, and cost)? How do we allocate ownership for the risks? Program managers are just like pilots who file their flight plan before starting, and they take into account risk events that might compromise their objectives for schedule, passenger comfort, budget, and safety. If the weather is severe, they may apply the response strategy of avoidance and cancel the flight, as both the pilot and passengers (their stakeholders) have zero tolerance for accidents. (In the language of risk, a weather-related accident is a low probability, high-impact event.)

Recall that stakeholder risk tolerances (part of Step 6, Prioritize) is the concept that any stakeholder (internal or external to the program) has certain comfort levels. Competent program managers explicitly consider stakeholder risk tolerances and include it in their baseline project plans. For example, some stakeholders can tolerate reduced product performance, but cannot tolerate delays. The plan identifies and quantifies the amount of buffer (also called a management reserve) available for use by the program manager. Baselining assures ownership of risks, and accountability for results. Of course, the authority of the program manager’s authority to manage risk varies with the organization, as described in the side article, "Risk Management Characterizes Organizational Maturity".

>> Insert Side Article "Risk Management Characterizes Organizational Maturity"<<

Finally, I note that contracts are risk allocation mechanisms. Therefore, all good program managers must have some practical knowledge of the different types of contracts used in projects, so they can understand the relationships between price, risk, and scope. The clarity of requirements is the starting point: more vagueness equals more risk. Firms set prices to cover the expected monetary value of the risks, as well as to cover costs and meet market demand. John Goodpasture, formerly a VP with Lanier Worldwide Inc., writes that there is an equation for strategic project risk, which I interpret this way: Resources Investment + Project Risk = Desired Results. The job of the program manager is to take invested resources to deliver a result, taking measured risks to do so. The contract formalizes the allocation of risk to the project and to the business.

In the execution of the project, the Program Manager is the person making sure that the team is following its own processes. The team should have a prioritized list of risks and issues, a plan for how they will manage the risk (if it occurs), and the resolution of the issues. Exhibit 9 provides a nice self-assessment instrument for assuring that the team remains aware of its responsibilities for managing program and project risks.

>>Insert Exhibit 9 – Self-Assessment<<

While "flying your project" you should note these two learnings from pilots. The first lesson is "situational awareness:" The pilot must know the location, altitude, and heading of the plane at all times. (Recall the American Airlines flight that crashed into a mountain in Columbia several years ago – the pilots were disoriented). The second lesson is "target fixation:" a phenomenon where military pilots occasionally crash their planes into an object because they are so narrowly focused on the target (I’ve seen similar experiences in NPD projects when people get overly focused on due dates, burn themselves out, and make foolish compromises on quality.)

One more principle: in the middle of an international financial crisis, I heard a bank executive who had prepared his organization well declare, "the first rule of risk management is don’t panic!"

Risk offers excellent opportunity for creating meaningful organizational learning. In the post-implementation review, the team members should consider these questions to stimulate reflection:

• Did we implement risk responses as planned? Why or why not? Were they effective? What can we learn?
• Instead of finger pointing and blaming at individuals or groups, what is going on in the larger system?

My favorite Sunday comic strip is Bill Watterson’s Calvin and Hobbes, the escapades of a six-year-old boy (Calvin) and his philosopher-stuffed-tiger (Hobbes). I have liked best Calvin’s soliloquies as they race down a steep hill in a wagon. I cannot help but consider the wagon as a metaphor for NPD program management and I imagine Calvin as the program manager and Hobbes speaking for the program team. My favorite is one where, as they are start down the hill in the wagon, Calvin states, "It’s true Hobbes, ignorance is bliss." Shortly before going over a cliff, Calvin states, "If you're willfully stupid…. you can keep doing whatever you want," and then covers his eyes. Calvin and Hobbes end up wrecked and bruised, and team-member Hobbes moans, "I’m not sure I can stand so much bliss." Calvin responds "Careful, we don’t want to learn anything from this." Good program managers are not like Calvin; they keep their eyes open, anticipate the hazards, and learn from their mistakes.

You now have a seen a simple ten-step approach for building a team-based approach for NPD program risk management. In nearly every step, I described the underpinnings of individual psychology and organizational culture. Do not think of risk as a nice-to-do "tool" but rather as Zen-like discipline of consciousness building.

Risk management does not need to be complicated. Kelly Benjamin, NPD PM Manager at Essilor of America confirms the value of simplicity, "We have a rather rigorous risk method that we use worldwide. Because each project is different, we leave it to the project manager and team to match the intensity of risk identification effort to the product strategy. Simpler projects get a more streamlined response."

Kelly’s comment emphasizes the importance of judgement and flexibility in matching technique to strategy. Just start with some simple inquiries: "How do you define project completion? How do you define success? What will keep you awake at night?" Because each project is different, its risks are different and the response must be flexible and robust. A sound risk management approach is scalable to the innovativeness of the marketing, technology, and production strategy. Too, the program manager should scale the amount of risk management process to the ability of the team to assimilate and use the process. Hence, the use of standard checklists and templates can focus the NPD team’s attention on the wrong areas and lead to a false sense of security.

Team ownership of the project’s risks is essential. I recently heard an executive complaining that the NPD team would not step up and make decisions – no matter how much he encouraged them. It was one of his biggest frustrations. Risk management is one of the very best ways to cause people to confront the difficult issues in the NPD project and structure information so that people can make good team decisions. Communicating, team building, and decision making are processes, not events.

NPD organizations tend to make the same mistakes repeatedly. A project risk radar can help avoid repeating past mistakes so the team can focus on innovating.

Kent Harmon of Texas Instruments notes that organizational culture sometimes conditions individuals to be distrustful. This distrust undermines good decisions. The fear that "I might be judged for something outside of my control" often leads to avoiding participating in risk, or deflecting the concerns to other team members. To build this support in individuals and teams, Kent and his staff listen actively to the concerns, engage people, and coach senior management on accepting the risk data.

When I get on an airplane, I expect that the pilot has assessed all risks and developed appropriate responses for her flight plan. I expect the crew to keep their "heads up" and not get absorbed in their technology. NPD organizations should expect similar standards of professionalism from their program managers. Risk management is arguably the single greatest competency of NPD program management.

I have repeatedly seen a no-longer surprising side effect of proactively managing project risk: people get more creative. They take the lemons and make lemonade. Risk is not always bad: risk is a choice, not an outcome. Did you know that the Chinese character for risk (see Exhibit 10) is a blending of the characters for danger and opportunity that literally translates to "take risks"? NPD program managers must thoughtfully manage risk and be willing to assume accountability for the performance of the project. A good decision is one that increases the probability of success and decreases the probability of failure.

>>Insert Exhibit 10<<

• Try this question as a risk identification icebreaker, "What makes projects fail or perform poorly?"
• Julius Caesar once said "Quod malum posset futurum," which turns out to be Murphy’s Law roughly translated

• Competent program managers explicitly consider stakeholder risk tolerances and include it in their baseline project plans.
• "I expect the crew to keep their "heads up" and not get absorbed in their technology."
• I have repeatedly seen a no-longer surprising side effect of proactively managing project risk: people get more creative.
• "The first rule of risk management is don’t panic!"

Exhibit 2: Decompose Concerns into Risks and Issues for Subsequent Response Planning

Avoid – Changing the project plan to eliminate the specific risk events or conditions. By avoiding the risk, the project team removes a source of poor product or project performance. Avoidance can also include project cancellation. However, by practicing avoidance the organization may miss opportunity.

Mitigate - Reduce the probability or impact to an acceptable threshold. Strengthening a product’s reliability (e.g., reducing mean time between failures) is an example of reducing the probability, and robust design (building in redundant or backup systems) is an example of reducing the impact.

Accept – Active acceptance is to develop a contingency plan. Passive acceptance leaves the project team to deal with risks as they occur.

Transfer – Moving the responsibility for the risk to another party. NPD examples include joint ventures, subcontracting, and purchasing insurance and warranties. Transfer is often the most "out-of-the-box" concept for many NPD teams, who have traditionally thought of the work of NPD as one of technical and market development.

>>Side Article<<

According to The Official Explanations, (1980, Paul Dickson, New York: Delacorte Press), Samuel Beckett’s 1938 novel named Murphy, first contains the phrase, "If anything can go wrong it will." Still, many give credit to a WWII veteran, Captain Ed Murphy for popularizing the phrase. You might be interested to know that the basic ideas are deeply embedded in the folklore of many cultures, and Julius Caesar once said "Quod malum posset futurum," which turns out to be Murphy’s Law roughly translated.

A tightrope walker knows the difference between respect for a hazard and arrogance; between preparation and foolish risks. The decision maker considers probabilities and impacts before committing to action when taking a calculated risk. The decision maker takes a foolish risk by plunging into action without considering the negative consequences.

The story of arrogance and vanity leading to a downfall is as old as civilization. I agree wholeheartedly with what Scott Adams writes in The Dilbert Principle, "People are idiots. Including me. Everyone is an idiot, not just the people with low SAT scores. The only difference is that we’re idiots about different things at different times. No matter how smart you are, you spend much of your day being an idiot." An attitude of humility improves decisions.

A sense of humor is the pearl in the oyster of humility. It helps risk identification, sparks creativity, and relieves tension.

Neither executive exhortation nor the team’s hard work will cause an unrealistic goal to happen. Pressure-for-results causes all kinds of people to make mistakes. Watch out for the excesses of wishful thinking, bottom line fixation, and macho images.

Accept for the moment the possibility that the NPD program has unrealistic expectations. Ask that the project team validate all characteristics of the target (time, product performance, and expenses). As senior managers learn to be better project sponsors, they probe deeper for the enablers of good project results. Ask the team to perform a risk analysis!

Be aware that people often panic when given due dates. They will tend to ignore the organization’s process.

There are quantitative risk assessment techniques (supported by software tools) available that can help in generating data. Be patient if your organization wants to use these quantitative techniques. It takes time to assemble quality data inputs, and to learn to use the tools.

It is essential to determine stakeholder risk tolerances as part of the prioritization process. It is vital for the project team to understand stakeholder risk tolerances. As a decision reaching process, the project team discusses the results and establishes a "cut off level" to determine which risks to accept and which to avoid. Stakeholders must accept some risks as inherent, otherwise if these occur they will cause changes to the program. IBM’s Nancy Whetstone advises teams to establish this cut off level early.

Jerry Groen of Abbott Laboratories says, "To evaluate the level of risk and the project's returns, we capture the opinions of experts from all parts of the organization on the probability of success of a project: the project team, in management, and even outside the organization. The program manager acts as the facilitator."

Jerry adds, "We then summarize the data. We request that the participants provide a rationale for their estimate so that executives can understand the underlying rationale." We think that the original numbers have value in understanding the range of plausible outcomes. The stakeholders can then consider their personal risk tolerances. We don't try to get the outliers to congregate to the middle numbers."

Says Jerry, "The intent of the process is project selection (go/no go decision). Project evaluators continued to use it to advise management of the riskiness of a project early during project selection so that they can make a determination whether to continue. We also use it in project reviews."

While it might seem logical to determine stakeholder risk tolerances before quantification and prioritization, I find teams usually wait and develop the analysis, and then discuss the data with stakeholders. In looking at the range of potential outcomes under various scenarios, the stakeholders look directly at the relevant data and make an intuitive decision on what that can and can not accept. Here are some good questions for assessing the individual or organizational risk tolerances:

• What is the magnitude of the upsides and the downsides? When do the risks occur?

• Can we reverse or recover losses? How much control do we have?

Avoidance: While working with a customer to fully define a new application development project, I noticed that the customer planned to develop the new application on its current legacy platform and then migrate it to its new platform at a later date. The risks from a development standpoint were obvious and significant. Rather then accepting the risk I went to the customer, explained the risks, and offered a good business case for them to purchase a developmental platform for the new application, thus avoiding the risks completely.

Mitigation: While developing a new systems solution for a customer we could find no way of realistically predicting whether end users would find value in the proposed solution, and use it. To mitigate the risks, I recommended a controlled implementation that called for turning up a few end users on a prototype system then using the data gathered to finalize the solution.

Acceptance: The implementation phase of a project’s schedule was very aggressive and the business case for that aggressive schedule was compelling. I developed a contingency plan that included a 16% risk pool for the discretion of the Project Manager, a list of pre-validated third party vendors that could be used as needed, and an aggressive schedule risk review plan.

Transfer: On a project, we needed a technology that was not within our core business. We were concerned about its performance. We elected to transfer the risk by identifying a niche vendor with the appropriate expertise and develop a highly-structured third-party teaming agreement.

Some firms have more capability to manage risk well, and research shows that these firms are the most consistent in their growth and profitability. Firms with more sophisticated program management, will "book" a project plan, pay attention to the details of product scope and project scope, use risk management tools like computer simulations, principle-based negotiations, and document their plans and assumptions. These more-mature firms are the ones that will consider risk in establishing project baselines and contracts.

Less mature firms typically establish a due date and pay attention to little else (and in my experience, this is the majority of firms). Firms that use the decision rule "Hit the launch date" default to passive acceptance: hiding the risk instead of managing it. Firefighting and crisis management characterize their organizational culture, and their strategic performance is inconsistent.