chart of risk management process

Manage risk like a pro

As a project manager, one of your biggest challenges is staying on top of the myriad of outside threats that can sidetrack your project.   Issues turn into risks that then become realities and can result in slowing down or even tanking your project completely in some cases.   Often during interviews, project management candidates are asked what they personally do to manage risk in their projects.   Understanding how to build comprehensive risk management into your projects is crucial to staying ahead of those risks, especially is higher-complexity, longer duration projects.   And having a crisp understanding of risk management process can be key in helping you land those higher-caliber PM positions.

Performing risk management formally often entails building and maintaining a centralized document (sometimes called a “Risk Register”) that lists and tracks all the potential risks that can impact your project.   Understanding and documenting all of the known risks during the planning phase of your project can help you head off potential challenges as the project team begins to execute.   Start by building a table (using a spreadsheet of some type) that includes a list of the risks in rows, and the following columns alongside each risk:

  • Severity – What is the overall scope of the impact (example: # of users impacted), High/Medium/Low.
  • Probability – How likely is it that this will come to pass, High/Medium/Low.
  • Impact – If this occurs, what will its effects be on adjacent projects and/or services?
  • Risk Trigger – What specific item would need to occur for this risk to become reality?
  • Risk Owner/Risk Response – who owns watching for the risk trigger and responding?
  • Cost – What is the cost of each risk, as measured by the triple constraint (scope, schedule, and budget)?
  • Threat Rating – The overall rating of each threat, which the risk list should be sorted by.
  • Mitigation – What can be done to prevent this risk from becoming a reality?

Building your threat rating

When managing high-complexity projects where the schedule can last beyond 6 months, the list of risks can become quite lengthy at times, so being able to focus on the highest priority threats is crucial.   Building a risk index (or Threat Rating) can be done by multiplying (Severity x Probability).   This can be done by assigning both Severity and Probability with rating levels (High/Medium/Low) and then assigning numerical values to each (High=3, Medium=2, Low=1). For specific risks with both a high probability and a high severity, then this risk would be assigned at Threat Rating of 9, which would be the highest and sit at the top of the list.   In some cases, you may decide that severity is slightly more important than probability, and so the values for severity can be adjusted higher to provide more heavy weighting to environments that are especially user-sensitive for example.   Utilizing this simple tool helps you quantify and then justify the time and effort required to continually revisit and review key risks to the project with your project team and stakeholders.

Use or it or lose it

Often, more junior PMs may build a risk management plan, save it to the project document repository, and then proceed to forget about it. Then, when one of the documented risks threatens to sideline the project, members of the team can be surprised when they are forced to respond to something they hadn’t discussed for several months. Instead, it is highly recommended that this document be reviewed during regular project team meetings with any necessary updates made to the specific columns that may result in changes to the overall Threat Rating or response plan.   Also, including status updates in your regular project reporting on the top threats can really help build confidence in the overall health of the project amongst stakeholders, so they are never caught off-guard if and when risks become reality.

Perception is reality

Often times, the difference between a “good” project and a “great” project comes down to stakeholder perception.   This can be especially painful to the PM if the project is delivered successfully on time and under budget – but specific stakeholders felt the project was too “noisy”.   If stakeholders feel like a project has had a lot of bumps in the road that weren’t expected throughout its lifecycle, they can provide critical feedback that can result in less than perfect results.   Having a highly visible, comprehensive risk management plan can certainly go a long way towards controlling stakeholder perception.

Being able to manage risk naturally as part of the project life cycle is often a key factor that separates the professionals from the rookies.   Taking the time now to research and build your own risk management strategy can give you a significant edge in moving into a more senior PM role and in achieving better overall results as you manage and deliver your next project.