Risk Maintenance

Identifying risks to your project and devising effective strategies to eliminate or mitigate the threats and guarantee or take advantage of the opportunities is only half the battle in managing risks to your project. Your client or customer’s business does not stand still while you deliver the project so you should not expect project risks to be static. Risks will change over time as the project deliverables and milestones change. Even when a risk does not change, its importance to the project will change with time as the project gets closer to the deliverable or milestone at risk.

Successful risk management requires agility, that is, you must be prepared to respond to changes to the project environment. When a risk you were monitoring disappears because the probability of it happening are reduced to zero, the deliverable at risk has been produced, or the milestone at risk has been achieved, the risk must be obsoleted and your focus moved to more current risks. The execution of a project is a learning experience. As you learn more about upcoming work, deliverables, or milestones, you are likely to identify risks that were not evident before. You need to be able to identify those risks as soon as they become apparent and devise effective strategies to deal with them. The activities described in the rest of this article fall under the process of Monitoring & Control (in PMBOK® parlance). These activities will keep your project management style agile and protect your project from being blindsided by risks that could have been dealt with earlier on but weren’t. You may want investigate the possibility of receiving your PMP (Professional Project Manager) certification. There are many excellent PMP® courses and other PMP® exam preparation training products to help you with your certification.

The Risk Register

Your risk register is your project’s bible for risk information. All the information that you gather that is pertinent to project risks should be captured in this document and that information should be kept up to date as you move through the project work. The following is a list of information that you should track with a brief description of each item. Items that must be captured and tracked are bolded. Items that may be captured and tracked are not:

• Risk event description A description of the threat or opportunity that you are attempting to discourage or encourage.
• Risk probability The chance of the event happening, expressed as a number (e.g. from 0 to 10) or ordinals (e.g. high, medium, low).
• Risk impact The impact to the project’s goals and objectives if the risk event were to happen, either expressed as a cardinal (i.e. a number from 0 to 10), or ordinal (i.e. high, medium, low). The method chosen for impact must duplicate the method chosen for probability.
• Risk PI score The product of the probability and the impact. This is either a number from 0 to 100 or a description (i.e. low-low, low medium, etc.).
• Risk costThis can be expressed in monetary terms, time, quality, or scope.
• Risk Strategy One of accept, transfer, mitigate for threats and exploit, enhance, and share for opportunities. Both threats and opportunities can be accepted or managed with a contingency plan.
• ResponsibilityThe name of the team member responsible for implementation of the strategy where this is someone other than yourself.

• Strategy Description This is mandatory when the strategy is other than acceptance.
• Status This refers to whether the mitigation strategy has been implemented. A one word indication of status, e.g. initial, planned, implemented, obsolete. You may want to add a fourth status to capture the status of a contingency plan, for example "ready” to indicate your plan is ready to implement if the "trigger” condition is encountered.
• Date The forecast date for implementation of the mitigation strategy. This does not apply to a contingency plan.
• ProximityThis refers to the proximity of the work, deliverable, or milestone at risk. For example, you have identified the risk of a dry wallers’ strike to the activity of dry walling the office building your project is building. The proximity will increase as the date approaches for the start of that work. This score can be numeric or ordinal. If you use a numeric system for capturing your PI score, a numeric system for proximity allows you to combine the PI and proximity scores (i.e. a number between 0 and 1,000).
• WBS # You may track the work involved in mitigating the risk in your scheduling tool if this makes monitoring of the work easier.
• Trigger The indicator that will tell you when you must implement your contingency plan. The trigger is the condition that will necessitate the implementation of your contingency plan.
• Comments Any additional, anecdotal information about the risk, such as the effectiveness of the strategy.
• Risk ThresholdThe PI score above which a risk strategy other than acceptance must be defined.

Your project risk register must be updated whenever any of the information described above changes. You should be especially vigilant of your contingency plan triggers, a once a week review of this information could reveal trigger conditions for your plan were reached 6 days ago and you will be exactly 6 days too late in implementing your plan.

When to Update

Some of your risk information will be updated on the fly, as you become aware of a change in the circumstances surrounding your project, some will be updated at regular intervals. Information you gather from monitoring your project’s progress is gathered on the fly and will be used to update your information about project risks. A key source of information is your project schedule. As work is completed and new work undertaken and you update your project schedule (MS Project file or other) with a percentage complete date, assess the activity for related risks. Where the starting date for an activity is a week closer, you may want to update your proximity score. You will want to obsolete a risk here an activity, deliverable, or milestone at risk has been completed or passed. You may break work down further in your plan as it approaches and that breakdown may reveal risks hidden to you before. You should repeat the steps you took to score your risk and devise a strategy for managing it.

