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.
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:
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.
Risk Management and Project Objectives
Risk Identification and Capture
Risk Mitigation Strategy (part 1)
Objects Impacted and Modular Architecture
Calculating Risk Exposure and Free Risk Exposure Spreadsheet
Risk Mitigation strategy (part 2)