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."
Discussion on:
View:
Show:
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.
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.
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.
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
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
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
Mark
Can you provide a few real examples of what you would identify as a risk in a project plan?
Thanks.
Thanks.
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.
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.
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.
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.
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
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
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
Mark
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?..
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?..
.. 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.
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.
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.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
