Update & Share tips on Testing, Develoment, Design & Other New Tech Trends

Post Top Ad

Post Top Ad

Friday, January 12, 2018

January 12, 2018

How To Make A Powerful Risk Management Template

The template is formatted nicely for you in the link at the end of this post. I also want to state, nice and early, that this template is adopted from a MSF document. It has proven itself a nice risk management template for me in a variety of software situations and does not tend to overwhelm anyone. Even clients who lack technical knowledge tend to get it and appreciate it.

These are the column names and description of what information goes in the columns. The .xls contains all this information and looks nicer. I cannot present a table well within WordPress. Sorry about that. Go ahead and use it. Say nice things about me if you like it.

Make a powerful risk management template

Risk Management Fields:

  • Risk ID: This is a simple numeric identifier for the risk. We have to keep track of each risk, independently.
  • Description: Summarize the risk. What is the issue at hand, who and what are the players involved, what is the concern? Be as high-level as you can be. No need to get bogged down in details here. Document what is immediately relevant and make sure that the Risk Owner has full understanding. This document should provide an overview for stakeholders but not overwhelm them with detail or technical information.
  • Impact: If this risk becomes a reality, how big of a deal will it be? Obviously, this is subject to a degree of context. Some teams may feel that not building RSS feeds into their System is a horrible misfortune, because their SEM campaign depends upon it. Other organizations will not be overly concerned with RSS feeds, since all their content is reserved for members. Use 1-3 for “not a huge problem”, 4-7 for “considerable problem”, 8-10 for “major problem”, and 100 for “showstopper”
  • Probability: How likely is it that this risk will manifest as reality? This may be tough to determine, but look at Historical Information, talk to your experts, and nail down your best estimate. This will be a percentage: 1% to 100%. If it is 100%, immediately consider the risk triggered and look to the contingency plan.
  • Exposure: Impact times Probability = Exposure. You need to do a little math here, sorry. This will represent how “exposed” your project is to the risk. Do you have a gaping hole in your armor, or are you pretty well insulated against tragedy? At minimum, this lets you see what the biggest risks are. Leveraged a bit more, it can show you what risks are truly worth immediate consideration and action.
  • Contingency Plan: What are you going to do when this risk becomes a reality? This is your backup plan, and it doesn’t hurt to have more than one. It does, however, make sense to have a primary contingency plan because you are going to have to take definitive action when the time comes, and you don’t want to have a bunch of meetings to determine the next steps. Congingency plans should be as unrisky as possible. It makes no sense to lay out a contingency plan like “Fly to Mars and find the secret element that will save us.” Write up a primary backup plan, and note others if you have identified them. Do not, however, spend too much time coming up with alternates. You want one safe Contingency Plan.
  • Trigger: What will tell you when this is no longer a risk and is now a reality? Usually, the trigger will be an event or a set of conditions. When the trigger event occurs or the trigger conditions manifest, you immediately move to your primary Contingency Plan. There should be no wishy-washy triggers. A trigger is a trigger, and when it is triggered, you take action. Just like a gun. When you pull the trigger, you can’t debate the bullet. I mention this because when it comes to HR or other sensitive issues, people may waver.
  • Risk Owner: Who is responsible for keeping tabs on this risk? Usually I recommend that the PM is the Risk Owner, but it may make sense for someone on the development team (like the Dev Lead) to be the Risk Owner. They may have intimate knowledge of the System that the PM does not have . I have seen the Risk Owner be the PMO, in which case they better not be too busy.
  • Mitigation: What are you going to do to make sure that the risk does not get triggered? Essentially: how are you going to control the risk? This will come from conversation with your stakeholders. I recommend having a Risk Assessment meeting and bringing key stakeholders together. Add the mitigation field as you go, but call it what you want.”Mitigation” is a very formal term.
  • Adjusted Impact: With your Mitigation and Contigency plan, what is the projected impact of this risk?
  • Adjusted Probablility: With your Mitigation and Contingency plan, what are the chances that this will still happen? Again, this is meant to measure the value of your Contingency and Trigger.
  • Adjusted Exposure: With your Mitigation and Contingency plan, what would the Exposure be? This is meant to make sure that your Contingency Plan is an effective one.
We hope this is useful for someone. It has been adopted from Microsoft’s Solutions Framework, streamlined and changed a bit. I find this more universally applicable.