Risk Management Process

Risk management has four steps. It is cyclical, and each risk, issue, question, and opportunity is put through the process as quickly as possible. Risk management is the essence of product development. Doing it well will improve your success rate immensely.

Identify
a. Briefly describe the risk
b. Give it a short name
c. Assign it an owner
Analyze
a. Determine/Document the risk drivers
b. Evaluate impact, probability, and exposure
c. Establish value rating (High/Medium/Low)
d. (Sometimes) merge with or supersede another risk
e. (On rare occasions) determine it is invalid
Plan
a. Evaluate mitigation options and determine which mitigations to implement
b. Establish a detailed mitigation plan, integrated with the overall project plan
c. Establish burn-down milestones (Milestones after which we re-evaluate the status and rating of the risk.)
d. (Sometimes) decide not to mitigate the risk, because the mitigation cost is too high compared to the value
Implement

While, at times, it may seem like the process is applied to all risks simultaneously, a key aspect of truly Lean product development is debatching. Debatching of risks allows quicker mitigation.

Our risk management process has many things in common with what some call Knowledge Based Product Development or Learning First Product Development. It also has a lot in common with LAMDA, PDCA, and the good ‘ole Scientific Method. The 5-Why’s are in here, too.

As a reminder from previous posts, the definition of a project risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” As such, we can apply this risk management process to:

Traditional Risks: Where some condition may or may not occur and result in negative impacts on the project objectives.
Issues: Where the condition is quite certain.
Knowledge Gaps: (Questions): Where we are pretty sure we need to learn something specific in order to meet the project objectives.
Opportunities: Where we might be able to create some conditions which have a positive effect on the project objectives.

Issues, knowledge gaps, and even opportunities are commonly associated with LAMDA and PDCA processes, which themselves are variations of the Scientific Method. If you are familiar with these processes, you will likely see some similarities. We are simply pooling these variations with traditional risks in our processes.

Throughout the remainder of this post and in future posts, we generalize and call each risk, issue, question, and opportunity a “risk.” We also generalize and use the word “mitigation” when we refer to the actions and steps taken deliberately to achieve the goal of reducing risk, eliminating an issue, answering a question, or realizing an opportunity.

Finally, before I leave the definition of project risk and move on to the process, I’ll simplify it in one more way. That is, I don't distinguish between an "event" or "condition" that causes the risk. Events cause conditions, and it’s the conditions which ultimately have an impact. But sometimes conditions cause events which cause other conditions.

Rather than distinguish between events and conditions, I prefer to think in terms of symptoms and root causes. If we drill down enough to find whatever event or condition resides at the root and address that, we’ll be doing the right thing.

Stay tuned for our next post on how to effectively navigate risks in hardware development projects!

Interested in taking risk management a step further? Download your free risk management template.