Product development is a risky activity. Managers often ask us how they can learn to better anticipate risks and how they can prepare to face these challenges as they occur.
Mindmapping is a fresh approach to risk assessment and management. Mind maps record a creative process. They are used for creative problem-solving, requirements generation, and product idea generation, but teams can also use them to brainstorm potential risks.
Benefits of Risk Mind Maps
Portrays the whole spectrum of risks at a glance
Assesses which of those risks are the most probable and/or have the most impact on the project
Allows teams to track risks and update the risk assessment as the project progresses
To create a mind map write the central concern in the middle of the diagram. Draw related factors as bubbles connected to the central concern.
Using the graphic below as a template, create a diagram with the major categories of risk – packaging, supplier, technology, reliability, etc. – already filled in.
This sample Risk Mind Map is drawn from a real optical development program.
The bubble in the center is the main theme.
The outer boxes are various classes of risks
List next to the boxes indicate specific risks, prioritized from 1 (high) to 4 (low).
Risks without numbers are the lowest priority
Which Business Problems Does the Tool Solve?
Most product development teams do not adequately assess the risk factors in their programs, nor do they adequately track and manage those risks throughout the development process.
The Risk Mind Map enables a team to create a comprehensive risk profile. It allows management to anticipate where risks might arise and to prepare to meet these challenges more effectively.
What Else You Should Know
Mindmapping software is available, making it easy to start from a central node or idea and then add branches around the node. Mindmapping software also allows distributed teams to collaborate more easily.
The quality of the Risk Mind Map is highly dependent on people. Ensure that the most experienced team members participate. If the team lacks depth, supplement it with principal engineers or architects from other teams.
Finally, careful and credible risk analysis needs time, and open, honest team communication. Often, the highest-risk parts of the project are not immediately evident.
At the end of the project, the team should use these snapshots of the Risk Mind Map to do a retrospective. How well did they anticipate and mitigate the risks? What did they learn, and what can they build into the product development process to make it smoother and faster for the next project?