Project Risk Management identifies, evaluates, responds to, and monitors uncertainty that could affect project objectives, timing, cost, quality, or adoption.
Definition
Project Risk Management is the disciplined handling of uncertain events or conditions that could help or harm project objectives. In improvement work, it addresses technical risks, data risks, resource risks, stakeholder risks, implementation risks, financial risks, and sustainment risks.
The goal is not to eliminate all uncertainty. The goal is to make risk visible early enough to choose prevention, contingency, transfer, acceptance, or escalation.
History
Formal project risk management grew from engineering, construction, defense, and project management practice. Lean Six Sigma teams use it because improvement projects often cross functions and fail more from execution and adoption risks than from tool selection.
When to Use
Use Project Risk Management when projects have tight timelines, major process changes, uncertain data, cross-functional dependencies, regulatory exposure, customer impact, or high financial expectations. It is also useful before Kaizen events and pilots.
Step-by-Step
- Define project objectives and risk categories.
- Identify risks through team review, lessons learned, gemba observation, and stakeholder input.
- Score probability, impact, detectability, urgency, or exposure.
- Prioritize high-exposure risks.
- Choose responses: avoid, reduce, transfer, accept, or prepare contingency.
- Assign owners, triggers, due dates, and escalation rules.
- Review risks during project governance meetings.
- Capture lessons learned for future projects.
Examples
- Data risk: Measurement-system error could invalidate baseline results.
- Implementation risk: A new layout may interrupt production during peak demand.
- Adoption risk: Supervisors may revert to old scheduling rules after the project closes.
Common Pitfalls
- Creating a risk list without owners.
- Only reviewing risk at project launch.
- Ignoring people and adoption risks.
- Using vague mitigation actions.
- No contingency triggers.
- Confusing issues that already happened with risks that may happen.