Risk Management

I get emails from TechRepublic on project management, mostly from Tom Mochal. Tom's submission are interesting most of the time. He's recent post was on Risk Management and making it easy. Two things struck me:

1. The language used to describe the actions is a bit off
2. One critical step was skipped.

There are four primary process areas  of risk management:

1. Planning
2. Assessment
3. Handling
4. Monitoring

Add Feedback and the Identification and Analysis processes to the Assessment and you get 7 total areas that need to be addressed when you claim you are "Managing Risk." There are several good sources for guidance in managing risks. PMI PMBOK is one, but it is simply a restatement of the original sources and has a serious issues with its approach to calculating the Risk values, which I describe below. The best source of risk management background is Risk Management Guide for DoD Acquisition, Fifth Editon. While this document may appear to be overkill for IT project managers, it contains all the processes needed to actually manage risk. You can scale the suggested actions down to fit your needs, but the Process Areas need to be covered in any credible risk management approach to IT projects.
    These process areas are arranged in the following way:

Doing each process areas is required in some way. Ignoring the risk may be a proper way, but having the mitigation process be "optional" - as suggested by Tom - seems a bit sporty to me. Why not just state publicly that an identified risk will be ignored. This happens all the time - the ignoring part - and when the risk appears everyone is surprised and disappointed. Documenting the risk's, there management and the feedback from this management is skipped in Tom's "easy risk management" process. This is another source of disappointment often found in IT projects.
    So take a look at the DoD handbook. There are other good risk management books. One of my favorite (altough it does not follow the current Process Area guidance) is Managing Risk, Elaine Hall, Addison Wesley (SEI Press) and Continuous Risk Management Guidebook, Software Engineering Institute Press. Both provide solid guidance for software project risk management.
The PMBOK Problem
     PMBOK and many other risk management books would have us multiple the probability of occurrence   with the consequential outcome to get a "Risk Factor." The DoD Version of PMBOK can be downloaded for free and contains many improved sections. This book is basically the Table of Contents of PMBOK, but with much better approached to project management. One critical one is the Risk chapter.
    Here and in Ed Conrow's Effective Risk Management, the multiplication of probabilities is forbidden. They are probabilities that are in fact uncalibrated ordinal values and the product of their multiplication is meaningless. Do Not do this. Instead:

1. Use a non-numeric scale - A,B,C,D,E - for identifying the outcomes of a risk.
2. Then construct a 5x5 matrix of the probability of occurrence and the outcome and explicitly state the impact on the project when a risk occurs and its outcome.

When looking at this chart - and its Green, Yellow, Red areas - the project management can sort out the needed actions for each identified risk. Each risk has one of these charts, or at worst, each class of risk. Doing math on probabilities of occurrence and the consequences is simply not allowed in the risk management processes of DoD, NASA, DOE and other domains where risks kill people.
    I hope Tom's article stimulates more conversation about "simple" ways to do risk management. But these ways need to be credible and produce usable results.