Project status review meetings, team meetings, and even job huddles are excellent venues for updating information about the current project risks being monitored and new risks that have escaped your notice. Devote a portion of your project status review meeting to the business of reviewing project risks; don’t waste time on obsolete risks or risks that are too distant for anyone to focus on yet. Use the risk register to focus discussion. High light the risks you want to review. Jog everyone’s memory by reading the description of the risk event and then poll the team to find out if any new information has come to light which might change the risk probability or impact. Review risks being managed with a mitigation plan to determine if the trigger conditions have been encountered. Conduct risk review meetings where the scale of your project warrants the extra meeting time. These meetings should be conducted with Subject Matter Experts who have good knowledge of the risks and some knowledge of risk management. You should conduct risk review meetings where you have broken your project down into sub-projects which are each managed by a project manager who reports to you.

Don’t neglect to include the topic of risks, new risks, and changes to identified risks as subject matter for your casual conversations with project team members. You’ll find if you practice your "walk around” management skills, you will increase your chances of identifying new risks as soon as they become known to the team. Listen with one ear tuned to the risk "station”. Conversations that involve what if scenarios can frequently lead to the description of a risk event which you may not have been aware of. Probe for the existence of trigger conditions for risks managed by a contingency plan. You may want to begin a conversation with "Have you noticed… (evidence of the trigger conditions).”

Risks will change dramatically from one project phase to another. You may want to conduct a risk workshop with the team at the start of each project phase where the project is large enough to warrant the expense. Use your judgment when you decide whether your project warrants risk review meetings and multiple work shops. The scale of the team involvement in managing project risks should be proportional to the size of the project and within your risk management budget. You may track time for risk management activities separately from other administrative activities in which case you’ll need to ensure you stay within your budget. Even where you don’t segregate risk management activities from other administrative activities you need to ensure that you don’t overburden the team to the point where the utilization rate suffers.

Obsolete Risks

Obsolete risks should be marked as obsolete in your risk register as soon as you become aware of their obsolescence. These risks should not be included in any of your reviews, unless they become active again (the recurrence of the conditions which produced the original risk will indicate the recurrence of the risk). Just mark the risk as obsolete in the register so that a viewer can tell at a glance that it is no longer active without removing it. You need to leave the information about the obsolete risk in your register so it can be archived at the end of the project, or project phase, with the rest of the information.

Risks can become obsolete when the conditions that produce the possibility of the risk event have passed or when the risk event has happened. If the risk event occurred (and it was not an accepted risk) you have some analysis to do. You need to analyze what went wrong with your avoidance strategy, if that was the strategy you chose. This analysis won’t help your project but may save projects that follow yours. You may not have time to determine a better avoidance strategy, your project is probably running over budget and behind schedule already, but at least indicate in your register that the strategy failed.

Risks that are mitigated are somewhat more difficult to analyze. It is particularly difficult to determine whether a strategy designed to reduce the probability of a risk event was effective. The risk event either happens, or it doesn’t. It is somewhat easier to assess the effect your mitigation strategy has on impact. If the impact on your project matches the worst case scenario of your risk event, your strategy was not effective. Take the risk mitigation strategy of the flu shot. You identified the flu as a risk to your project and took the step of having the team inoculated against it. If only one member of your team took time off due to the flu, it is very likely the inoculations had the desired effect. It will be a little more difficult to assess the effectiveness of the strategy if a percentage of the team comes down with the flu.

Risks that are transferred require special action. The best example is a risk that has been transferred with an insurance policy. You will need to initiate action as soon as you have been notified of the risk event, in this case the action would be the filing of an insurance claim.

Changes to the Project

Change management and risk management must work hand in hand if your project is to be successful. Changes to any of the project’s goals and objectives may introduce new risks to the project and/or may obsolete existing risks. Risk identification and analysis should be part of the analysis of every change request. You must make the scale of the analysis proportional to the scale of the requested change, while at the same time identifying any new risk event that the change might expose the project to, or existing risks that would become obsolete. You should evaluate the new risk event to determine its probability and impact to calculate its PI score. Identify an effective risk strategy if the PI score exceeds the project risk threshold, or simply note the risk if it doesn’t.

The new risk event, its mitigation strategy, and any risks that would become obsolete if the requested change were to be implemented will factor into the business case for the change. The cost of implementing the suggested risk mitigation strategy, along with the cost of the impact of the risk event, should it happen, should be entered in the cost side of the business case. The savings from any risk strategies that could be avoided due to an obsolete risk should be entered in the benefits side of the business case. This information should be captured in the change request. Acceptance of the requested change should trigger the entry of this information in the risk register and the implementation of the risk strategy. The information will be archived with the change request should the change be rejected.

Risk Register vs. Project Plan

There is frequently an overlap of information in the risk register and the MS Project (or other project management tool) file. Risks that are accepted will not cross over from the register to the MS Project file but risks addressed with any other strategy may. The trick is to know when you should enter information about the risk in the MS Project file.

