Josh Nankivel has a nice thread going on his PMStudent blog about risk management. There's the usual number of responses from a variety of points of view. I'd like to make an important point from my personal experience in the risk management business on programs where improper managing of risk gets people killed and wastes billions in public funds.
Not all risk management approaches are equally credible
That's not to say these approaches aren't useful in the domain in which they are applied. Doing risk management on an ERP project. Doing risk management on a road paving project. Or maybe in Josh's notional example, doing risk management on the winter drive to the relatives.
But here's the problem with home grown risk management processes - as well as home grown processes for building a WBS, installing an EV management system, performing requirements management, writing proposals for FAR compliant procurements, conducting project performance measurement assessment, and a variety of other project and program management process areas.
There is a way of doing the work that gets you by in the domain in which you work.It's good enough.
"We do it this way in our world out here in the boondocks and it's worked for us, so it is likely it'll work for you as well."
And then there is a way of doing the work that follows a set of immutable principles.Principles developed over time in a variety of domains that are independent of the personnel apply them.
As one of our nieces is fond of saying to her advertising clients when they come up with their own ideas of how to write and place spots, when they say "we've go a great idea from a competitor, do you like this? "Ah, no so much" is her usual response.
So Here's Some Advice from a Program Manager on High Risk Programs
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,” to see how 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 many risk management situations.
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.
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 the Mitre framework for useful guidance. The Mitre approach is used on many programs we work. As well see the DOE 413.3 series and the Risk Management Guide for construction and high risk product based projects.
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.
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 for guidance – 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 dilutes the practice and usefulness of RM. Instead look at the official guidance from DoD and DOE found at the Defense Acquisition University.
Now for a Practical Example
Risk – like the car accident example Josh speaks to – on the program are things we have no real control over, other than preparing as best as possible for the probabilistic arrival. For example a “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 example it is prudent 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. The “handle-able” 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.
