We had a LOT of snow over the Christmas holiday. A LOT.
NOT the vehicle I drove around in!
Having barely made it out to my in-laws for my birthday celebration (and even more Christmas presents for my 3 spoiled sons) we stayed the night because it was getting worse and the snow plows weren’t going to be out until the next day in that area.
I wouldn’t have driven back on Saturday around noon but our dog Snickers needed to be cared for. So I left the family safe and warm inside and I ventured out.
AND THEN IT HAPPENED.
No, I didn’t get stuck or slide into the ditch. Fooled you!
I started thinking about the heightened level of risk all around me. Looking at it from a project manager’s eyes who has always taken risk management seriously, I started to notice some things that were important to me in this risky situation.
Data
- Before I left in the first place, I checked my city’s website to check the status of our fleet of snow plows. It enabled me to plan a route that was longer, but less risky.
- I also checked Twitter. Unfortunately the references to “my street” were not helpful. Sometimes data is unreliable for use in risk management decisions.
Equipment and Materials
In an area that gets a lot of snow, you have to be prepared. Some years we don’t get a big blizzard at all. Other years it can get pretty bad.
How do we mitigate this risk using equipment and materials?
- We own 4×4 trucks, snow blowers, shovels, and of course warm clothes.
- We own small cars too, but we don’t drive them when it’s like this out!
- We pack winter survival gear in our vehicles so that if we get stuck somewhere we don’t freeze to death.
- We throw shovels and chains when it’s bad just in case we get stuck or need to help someone else who is stuck in the snow.
- We make sure our cell phones are fully charged and the gas tank is full.
Contingency
As I was driving home, I made sure to leave a decent amount of space between me and the car to the front and side of me. In case the vehicle on my side started to slide, I wanted to have plenty of room to react. If possible I would speed up or slow down slightly so we were staggered and not directly across from each other.
The space in front of me was for 2 reasons.
- I wanted to have plenty of room so that if I started sliding when trying to stop, I would have extra room to gain control and not crash into the vehicle in front of me.
- I wanted plenty of room so that if a vehicle coming up behind me started to slide I could gently move forward into the buffer and prevent a collision from behind.
Attention & Feedback
All that buffer wouldn’t have done much for me if I wasn’t vigilant. I had to be sure the channels of information flow were open so I knew immediately if something bad was going down, what it was, and in many cases respond with an action I had already pre-planned.
- All my windows and mirrors were well cleared of ice and snow so I could see what was going on around me.
- I kept the defroster on to prevent the wind shield and side windows from fogging up.
- When coming to a stop, I kept a constant eye out for cars coming up behind me so if they started sliding I could use that buffer in front of me.
- I paid attention to the cars beside me too so I could react if they started sliding or decided at the last minute to change lanes while they had poor visibility due to being too lazy to clear their windows properly (yeah, that one happened)
Method of Operations
Finally I drove the truck in such a way to mitigate my risk of being on the road at such a lousy time.
- I drove slow and deliberately.
- When stopping it was gradual so as to not start sliding.
- Looking ahead more than usual to see upcoming obstacles, etc.
- On 2-lane roads I stayed in the left lane. This got me out of the way of crazy people who were turning on to the main street in little golf cart-like cars by gunning it through a 3-foot pile of snow the plows left. (yeah, that one happened too. Several times. Some got stuck, some made it through and careened out into the middle turning lane.)
- I used 4×4 low gear on unplowed residential streets and 4×4 high gear on the plowed streets.
There’s probably more that I just can’t think of right now. (How about “not living in South Dakota” as a mitigation plan!)
So how does this relate to risk management on your projects? How do you use data, equipment and materials, contingency, attention & feedback, and your method of operations to perform what I always like to call CONTINUOUS risk management?
Leave your comment below!
Related posts:
{ 44 comments… read them below or add one }
Josh,
We sent you that snow storm. Sunny here in Breckenridge now with nice “freshies” for our tuned skis.
But the description you provided above, and a good management approach it is, is not risk management.
The storm was forecast days ahead, and all the “issues” are well known and understood.
For a risk to be present it needs be have an unknown presence with a probability of appearing that is itself an unknown outcome.
The description you provided is an “issue” that can be dealt with with specific handling processes. Driving skills, tools in the trunk, charged cell phones, loads of power bars.
From PMI’s Practice Standard for Project Risk Management,
“Project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project’s objectives.”
I’d be hard pressed to say the storm was a “risk” with the weather service forecast in hand.
But here’s a counter example. Our son attends Western State in Gunnison and has his back country backpack with us here in Breck. In it is a Spot Satellite emergency locator transmitter (survivor guy endorsed), an avalanche locator, several cutting tools, and a pole to find his buddies under 8 feet of snow.
So “risk” in his world is avalanche country outside the bounds.
The probability of skiing into an avalanche “ready to happen,” has some probability and the outcome has some probability.
I see what you mean Glen, but I think we may be looking at the situation from different perspectives.
As Dr. Paul said below, I was making the analogy of the drive itself being a project, and the risk of a collision being the project risk I was focusing on.
[Given that] the roads are icy and some are unplowed
[there is a risk] I may get into a collision
[resulting in] bodily harm and property damage.
The collision was not a forgone conclusion; not an issue. It was a risk.
If you zoom out to the general condition of blizzards happening in South Dakota, I’ll go with you there. That’s a known quantity.
Josh –
“the roads are icy and some are unplowed” is not a cause, but I feel “the roads are icy and some are unplowed. I (Josh) doesnot have a good car or experience in driving this condition” is the cause, and the risk is “you may get into collision (threat)”, and the effect is “time delays (time) and property damage (cost)”
Am I right josh?
Sai
The way I formulate risk statements is as follows:
[Given] {condition}
[there is a possibility] {risk event}
[resulting in] {consequence}
I would say the risk exists due to the road conditions…the risk would still exist regardless of my experience level, although the probability might be higher for less experience driving in these conditions.
It is important to distinguish between risk causes and other factors that contribute to magnitude or probability. All are important and need to be taken into consideration, but the risk statement itself should highlight the condition that is causing the risk to be present in the first place.
Great discussion!
Since, you stated in your post “lots of snow” itself indicates that “the roads are icy” is a fact, that is it is 100% certain. How can a fact become a risk?
You should have a cause, and then the risk. The cause could be “how is you and your vehicle cause the risk?”.
The {condition} is not the risk; the {condition} exists! It sets the context and informs probability.
The real risk part of the statement is this:
[there is a possibility] {risk event}
So here’s a more real-word project example:
[Given that] {H1N1 is pandemic this year}
[there is a possibility] {that absenteeism will be higher than planned}
[resulting] {in failure to meet the planned review date}
The H1N1 situation in the population at large is a known quantity. What is not known is to what extent it will impact your project team, if at all. You are not experiencing the impact yet, nor do you know you will experience an impact.
The mitigation plan could include things like company-sponsored on-site vaccination, additional schedule contingency, etc. Or you could even decide to just accept the risk and hope it doesn’t happen (that wouldn’t be my plan).
I agree with your statement “H1N1 is pandemic this year” is a cause 50%
.
I feel you need add clarity in the cause statement in terms of your project context like “H1N1 is pandemic this year, and the knowledge about this disease is not known to the team”
Hmmm. No. I wasn’t saying that a lack of knowledge was causing the risk. That H1N1 is pandemic is not 50%, it’s 100%. It’s a fact.
It’s the local impact to my project team that I’m identifying as a risk with unknown probability.
I meant I agree your cause only 50%. I just want the cause to be reworded, so that in indicates the cause is specific to your project.
Am i right?
Josh,
There is a risk of a collision during adverse driving conditions. This is the type of risk insurance companies consider.
Most other conditions would be considered “issues” in a risk management paradigm, since the observable probability is 100% during norm winter driving conditions.
Josh,
I’m always troubled by making everything into a project.
While it may be useful from an analogy purpose, where’s the product or service produced by your drive.
Driving to work, driving to Gamma’s for Christmas or flying the airliner is “operations.” It has risks as well, it has resources and it may have a finite duration. But it doesn’t have many of the other attributes of projects.
This confusion between operations and project dilutes the value of “managing projects,” as well as over generalizes the notion of a project – to include anything and everything – with now beneficial outcome for doing so.
Josh,
We sent you that snow storm. Sunny here in Breckenridge now with nice “freshies” for our tuned skis.
But the description you provided above, and a good management approach it is, is not risk management.
The storm was forecast days ahead, and all the “issues” are well known and understood.
For a risk to be present it needs be have an unknown presence with a probability of appearing that is itself an unknown outcome.
The description you provided is an “issue” that can be dealt with with specific handling processes. Driving skills, tools in the trunk, charged cell phones, loads of power bars.
From PMI’s Practice Standard for Project Risk Management,
“Project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project’s objectives.”
I’d be hard pressed to say the storm was a “risk” with the weather service forecast in hand.
But here’s a counter example. Our son attends Western State in Gunnison and has his back country backpack with us here in Breck. In it is a Spot Satellite emergency locator transmitter (survivor guy endorsed), an avalanche locator, several cutting tools, and a pole to find his buddies under 8 feet of snow.
So “risk” in his world is avalanche country outside the bounds.
The probability of skiing into an avalanche “ready to happen,” has some probability and the outcome has some probability.
I see what you mean Glen, but I think we may be looking at the situation from different perspectives.
As Dr. Paul said below, I was making the analogy of the drive itself being a project, and the risk of a collision being the project risk I was focusing on.
[Given that] the roads are icy and some are unplowed
[there is a risk] I may get into a collision
[resulting in] bodily harm and property damage.
The collision was not a forgone conclusion; not an issue. It was a risk.
If you zoom out to the general condition of blizzards happening in South Dakota, I’ll go with you there. That’s a known quantity.
Josh –
“the roads are icy and some are unplowed” is not a cause, but I feel “the roads are icy and some are unplowed. I (Josh) doesnot have a good car or experience in driving this condition” is the cause, and the risk is “you may get into collision (threat)”, and the effect is “time delays (time) and property damage (cost)”
Am I right josh?
Sai
The way I formulate risk statements is as follows:
[Given] {condition}
[there is a possibility] {risk event}
[resulting in] {consequence}
I would say the risk exists due to the road conditions…the risk would still exist regardless of my experience level, although the probability might be higher for less experience driving in these conditions.
It is important to distinguish between risk causes and other factors that contribute to magnitude or probability. All are important and need to be taken into consideration, but the risk statement itself should highlight the condition that is causing the risk to be present in the first place.
Great discussion!
Since, you stated in your post “lots of snow” itself indicates that “the roads are icy” is a fact, that is it is 100% certain. How can a fact become a risk?
You should have a cause, and then the risk. The cause could be “how is you and your vehicle cause the risk?”.
The {condition} is not the risk; the {condition} exists! It sets the context and informs probability.
The real risk part of the statement is this:
[there is a possibility] {risk event}
So here’s a more real-word project example:
[Given that] {H1N1 is pandemic this year}
[there is a possibility] {that absenteeism will be higher than planned}
[resulting] {in failure to meet the planned review date}
The H1N1 situation in the population at large is a known quantity. What is not known is to what extent it will impact your project team, if at all. You are not experiencing the impact yet, nor do you know you will experience an impact.
The mitigation plan could include things like company-sponsored on-site vaccination, additional schedule contingency, etc. Or you could even decide to just accept the risk and hope it doesn’t happen (that wouldn’t be my plan).
I agree with your statement “H1N1 is pandemic this year” is a cause 50%
.
I feel you need add clarity in the cause statement in terms of your project context like “H1N1 is pandemic this year, and the knowledge about this disease is not known to the team”
Hmmm. No. I wasn’t saying that a lack of knowledge was causing the risk. That H1N1 is pandemic is not 50%, it’s 100%. It’s a fact.
It’s the local impact to my project team that I’m identifying as a risk with unknown probability.
I meant I agree your cause only 50%. I just want the cause to be reworded, so that in indicates the cause is specific to your project.
Am i right?
Josh,
There is a risk of a collision during adverse driving conditions. This is the type of risk insurance companies consider.
Most other conditions would be considered “issues” in a risk management paradigm, since the observable probability is 100% during norm winter driving conditions.
Josh,
I’m always troubled by making everything into a project.
While it may be useful from an analogy purpose, where’s the product or service produced by your drive.
Driving to work, driving to Gamma’s for Christmas or flying the airliner is “operations.” It has risks as well, it has resources and it may have a finite duration. But it doesn’t have many of the other attributes of projects.
This confusion between operations and project dilutes the value of “managing projects,” as well as over generalizes the notion of a project – to include anything and everything – with now beneficial outcome for doing so.
Hi Josh (and Glen)
As you know, I don’t necessarily consider PMI to be the be all/end all authority on anything.
In checking over my trusty Merriam Webster’s on-line dictionary, (Which I think enjoys much more credibility than does PMI) I find risk (in this context)defined to be ” the possibility of loss, injury, disadvantage, or destruction”.
So based on the standard English language dictionary definition of Risk, and given his plan to drive from point A to point B qualifies as a project (“a devised or proposed plan : a scheme for which there seems hope of success”) I think Josh’s story to be appropriate one.
I also think it makes sense from the more pragmatic perspective of being a prudently cautious professional. Was he assuming risk in driving home to feed his dog? Yes, of course. Did he mitigate those risks? Yes, of course he did…..
Now the real question is whether he captured those lessons learned and the next time he ventures out with a storm coming, does he leave behind sufficient food and water for his dog so he doesn’t have to take the risk of driving home over unplowed roads?
That is the REAL question in terms of project management…..
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
Great point on the lessons learned Dr. Paul!
Hi Josh (and Glen)
As you know, I don’t necessarily consider PMI to be the be all/end all authority on anything.
In checking over my trusty Merriam Webster’s on-line dictionary, (Which I think enjoys much more credibility than does PMI) I find risk (in this context)defined to be ” the possibility of loss, injury, disadvantage, or destruction”.
So based on the standard English language dictionary definition of Risk, and given his plan to drive from point A to point B qualifies as a project (“a devised or proposed plan : a scheme for which there seems hope of success”) I think Josh’s story to be appropriate one.
I also think it makes sense from the more pragmatic perspective of being a prudently cautious professional. Was he assuming risk in driving home to feed his dog? Yes, of course. Did he mitigate those risks? Yes, of course he did…..
Now the real question is whether he captured those lessons learned and the next time he ventures out with a storm coming, does he leave behind sufficient food and water for his dog so he doesn’t have to take the risk of driving home over unplowed roads?
That is the REAL question in terms of project management…..
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
Great point on the lessons learned Dr. Paul!
Folks, unfortunately, with all the hoopla over project management being (or not being) a profession and an almost cult like obsession with getting certified, we tend to forget that project management seems to be “hard wired” into the human psyche and that project management is 99% applied “common sense”.
We seem to have gotten so hung up on the tools and techniques that we forget to actually use them…. even though they exist in our tool box….
Wishing both of you and the rest of our readers a safe, happy, healthy and prosperous 2010.
And Josh, I expect to have that other “project” done this afternoon (Sunday morning your time)
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
Folks, unfortunately, with all the hoopla over project management being (or not being) a profession and an almost cult like obsession with getting certified, we tend to forget that project management seems to be “hard wired” into the human psyche and that project management is 99% applied “common sense”.
We seem to have gotten so hung up on the tools and techniques that we forget to actually use them…. even though they exist in our tool box….
Wishing both of you and the rest of our readers a safe, happy, healthy and prosperous 2010.
And Josh, I expect to have that other “project” done this afternoon (Sunday morning your time)
BR,
Dr. PDG, Jakarta
http://www.build-project-management-competency.com
I hope this turns into a great conversation about what IS and IS NOT risk management, and how we are or or not doing it on our projects.
Here’s another one:
[Given that] the roads are icy and some are unplowed
[there is a risk] I may get stuck in the snow
[resulting in] getting cold, delayed, and in a generally bad mood!
Seeking out data about which roads are plowed and which are not is an action to avoid or mitigate the risk. Having a 4×4 is too, because it may prevent me from getting stuck.
Having a survival kit is a part of the contingency plan, NOT a part of managing the risk. It’s for after the risk has already turned into an issue. Planning for it is a part of risk management to be sure, but it’s part of the contingency plan, not the mitigation plan.
I draw this distinction because I’ve run into people who think they are the same thing. They normally do a mitigation plan and disregard the contingency plan.
I argue that you need at least a basic high-level plan for each identified risk that is large enough. You want to formulate an approach for after the probability distribution has collapsed and you now have an ISSUE. If you started a blueprint before the building started on fire, you can go about fire fighting with a general approach that was agreed upon beforehand. This saves time, money, and frustration.
Josh — the problem that I have when teaching project risk management is that most risks are a chain of cause and effect. Using your example, the possible risk events include unplowed roads, icy roads, other unskilled drivers on the road, other improperly equipped vehicles, and so on, any one of which could result in either an accident or you getting stuck in the snow, that prevents you from getting to Snickers. A complete analysis would also allow for the possibility that you stop to help someone and something untoward happens while you are playing good Samaritan. This leads to a great number of possible risk statements.
Duncan
William R. Duncan, Project Management Partners
Director of Certification for asapm
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Great point Bill!
I have found in practice when brainstorming risks with a team, many times you’ll end up collapsing several of them into one because you realize they all have the same root cause, at least going back through the 5-why’s as far as you can manage and control. This works when the potential mitigation/avoidance measures are the same.
In my experience it’s been a judgment call by the team to determine what is distinct enough to call out on it’s own or combine.
When combining items into a larger risk statement though, I’ve found it useful to have separate contingency plans available to deal with multiple consequences after the risk has become an issue.
Anyone else have thoughts on this aspect?
Josh,
If you’d like to start a conversation about risk management, I’d suggest you look into the sources of guidance used by those working “high risk” projects. NASA, DOE, and DoD. I say this from my hands on experience of writing and executing Risk Management Plans (RMP) in nuclear power and weapons, manned space flight, and other DoD domains. While the PMI approach is an OK starting point, SEI’s Continuous Risk Management is a better of guidance for the software development world.
Next take a look at “The Death of Risk Management,”
http://www.dtic.mil/ndia/2008systems/7349gaydar.pdf
to see who we’ve dumbed down the application of risk management in many domains. As stated on the title page, the author is the Chief Engineer of NAVAIR. Each service has a CE, he’s the one accountable for all things that fly for the NAVY. Page 4 of that presentation speaks to the misunderstandings of your snowy driving trip. Page 19 is a machine that has killed many pilots and drew before the risks were truly understood.
On the web “The Risk Doctor” is a pretty good place to start. However the notions he uses of combining risk and opportunity are highly domain dependent. In the domain where things blow up and kill people, mixing them is usually limited to the early design stages.
For a quick overview of the principles of Risk Management see
http://www.lewisandfowler.com/presentations/RiskManagement6_19.pdf
For some historical background on the application of risk management read “Disasters and Accidents in Manned Space Flight, David Shayler, Springer / Praxis.
There are many other books, most bad, many other opinions, most untested in domains where people die or billion are lost with a single mistake.
The one book to own (other than the SEI CRM handbook which you can find on the web), is Edmund Conrow’s Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press, 2003.
For the “execution“ of the Risk Management Plan, see http://www.mitre.org/work/sepo/toolkits/risk/index.html for useful guidance. The Mitre approach is used on many programs we work. As well see the DOE 413.3 series a Risk Management handbook in support of the NQA-1 guidance.
Finally it is critical to separate programmatic risk from technical risk – although technical risk does drove programmatic risks. See DID 81650 for guidance on programmatic risk assessment.
Regarding you last sentence. First, the risk mitigation or retirement activities MUST be embedded in the Integrated Master Schedule, with funding and resources held in escrow. What happens in the traditional approach is when the risk becomes an issue; you usually don’t have any money or resources. So you’re both late and over budget. The better approach is to RETIRE the risk during the execution of the program.
When the risk becomes an Issue, normal project execution processes apply and the addressing of the issue becomes a work package management process with normal cost, schedule, and technical performance processes.
My final advice – as a practicing programmatic and technical risk manager on two high risk programs – is to NOT make up your own version of how to do things or to dumb down the definitions, adjust them for domains, or other similar simplifying approaches.
This dilust the practice and usefulness of RM. Instead look at the official guidance from DoD and DOE found at the Defense Acquisition University.
I hope this turns into a great conversation about what IS and IS NOT risk management, and how we are or or not doing it on our projects.
Here’s another one:
[Given that] the roads are icy and some are unplowed
[there is a risk] I may get stuck in the snow
[resulting in] getting cold, delayed, and in a generally bad mood!
Seeking out data about which roads are plowed and which are not is an action to avoid or mitigate the risk. Having a 4×4 is too, because it may prevent me from getting stuck.
Having a survival kit is a part of the contingency plan, NOT a part of managing the risk. It’s for after the risk has already turned into an issue. Planning for it is a part of risk management to be sure, but it’s part of the contingency plan, not the mitigation plan.
I draw this distinction because I’ve run into people who think they are the same thing. They normally do a mitigation plan and disregard the contingency plan.
I argue that you need at least a basic high-level plan for each identified risk that is large enough. You want to formulate an approach for after the probability distribution has collapsed and you now have an ISSUE. If you started a blueprint before the building started on fire, you can go about fire fighting with a general approach that was agreed upon beforehand. This saves time, money, and frustration.
Josh — the problem that I have when teaching project risk management is that most risks are a chain of cause and effect. Using your example, the possible risk events include unplowed roads, icy roads, other unskilled drivers on the road, other improperly equipped vehicles, and so on, any one of which could result in either an accident or you getting stuck in the snow, that prevents you from getting to Snickers. A complete analysis would also allow for the possibility that you stop to help someone and something untoward happens while you are playing good Samaritan. This leads to a great number of possible risk statements.
Duncan
William R. Duncan, Project Management Partners
Director of Certification for asapm
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Great point Bill!
I have found in practice when brainstorming risks with a team, many times you’ll end up collapsing several of them into one because you realize they all have the same root cause, at least going back through the 5-why’s as far as you can manage and control. This works when the potential mitigation/avoidance measures are the same.
In my experience it’s been a judgment call by the team to determine what is distinct enough to call out on it’s own or combine.
When combining items into a larger risk statement though, I’ve found it useful to have separate contingency plans available to deal with multiple consequences after the risk has become an issue.
Anyone else have thoughts on this aspect?
Josh,
If you’d like to start a conversation about risk management, I’d suggest you look into the sources of guidance used by those working “high risk” projects. NASA, DOE, and DoD. I say this from my hands on experience of writing and executing Risk Management Plans (RMP) in nuclear power and weapons, manned space flight, and other DoD domains. While the PMI approach is an OK starting point, SEI’s Continuous Risk Management is a better of guidance for the software development world.
Next take a look at “The Death of Risk Management,”
http://www.dtic.mil/ndia/2008systems/7349gaydar.pdf
to see who we’ve dumbed down the application of risk management in many domains. As stated on the title page, the author is the Chief Engineer of NAVAIR. Each service has a CE, he’s the one accountable for all things that fly for the NAVY. Page 4 of that presentation speaks to the misunderstandings of your snowy driving trip. Page 19 is a machine that has killed many pilots and drew before the risks were truly understood.
On the web “The Risk Doctor” is a pretty good place to start. However the notions he uses of combining risk and opportunity are highly domain dependent. In the domain where things blow up and kill people, mixing them is usually limited to the early design stages.
For a quick overview of the principles of Risk Management see
http://www.lewisandfowler.com/presentations/RiskManagement6_19.pdf
For some historical background on the application of risk management read “Disasters and Accidents in Manned Space Flight, David Shayler, Springer / Praxis.
There are many other books, most bad, many other opinions, most untested in domains where people die or billion are lost with a single mistake.
The one book to own (other than the SEI CRM handbook which you can find on the web), is Edmund Conrow’s Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press, 2003.
For the “execution“ of the Risk Management Plan, see http://www.mitre.org/work/sepo/toolkits/risk/index.html for useful guidance. The Mitre approach is used on many programs we work. As well see the DOE 413.3 series a Risk Management handbook in support of the NQA-1 guidance.
Finally it is critical to separate programmatic risk from technical risk – although technical risk does drove programmatic risks. See DID 81650 for guidance on programmatic risk assessment.
Regarding you last sentence. First, the risk mitigation or retirement activities MUST be embedded in the Integrated Master Schedule, with funding and resources held in escrow. What happens in the traditional approach is when the risk becomes an issue; you usually don’t have any money or resources. So you’re both late and over budget. The better approach is to RETIRE the risk during the execution of the program.
When the risk becomes an Issue, normal project execution processes apply and the addressing of the issue becomes a work package management process with normal cost, schedule, and technical performance processes.
My final advice – as a practicing programmatic and technical risk manager on two high risk programs – is to NOT make up your own version of how to do things or to dumb down the definitions, adjust them for domains, or other similar simplifying approaches.
This dilust the practice and usefulness of RM. Instead look at the official guidance from DoD and DOE found at the Defense Acquisition University.
Interesting post Josh. We have had snow here in the UK…but nothing, I repeat, nothing like the snow you have had. I stated to put pen to paper about what is called the risk based approach to snow here in the UK only to be beaten by a 400 mile journey…
This risk based approach to bad weather is simply why have large equipment lying around for 11 months of the year when we MAY get bad weather for a few days. There has been much criticism of the authorities here in the UK for poor snow preparation (an issue) and when the snow arrived even poorer gritting.
Your journey is a project – I support that one Josh. The interesting issue is experience. How experienced are you (we) as a driver in the snow and as Dr Paul suggests what can you learn from it?
I am returning on the same 400 mile trip on Monday and have started to look at all of the stuff you listed Josh. I’m learning and I only wish others did!
Thanks Ron. Experience may mean we come up with better mitigation plans and contingency plans, and when a risk turns into an issue we will probably be able to fire fight better.
So, I’m able to prepare for getting stuck in the snow better than someone from Ecuador because of my past experience. I’m also better able to react appropriately if I do get stuck because I’ve dug a lot of vehicles out before and know where to dig, how to rock the vehicle to gather momentum and clear space, etc.
I wanted to add that while experience may be helpful, it never completely eliminates the probability of a true risk.
I can still get stuck in the snow, no matter how experienced I am.
Josh,
Here’s a thought from our morning restart stand up on a large (several billion) Army program.
Risk – like a car accident – on the program are things we have no real control over, other that preparing as best as possible. For example the “flying machine,” can crash for a possibly unknown reason. It will be known after the crash of course, but at 1st flight test, it was not. The Flight Readiness Review (FRR) will have considered all risks to the 1st flight and either mitigated them or retired them prior to the FRR.
Now along the way, we identify potential causes of a crash and either retire them, mitigate them, or ignore them. The transfer option is not possible, since the client is the system integrator and the “buck stops there.”
The benefit of this approach is it separates the risk responses into – true “risk” and “risks we can do something about.” For the winter driving – your weather is likely more extreme than ours here on the front range – is to have in your car all the “risk response” materials. Blankets, fire starter, emergency radio, etc. etc.
Where the accident situation can’t carry all the response materials – like another car.
So when Duncan says there may be a great number of risk statements, this is a signal that risk management is not being performed well.
The “handleable” risks must be in the Integrated Master Schedule. We know they are risks and we know how to perform risks handling on them – one of the four responses. It’s the ones that we have no pre-defined response for that are the real “risk” to the program.
This allows risk management to focus on the “real” risks and systems engineering and program management to focus on the risks that can be handled.
Interesting post Josh. We have had snow here in the UK…but nothing, I repeat, nothing like the snow you have had. I stated to put pen to paper about what is called the risk based approach to snow here in the UK only to be beaten by a 400 mile journey…
This risk based approach to bad weather is simply why have large equipment lying around for 11 months of the year when we MAY get bad weather for a few days. There has been much criticism of the authorities here in the UK for poor snow preparation (an issue) and when the snow arrived even poorer gritting.
Your journey is a project – I support that one Josh. The interesting issue is experience. How experienced are you (we) as a driver in the snow and as Dr Paul suggests what can you learn from it?
I am returning on the same 400 mile trip on Monday and have started to look at all of the stuff you listed Josh. I’m learning and I only wish others did!
Thanks Ron. Experience may mean we come up with better mitigation plans and contingency plans, and when a risk turns into an issue we will probably be able to fire fight better.
So, I’m able to prepare for getting stuck in the snow better than someone from Ecuador because of my past experience. I’m also better able to react appropriately if I do get stuck because I’ve dug a lot of vehicles out before and know where to dig, how to rock the vehicle to gather momentum and clear space, etc.
I wanted to add that while experience may be helpful, it never completely eliminates the probability of a true risk.
I can still get stuck in the snow, no matter how experienced I am.
Josh,
Here’s a thought from our morning restart stand up on a large (several billion) Army program.
Risk – like a car accident – on the program are things we have no real control over, other that preparing as best as possible. For example the “flying machine,” can crash for a possibly unknown reason. It will be known after the crash of course, but at 1st flight test, it was not. The Flight Readiness Review (FRR) will have considered all risks to the 1st flight and either mitigated them or retired them prior to the FRR.
Now along the way, we identify potential causes of a crash and either retire them, mitigate them, or ignore them. The transfer option is not possible, since the client is the system integrator and the “buck stops there.”
The benefit of this approach is it separates the risk responses into – true “risk” and “risks we can do something about.” For the winter driving – your weather is likely more extreme than ours here on the front range – is to have in your car all the “risk response” materials. Blankets, fire starter, emergency radio, etc. etc.
Where the accident situation can’t carry all the response materials – like another car.
So when Duncan says there may be a great number of risk statements, this is a signal that risk management is not being performed well.
The “handleable” risks must be in the Integrated Master Schedule. We know they are risks and we know how to perform risks handling on them – one of the four responses. It’s the ones that we have no pre-defined response for that are the real “risk” to the program.
This allows risk management to focus on the “real” risks and systems engineering and program management to focus on the risks that can be handled.
{ 3 trackbacks }