Security

Managing project risk is easy with the right process

A lot of project managers are intimidated by the notion of risk management. However, this simple five-step process will be more than adequate for most projects.

A reactive project manager tries to resolve issues when they occur. A proactive project manager tries to resolve problems before they occur. Here's a process you can use to identify risks before they occur:

1. Identify all risks

Perform a complete assessment of project risk. The purpose of this step is to cast a wide net to uncover as many potential risks as possible.

2. Analyze the risks

In the prior step, you uncovered as many risks as possible. You'll find there are usually too many potential risks to manage successfully. In fact, many of them don't need to be managed since they have a low probability of occurring or they would have a low impact on your project. In this step, group the identified risks into high, medium, or low categories. For most projects this can be a subjective assignment based on your best estimates. On some projects, this would be based on rigorous risk models, simulations, and quantitative techniques.

3. Respond to the high risks

Create a response plan for each high-level risk that you identified to ensure the risk is managed successfully. This plan should include activities to manage the risk, as well as the people assigned, completion dates, and periodic dates to monitor progress. There are five major responses to a risk -- leave it, monitor it, avoid it, move it to a third party, or mitigate it. The risk plan activities should be moved to your project schedule. You should also evaluate the medium-level risks to determine if the impact is severe enough that they should have a risk response plan created for them as well.

4. Create a Contingency Plan (optional)

A Contingency Plan describes the consequences to the project if the risk plan fails and the risk actually occurs. In other words, identify what would happen to the project if the future risk turns into a current issue. This helps you ensure that the effort associated with the risk plan is proportional to the potential consequences. For instance, if the consequence of a potential risk occurring is that the project will need to be stopped, this should be a strong indication that the risk plan must be aggressive and comprehensive to ensure that the risk is managed successfully.

5. Monitor risks

You need to monitor the risks to ensure they are being executed successfully. You should add new risk plan activities if it looks like the risk is not being managed successfully.

You also need to periodically evaluate risks throughout the project based on current circumstances. New risks may arise as the project is unfolding and some risks that were not identified early may become visible at a later date. You should perform this ongoing risk evaluation on a regular basis – say, monthly or at the completion of major milestones.

I know that a lot of project managers are intimidated by the notion of risk management. However, this simple five-step process above will be more than adequate for most projects.

14 comments
gtkeller
gtkeller

In ?Identifying all risks? it is mentioned to ?cast a wide net? I believe it would be more apropos to reconnoiter. Project Managers are not the guru with all the answers; they bring the information or the experts together. The Project Managers need to get out and discuss the project with the individual team members or do some research themselves on risks and questionable issues which could become risks. I agree to a certain degree about Analyzing risk, but if you have a project with to many risks to manage, I would have to advise to find another project. Or maybe not confuse risk with issues. Another method to analyzing risks would be to talk to SME?s (Subject Mater Expert) about the risk, to identify different approaches or determine level of risk. You may find that in talking to several people that depending on the mitigation plan the Risk could change from High to Low or negated altogether. In reference to managing the risk and contingency planning, I agree with the other response, Contingency planning is NOT an option, especially in high level risks. It should also be noted that there is a difference between Contingency planning and Risk mitigation or ?Risk Management? (as referred to in the article). There has to be a point in time where the project sponsor and project manager agree that the cost and timing of mitigating the risk far exceeds to cost and or delay in schedule of implementing the contingency plan or plans. In ?Monitoring risks? like in all plans, and I should also mention a project plan is not a project schedule, there should be a review and re-planning phase to ensure the actions taken are on track, or on task, to reduce scope creep or determine if a contingency plan should be implemented. One additional thought that I have run across with Pm?s is knowing the difference between risk mitigation and risk avoidance, risk avoidance being?..where Project Managers think, by assigning the issue to a contractor or another group, the issue is resolved, this is only avoiding the inevitable. Just some quick thoughts that came to mind, after reading your article?..

JMUnderwood11
JMUnderwood11

Can you provide a few real examples of what you would identify as a risk in a project plan? Thanks.

slksport
slksport

This article posits one axis of risk: the relative amount (high medium or low). Think of a risk matrix, where the x axis is consequences (perhaps a scale of one to ten for example) and the y axis is likelihood. The farther to the upper right an issue is, the more attention it needs. For each risk, define an approach: mitigate, monitor, accept, or research (with a deadline on the last one). And for each risk, your project plan should track the trend over time: more or less likely, more or less severe consequences? That lets you track the results of your strategy.

galleman
galleman

The management of risk does not allow contingency to be "optional," in the literal sense. An optional contingency means you are ignoring the risk, which is a valid step in Plan, Assess, Handle and Monitor processes. But it is a dangerous one for the naive risk manager. It would have been better to state that all identified risks (once they are truly identified as risks and not just issues with the project), most have a "Handling" plan. If "handling" means ignore then that would be an explicit response. The way suggested here provides a trapdoor for the PM to "ignore" risks before assessing there impact. As well any risk that is not "ignored" needs an assigned budget somewhere in the plan. Otherwise it will be the same as "ignore."

SObaldrick
SObaldrick

