RIGHT Blogs                                                              

Monitoring Your Program Health (Risks)

Tracking risks on a program / project is something of a challenge because risks evolve as your project evolves.  The beautiful risk profile that you put together detailing all the risks that you identified at the project kickoff is unlikely to look like the risk sheet that you put together in the middle of a project.   So tracking risks on a project and making sure that you are always ahead of the latest ones takes a lot of work.  It's very easy to get comfortable with your first take on a risk sheet and just keep updating the risks you initially identified, instead of constantly looking for new ones.   And that's when you are most likely to get bitten.

I've enclosed a sample risk tracking sheet below as an idea of the elements you should be tracking.  The columns are what I've found useful to track based on past experience, but you can adjust them based on your program or preferences.

Risk Id: This one's pretty obvious.  But basically you want a way to uniquely identify your risks and be able to refer to them quickly.  It makes risk review meetings go much faster.

Active: I've been part of programs where they've wanted us to move all the closed risks to a different tab or spreadsheet, but personally I like having them all on one sheet where they can be easily seen and re-activated if necessary, or just filtered out if you just want to focus on the active ones.

Opened & Risk: These are pretty self-explanatory, the date the risk was opened and the description of the risk.  The description should be detailed enough that someone picking up the sheet can easily understand the issue.

Likelihood: This is your best guess at how likely the risk is to occur.  From Remote to Very Likely.  Some people like to use % Probability instead of words, it's up to you on which conveys the most information.

Impact: This is your best guess at how badly your project / program will be derailed if the risk does come to pass.  That can range from a low impact to a significant one.  Again, you can use numbers to represent the impact instead of words.  A benefit to using numbers is that you can then use a calculation of (Likelihood x Impact) to calculate the exposure due to the risk.  But you can usually figure that out pretty easily by just looking at the individual components.

Target Close Date: This is your best guess at when this won't be a risk anymore.  Unless you've found a way to completely eliminate the risk, it will usually be at some time when that particular risk will no longer impact the project.  For instance, a risk of a subject matter expert not being available to help define the requirements, will no longer be a risk when you've got a signed off BRD.  There are other risks that pop up at that time, but this one will be closed.

Mitigation Approach: This is where you can document your plan to close out or reduce the risk to the point where it will only have a minor impact on the program.  Once you've identified the risk, this is the most important task you have, and usually some creativity is required because you are working with fixed resources and a fixed timeline.