The MS Project file is useful for tracking work. Its key output is the Work Breakdown Structure (WBS), designed to help the project manager organize, track, and control work. Any time that a risk strategy requires multiple activities or work packages you should consider the benefit of managing that work in your MS Project file. The work is part of the work of the project after all and tracking it there will make it easier to control than if you attempt tracking it in the risk register. Risk registers are usually fairly simple spreadsheets containing the information in the list in the beginning of this article while your MS Project file is designed to break the work down, then track it to ensure it gets completed.

You will need to identify any work you track in your MS Project file with risk management if the risk management budget is tracked separately. There are several different ways of accomplishing this, for example creating a separate sub-project to capture and track risk management related work.

A simple rule of thumb to determine whether to track risk management work in your MS Project file is this: if the work of implementing the risk strategy should be broken down, or the work requires more than one activity, you will probably save time and effort by tracking it in the MS Project file.

Budgets

You need to monitor your risk management budget, if that budget is separate from the project budget. The budget may be given to you in the form of money, or time. If you are implementing your risk strategies on budget, you won’t need to return to your project sponsor to ask for more. If you are overrunning the budget you will need to change the project by either increasing the risk budget, or accepting more risk. Unused portions of the budget should be returned to the sponsor.

Risk reserves or contingencies should also be monitored. Reserves may be given to you in the form of money or time. In software projects, time is a much more common form of reserve, in this case you will allocate your budget to the project by buffering the work on the critical path. For example, if you are given a month of reserve for a 9 month project, you would allocate portions of that month to activities on the critical path that were at risk, allocating the largest amounts of time for the activities most at risk. You should alert your sponsor when you are likely to consume the budget before the project is complete. Unused portions of cash reserves should be returned to the project sponsors as the activities they were reserved for are completed.

Reporting

Risks should form a part of the reporting of the project. You should be able to mine all the information you will need from your risk register. You do not want to report on each risk to the project so need to be selective when deciding on which risks to report on. You may set a threshold for risks to put in your report, such as any risks with a PI score over 80, or only risks with a high-high score. You can also restrict the risks by number, for example only reporting on the top 6 risks to the project. The proximity of the risk should also influence your decision on which risks to report on. No-one will be terribly interested in a risk to the User Acceptance testing phase of your project during project planning.

You should include a brief description of the risk event and the strategy you have chosen to address it. You may also want to include the status of the strategy and an evaluation of its effectiveness – has the strategy been implemented? Is it proving to be effective? How has the PI score been influenced? You may also want to describe triggers for contingency plans.

Risk Scoring

Risks are scored for probability and impact after identification and that score determines whether the risk will be accepted or a strategy devised to manage the risk, but what happens to the scores over the life of the project? Does it make sense to assess a risk as having a high probability of happening, even after an expensive strategy has been implemented to reduce its probability? Of course not. The trouble is that at the outset the probability and impact scores merely assess the probability of the event happening and the impact if it does. After a strategy has been implemented that is designed to mitigate the risk, you really can’t evaluate the PI score of the risk event without evaluating the strategy you have implemented.

You don’t necessarily need to consider the impact of the mitigation strategy on the probability and impact of the risk event, but you do need to evaluate the effectiveness of the strategy periodically and use this evaluation to determine if a new or additional strategy needs to be implemented to mitigate the risk. Take our flu scenario as an example. You’ve taken the precaution of having the entire team inoculated for flu because that was identified as an effective strategy to manage that risk, but now a new strain of virus is making the rounds. You need to ask the question: is the vaccine we used effective against the new strain? If it isn’t, should we take any other precautions to mitigate this risk? You may decide that the probability of a significant portion of the team falling ill with the flu has increased to the point that you need to make contingency plans for hiring contract programmers to pick up the slack if more than 2 team members become ill.

The obvious way to factor in the effect the mitigation strategy has on the risk is to re-evaluate the probability and impact scores based on the project environment, including the risk strategy. The new probability score of a risk using an avoidance strategy should be 0. If you or the Subject Matter Experts re-assess the probability of the risk occurring at more than 0, you will need to re-evaluate the effectiveness of that strategy and determine if a new one is needed. You would factor in a mitigation strategy in the same way and re-evaluate the strategy if the PI score increased. You do not need to use this method in order to factor strategy effectiveness into your scoring. Another method is to simply identify the strategy as effective or not effective. Strategies that are replaced with new, more effective strategies should be retired and any future work associated with them should be removed from your plans. For risks requiring additional strategies to increase effectiveness, simply add the new strategy to your plan. A third approach is to capture a separate PI score for the strategy. Score the risk event without factoring in the strategy, then re-score it factoring in the strategy.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP^® courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.