What is the Project Management Risk Process?

What is the project management risk process?  The project management Risk Assessment Framework is a flexible, easily scaled, and tailored framework aligned with the Project Management Institute's PMBOK® Guide. 

The benefit of the framework is that it is easy enough for an aspiring, new, and accidental project manager to understand yet comprehensive enough that even seasoned project managers will have unique insights into the risk management process.  More details about it are in my book, Risk Assessment Framework: Successfully Navigating Uncertainty, and I will outline the processes here. As you will see, the framework is both iterative and recursive. 

The framework has two major components - Risk Assessment and Risk Control.  Risk Assessment is a collection of processes to be performed during project planning and repeated as necessary during project execution, monitoring, and control. Risk Control starts in parallel with project execution and finishes at the end of the project. 

Here is a brief description of each process in the framework: 

Risk Planning: Risk planning aims to develop a risk management plan.  This document documents organizational attitudes toward risk; what processes will be followed; the supporting decisions, tools, and techniques; and how escalated and unknown risks will be handled.  Some risks may already be known at this point, and a risk register is created to start documenting them. 

Risk Identification: Here, the risks are identified.  The focus is solely on identification so that nothing important is missed.  Categories and prompt lists help guide brainstorming efforts and assure completeness. 

Risk Analysis: Analysis may be qualitative or quantitative.  The goal is to determine the probability that the risk may occur and the impact if it does.  This information can be used to determine a risk priority and provide information for the budget and schedule costs and time that may be needed to cover risks. 

Risk Response Planning:  Starting with the highest priority risks, many of which should be avoided, the responses to risks when they occur are planned. Some will warrant a complete change of plans, while others may just be accepted and dealt with in the unlikely event they happen.  Therefore, it is critical to identify the highest-priority risks.  Then, since avoidance and other responses may change the project somehow, it is necessary to return to identification to see if any additional risks are now exposed. 

Risk Monitoring:  Once project execution begins, there needs to be a regular review, usually weekly.  Usually, this means watching the top 5-10 highest-priority risks that might occur during this week. Spotting a risk trigger that has happened means the response plan may need to be enacted. A more thorough review may occur once every 6-12 months (the time frame should be scaled to the project length), starting with a study to see if any new risks are identified. 

Risk Response Implementation: Once a risk trigger has been identified as imminent or has already happened, the risk responses may need to be enacted.  These, too, may change the course of the project, so a return to identification is critical. Monitoring needs to continue as well. 

If you have been skipping over risk management, you may want to rethink it.  A small project can work through the first five steps within 4-8 hours.  However, missing risks can be fatal to your project and organization - a McKinsey study found that 17% of IT projects go so poorly that they threaten the company’s existence. 

Have any further questions?  Please ask in the comments below.