Risk Mapping

Ray Kroc: “If you’re not a risk taker, you should get the hell out of business.”

Contributed by Scott Elliott, TechZecs LLC.

http://techzecs.com/

What’s New?

Product development is inherently a big set of risks. The main purpose of a product development project is to reduce the uncertainty of the product’s success and any associated risks to a manageable level. Most product development teams do not adequately assess the risk factors in their programs to begin with, nor do they adequately track and manage those risks through the development process.

A fresh and graphical approach to risk assessment and management is to use a mind-mapping tool as illustrated in the figure below:

Figure 63a: A generic risk mind map for product development

This kind of diagram is easy to create using one of the many mind-mapping tools available and can be used to brainstorm the risks within the team and to collaborate on managing those risks throughout the product development process. Teams are also discovering how useful this tool is for project retrospectives.

What Is the Tool? Risk Mind Map

A set of tools that works very well for brainstorming and developing the set of risks is mind-mapping software. There are robust, commercial packages such as MindManager from Mindjet and many open-source packages such as FreeMind and XMind. There is a helpful list on Wikipedia here:

http://en.wikipedia.org/wiki/List_of_mind_mapping_software

These packages make it easy to start from a central node or idea and then add branches around the node to fill out related ideas, causes, effects, etc. Of course you can do this by hand on a whiteboard or on paper, but the software reformats the chart on the fly and makes room for more branches. You can also edit, move, and order branches at will, as shown in Figure 63a using XMind.

Here is a proven method for using this tool:

1. Brainstorm

The process starts with the team brainstorming risks in the product development project. The first step is to list the major categories such as product definition, technology, competition, commercialization, support, reliability, etc. as shown in figure 63b.

61_risk2
61_risk2

Figure 63b: Major risk factors

Next, add branches to the major categories in order to identify all of the foreseeable risk elements for your specific project. Cut off any branches that have a very low probability, such as “lab hit by meteor”. An example is shown in figure 63c.

61_risk3
61_risk3

Figure 63c: Typical project technical risks

A typical project risk mind map will identify 30 to 50 such possible risks on the full map.

2. Impact and probability

Of the 30-50 risks in the outer branches, the team should then identify which are the most likely and have the highest impact.

You can use symbols or markers provided by the mind-mapping tool to highlight these risks as shown in figure 63d. In this case, we have used numbered balls to indicate the probability and an exclamation point to indicate the impact on project success.

61_risk4
61_risk4

Figure 63d: Prioritized technical risks

3. Validation of high-impact/likely risks outside of meeting

After building out and prioritizing the branches of the risk map, it is time to make assignments to validate the risks and propose mitigations. Each high-priority or high-impact risk should be studied by a team member, subgroup, or third party. For example, financial risks might be assessed by someone in the finance department.

After these risks are studied and evaluated, you can add the results and mitigation plans to the risk map as shown in figure 63e.

61_risk5
61_risk5

Figure 63e: High-priority risks and mitigation plans

Each mitigation plan should include a responsible person and a due date or checkpoint date, as shown in the figure.

The project manager owns this risk management process. The risk map and the Gantt schedule are the two most important graphical tools of his/her job. A best practice is to have a real or virtual “war room” where this map is posted prominently, usually on the company wiki or internal collaboration software. For software development, a similar map could be used as a “bug list”.

As risks are mitigated or eliminated, they should be edited and re-prioritized on the risk map as well as other project tools like the Gantt chart. New risks can (and will) appear and should be added. The risk map should be communicated to all stakeholders regularly. A “snapshot” of the risk map should be made at least weekly.

At the end of the project, these snapshots of the risk map should be used to do a retrospective. How well were the risks anticipated and mitigated? What did we learn, and what can we build into the product development process to make it smoother and faster for the next project?

What Are the Benefits of this Graphical Technique?

The risk map provides an efficient method to view the whole spectrum of risks at a glance. We can see which of those risks are the most probable and/or have the highest impact on project success. The risks can be pared and mitigated as the project progresses. At the end of the project, sequential snapshots of the risk map clearly show the trajectory of risks as they are eliminated or mitigated.

In some cases, a risk that grows in importance and transpires might even kill or drastically change the project. The earlier this risk and event can be foreseen, the better to minimize the investment and change course.

Which Business Problems Do We Solve?

Often risks that are not considered or taken seriously have the biggest impact on project budget as money is thrown at the problem in order to get to market on time. The risk map allows the management team to anticipate risks sooner and prepare mitigation plans. It keeps the risks and their trajectories visible to the team throughout the project, allowing the project manager to move resources where needed to eliminate those obstacles.

If the risk map snapshots are used in a disciplined fashion for retrospectives, the ability of the company to develop better products faster in the future will improve its success rate.

What Are some Considerations?

A careful and credible risk analysis needs time and an open and honest team. Often the highest-risk parts of the project are not immediately evident until some structured thinking and brainstorming are done, as illustrated by the case study below. The risk analysis also may show that the highest-risk parts of the project are not always the most fun and interesting parts.

Case Study

The author once managed a project to develop an optical modulator that would imprint a modulation frequency of zero to 40 GHz (then unheard of) on a laser beam in a fiber for high-speed optical communications. The team was assembled, and a risk mind map was developed as reproduced in figure 63f.

The brightest PhD engineers had been hired to develop this state-of-the-art product. For them, the challenge and fun were in designing the electrode pattern and the optical waveguiding pattern as shown in the upper right of figure 63f. Although these things had never been done, the engineers were virtually 100% confident they could do it successfully in the allotted one-year time because they had made similar designs in other labs and were confident in their computer models. They couldn’t wait to see their names on the groundbreaking technical papers.

However, when we did the risk analysis, it became clear that the greatest risks (#1 and #2 in the figure) were in the much less glamorous area of getting optical fibers to align and stick to the ends of the chip and stay there permanently. The project leader decided boldly to put 80% of the team on this aspect of the project, much to the initial disappointment of the gurus. They were allowed to spend most of their time on the modulator design only after they had demonstrated 90% confidence that the fiber alignment and attachment process would work - a subproject that took nine months! In just three more months, they had a fully functional, manufacturable, and reliable product ready for the market! Had the team not done this thorough risk analysis and mitigation effort, the project would have taken much longer.

61_risk1
61_risk1