When my high school buddies realized they had a half an hour or so to spare, one would spontaneously announce, “Let’s play a quick game of Risk.” The not-so-inside joke was that, if you are playing the traditional game of Risk, there is no quick game. Our poker nights usually turned into an overnight game of Risk, with the table set up and maintained for the next poker night, when the game would continue.

For your project, you created the risk register, which you will visit frequently throughout your project. As with the game of Risk, project risk management is not a quick game, nor a one-and-done consideration. It is regularly reviewed, cultivated, and refined to meet the needs of the project.

What’s In A Risk Register

What is the Risk Register? It is the document where you listed the initially identified risks and opportunities for your project. You also identified the initial probabilities and severities of each. Hence, your baseline exists, but you need to take it to the next level. There are many versions of Risk Register templates available online; you can pick one that suits you, or your Project Management Office (PMO) can provide one.

Attributes of a Risk Register

Your risk register should include the following attributes for each risk:

  • Trigger – Identifies what causes this risk to convert from “might happen” to “is happening” (in other words, it is no longer a risk, but is now an issue). Trigger events could be objective – a critical vendor delivery is not provided by the committed delivery date – or subjective – actual resource availability is falling short of planned allocations. Triggers can change over time; they may not be static.
  • Strategy – The preferred approach – either company, PMO, or sponsor-directed – to handling this risk. There are usually four ways to handle a risk:
    • Accept – There is nothing you can do about this risk if it happens; you deal with it.
    • Avoid – Your project team or the company does everything in its control to not have this happen.
    • Mitigate – The project team takes preventive measures to not have this risk happen or takes steps to reduce its impact if it does.
    • Transfer – Moves responsibility for handling this risk to another party. Normally, this strategy relates to liability or insurance issues.
  • Owner – the person responsible for addressing the risk, either working to prevent its occurrence or addressing the issue when the risk is triggered.
  • Planned Action(s) – how the issue will be addressed should the risk get triggered. The planned action could be a brief, one sentence description or a fully-detailed plan.
  • Actual Action(s) / Resolution – if the risk is triggered, how it was actually addressed.
  • Trigger Date – the date the risk was triggered. You want to record this so you can monitor project performance to see how it was impacted by the risk.
  • Resolution Date – if the risk was triggered, the date the issue was resolved.

Managing Your Risk Register Informally

Managing your Risk Register requires keen perception of the environment around you. Not just the project environment, but the corporate and maybe societal environment as well. Your eyes and ears are open to new risks and opportunities; they can arise out of nowhere in any setting:

  • In a hallway conversation
  • At a status meeting
  • While watching TV at home
  • Talking with a friend about a hobby

Sounds crazy, right? Inspiration hits at some strange times, and one conversation may trigger a thought about your project.

What do you do? Write down your thought. Always, every time. Might you realize later that it was not accurate? Possibly. But it is better to record it for future use.

There is the informal component of Risk Register management.

Formal Risk Register Management

The formal components of risk register management are:

  1. Add risks and opportunities as they are mentioned or discovered.
  2. Conduct regular risk register reviews with the project team:
    a. Assess newly added risks for probability and severity then assign priority and ownership.
    b. Review existing risks for changes in strategy, priority, probability, and severity. Close those risks that are no longer possible or have been triggered and resolved.

This activity can be a portion of a status call or its own meeting, depending how extensive your risk register is.

That Quick Game…Takeaways

You assembled your initial Risk Register and now understand how to manage it. You cannot really play Risk alone, and you should not undergo risk management alone; your project sponsor, advisory board, and PMO are there to help you assess, plan for, and address risks. As long as people and technology are involved, new risks will arise and old risks will be addressed.

Our next post will be all about the people and organizations that have an interest in your project, your stakeholders.

December 9, 2024

To tell or not to tell, that is the question. When you are making a major change in your organization, when do you tell them? In advance so they can prepare for it, or at the time of change, so that they don’t ask too many questions? The answer seems obvious, right? Tell them with

Read More
April 1, 2024

A vendor’s project manager will not manage client-side activities. Why is having someone who does manage them important for your project?

Read More
March 11, 2024

Were you the student who always crammed for your tests? Or were you the planner? How do you migitate risks that crammers bring to projects?

Read More

Elevate Your Software Project Management

Streamline and Organize Your Activities for Maximum Efficiency Today!

>