By Peter Symons, OARBIC (Part 1 of 2)
Dec. 1, 2005 – “Great Deeds are Usually Wrought at Great Risks.”
Last week, we decided that Herodotus probably wasn’t running an IT project and we looked at the differences between “Inherent Risk” and “Operational Risk.” We also discussed the good work that The Standish Group has done in recognizing and measuring Inherent Risk. This week we’ll look at recognizing and managing Operational Risk.
Conceptually, managing Operational Risk is a relatively straight forward process. It’s a circular process that recognizes the possibility and probability of risk, the actions to be taken if the risk occurs, or to prevent the risk from happening, and the continued monitoring to see if the risk has either materialized or changed.
The challenge with Risk Management is that every project could potentially be facing literally thousands of risks, which, simply because of volume, would be impossible to manage. The trick is listing and managing the ones that will hurt your project and, as importantly, letting go of the ones that won’t.
The first step is to list all the risks that could impact your project. PMBOC offers some advice of how to expose or recognize risk: Brainstorming sessions, Delphi Technique, Interviewing, Root Cause Identification and SWOT analysis amongst others. All these techniques will result in a list of potential risks and should include a description of the risk and an indication as to both the size of impact of the risk and the probability of it occurring.
Once you have made your initial pass at exposing all the potential risks, you will probably find you have exposed too many risks to manage properly. The next critical step is to select the ones for which you want to develop contingency plans.
One way of selecting the appropriate risks is to create a Risk Rating Template that considers both the impact of the risk and the probability of the risk occurring. Included in this process (with suitable input from all the key players), is the determination of where the project’s Risk Tolerance Line is on the template.
Once you have developed your template, add all the risks that were discovered in the first process. This will give you a crisp break between those risks that could hurt you and those risks that the project can probably weather if they occur. Your job now is to actively manage those risks that fall into the “Active Management” area and passively manage those risks that fall into the “Passive Management” area.
An example of a risk template is as follows:
That said, in practical terms, listing every risk on the template is still a significant job, there are however a couple of techniques that can quickly reduce the number of risk that even get to the template.
Assumptions: always view assumptions (as documented in the project charter) as risks. They are there for a reason and the reason is usually bad! For example, if an assumption is “All staff on this project will fully understand the XYZ System” That sort of comment is typically written as either the schedule is tight and there is little, if any, learning time available or the project is complex and requires a high degree of system understanding. Whatever the reason, it would be wise to log a risk “Not all project staff is experienced in the XYZ System” and have contingency time and training available if the risk materializes.
The “Uh-oh” factor: think about what your first reaction would be if your assistant PM were to race into your office to tell you something has gone wrong. If your initial inward response is calm and unconcerned, then the risk may not be worth tracking. On the other hand, if your inward response is “Uh-oh”, unless you have a very low tolerance for problems, you probably should consider this a risk.
Creeping risk: this one can be tricky. Don’t automatically dismiss a small risk as not worthy of being tracked if it can creep up to becoming a large risk. For example, if your architect takes 1 sick day, typically that’s not a problem, if your architect takes 100 sick days, typically that’s a problem. You have to decide where, between the 1 and the 100, does this turn from “not a problem” to “is a problem”?
Once you know what risks you should manage, you should log them in a risk register; there are dozens of examples of risk registers available on the internet that you can use as a starting point. Against each risk there should also be a risk mitigation plan. Risk mitigation plans, basically come in two forms:
-
What to do to prevent a risk from occurring (prevention).
-
What to do if the risk occurs (plan “B”).
An example of risk prevention would be the risk of poor quality code. It would be unwise to wait until the code is complete to see if this risk has occurred as just about the only mitigation plan you could use at that time would be “re-write code” followed closely by “apply for new job!” Your risk mitigation plan could include many things to ensure quality code; RUP type multi-iteration development, peer design reviews, code walk-throughs, continuous testing and so on. These are all risk mitigation techniques to prevent the risk from occurring.
The second type of risk mitigation, Plan “B”, occurs if a trigger point is reached. For example, if your project is the planning a large garden wedding (life isn’t always about IT you know), it would be a wise risk mitigation plan to have a large tent ready in case it rains. That way, if it does rain, (the trigger point) you can move to plan “B” and move all you guests quickly into the tent.
Finally, and arguably most importantly, risk management is not a one shot event to do at the start of a project where you dust your hands off and say “thank God that’s over”. You should, on a very frequent basis (weekly), review and monitor your risk plan, your mitigations strategies, your Plan “B”s and so on. Any time anything changes in your project, your risk management process should kick into action and see if the risks have changed or if your risk mitigations strategies have or should change.
Peter Symons
Managing Partner, OARBIC.
[email protected]
About OARBIC:
OARBIC Inc. is a specialized IT consulting firm helping the property and casualty insurance industry make older systems behave like new ones – and new ones behave the way they should.
We offer an array of consulting services, plus our OSEA software solution is specifically designed to extend the life of legacy applications to allow them to keep pace with change.
Our in-depth knowledge of the property and casualty insurance industry and our access to a global network of talented, specialized IT professionals, sets us apart from other consulting companies. More information at www.oarbic.com