.. is to identify the risks. I would like to see more information about risk gathering. Do you simply brainstorm amongst everyone associated with the project? At what point do you draw the line and say, "we've got enough risks, let's start prioritizing them"? Note that this is not necessarily a sequential process. New risks can be identified at any time during the project. One view I might like to suggest, is to identify what can go wrong with the project, and discover the causes for each consequence. For example, Risks that may cause cancellation of the project - technology, funding, schedule overruns, etc. This may be due to, not having the correct resources, funding does not meet the original budget, the right skills are not available at this time. Also anytime the project is reliant on a deliverable by a group outside the of the project manager's immediate control, it is a risk to the schedule. Les.

Mark.swabey
Mark.swabey

Try a brainstorming session with your project team. Instead of a blank whiteboard, try a matrix with Technical, Human and Politico/Economic across top and Team, Project Organisation, External down the side. This helps you focus on each area and also not just what is inside your project - most risks hit your project from outside, but with a little imagination, you can protect yourself remarkably well from their effects. See www.riskaid.co.uk if you want to know more. Mark

JamesRL
JamesRL

First, start with a series of questions based on the traditional PM triangle - resources/budget/time. What if any are the risks around resources? Are there scarce/high demand skill sets required for this project. Are the reources fully committed? Are there resources required that are being shared with other high priority projects? Budgets: Are the costs rough estimates or finely tuned? Have we done enough of these types of projects to know if we have budgeted well? Are there contingency funds available if we have made a mistake? Is there a chance the funding will get pulled? Time: Have we done a critical path analysis to verify our schedule, and analysed each item on the path? Have we accounted for vacations, holidays, lags? Once you have those I would look at: Technology risks - have we used this tech before? Is this stable, and well supported? Do we have experience using this technology? Do we have depth in using this technology? Once you ahve asked yourselves those questions, ask yourself what is unique about the project and then even more will come out. James

Wayne M.
Wayne M.

In software development projects, the most common risks I identify are concerning the availability of resources. For one proposal, we assumed the client would provide an expensive but necessary piece of software. The project risk was that this software would not be provided. This was a realized risk due to internal politics at the client where the group holding the license would not allow access by contractors. We ended up spending about 3 man-months developing an alternative based on freely available shareware. Another risk might be security clearances. If you assume all personnel will be cleared in n months, there is the risk that not all (or even none of the) personnel will be cleared after n months. If you are dealing with outside suppliers or contractors, there is the risk they will not provide their component by the needed date or the component may not function as desired. [Delegating risk to others is really just a shell game. You still bear the risk if the outsider messes up.] I usually find it conceptually easier to identify assumptions - what are the things that I am assuming to happen? These are easily converted to risks by looking at what occurs if the assumed events do not occur. It's just semantics, but it seems to help me think about the issue.

slksport
slksport

If it is a big project, many modules will be developed in parallel. Integrating them is a risk. If you are using a rapid prototyping methodology then scope creep is a risk. If you need to add team members, the delay in getting them up to speed is a risk (albeit a low one and manageable). If you have other projects that might take away your resources, that's a risk. If the regulatory requirements in your industry might change partway through your dev and affect the standards, that's a risk.

gtkeller
gtkeller

An example that comes to mind in the IT area would be building project planning and scheduling resources for an older code to convert or update, when the resource is lacking the experience, or has limited experience with the older code, or off shoring the resource without having worked with that vendor to become familiar with their performance. This could be a risk to the project that could be thought of as a low or medium risk, but with out the proper attention could quickly become a high risk, and potential to late to institute a contingency plan.

JamesRL
JamesRL

By just focussing on probability you miss something.... If something has a low probabilty and a very high impact, you probably want to still do the analysis and look at mitigation. In Large scale projects I would not only look at the risks - the impact and the probabilty, but assess the cost of mitigation. If mitigation is inexpensive (time and/or money) then build it into your project plan. You can analyse the cost of mitigation versus the potential cost of ignoring the risk... James

Wayne M.
Wayne M.

In the context of the article, I believe what are being described are potential risks. When a potential risk is "ignored" or "accepted", it means that one is not preparing a course of action (the contingency plan) prior to the actual occurrence of the risk event. If an ignored risk does occur, one will still need to react to it, but without any sort of plan in place. An example of an ignored risk for a software development project would be a building fire. Should a fire occur, it could significantly affect the project, but, in my experience, no one will create a contingency plan for such an unlikely event. Should the fire occur, one would assess the situation after the fact and determine what steps to take. Determining how one will address potential risks is different from planning (and sometimes preparing) the contingencies one will take should the risk occur.

Wayne M.
Wayne M.

The hardest part, in my experience, in risk management is to either allocate schedule and budget buffer to cover potential risks or to generate a new schedule and budget should a risk occur. Until it is realized that mitigating a risk reuires time and money, risk managment is largely a ppaperwork generation effort.

Mark.swabey
Mark.swabey

To really work out the effectiveness, you are absoluetly right to include the cost of mitigation. However there is a subtlety here that most people miss - is the action you propose to prevent the risk or to minimise the impact. If you think of it that way, your actions are more focussed, and there is another point - if the action is prventative, you will have to pay for the action - before the risk occurs. If the action is to minimise the impact, then you only have to spend the money IF the risk occurs. Take that into account in your calculations and you will have the real view of risk costing. If you want to know more, see www.riskaid.co.uk. Mark