Lies, Damn Lies, Statistics & Risk Management

Past willful risky behavior, and then outright foolishness, we have Risk Mismanagement. We’ve all head the quote “Lies, damned lies, and statistics” (author unknown) with its intention that statistics can be used to lie persuasively or lend credence to otherwise suspect arguments. With Risk Management we’ve layered Management on top of statistics - this is where things can really go wrong and provide a false sense of security. Individuals and organizations all have not only a tolerance for risk, but also seemingly a tolerance for risk management itself. This later tolerance biases our Management, limiting its effective application.

This article uses examples primarily from IT Operational and Project Risk Management but is broadly applicable. It deals primarily with the organizational behavioral failures around Risk Management.

The Common Mismethodology
While there are plenty of Risk Management Methodologies, this one will suffice. It’s presented in reverse order as that is how many organizations mishandle it – so my Evil Twin will be narrating some of the situations that occur in this way.

6. Implementation of Treatments
5. Prioritization of Treatments
4. Identification of Risk Treatments
3. Determine Risk associated with Threats
2. Assessment of Threats
1. Identification of Threats

6. Implementation of Treatments
Our budget is $85,000 so let’s spend it. How can we treat some of our threats? Actually, we don’t know what treatments would be most effective, but we’ve got to do something. We’ll add an extra signature here, a process there, a database of information here, remove some rights there, and hey I read about this in an industry magazine so let’s do this other thing.

Unfortunately, we’re having trouble getting buy-in from our Development Managers! Seems Risk Management and Accountability are not in their yearly goals and objectives – only functional point delivery and cost containment are. Anyway, those Development guys just throw the product over the wall to the Operations department, and then they have to deal with the operational bugs and data integrity issues.

I feel safer.

5. Prioritization of Treatments
Let’s get something going here even though we haven’t completely tied Risks to Treatments. Look, “Treatment C” should be easy – let’s start with that. How are we going to do “Treatment A”? Could be expensive, let’s table that. Here’s another good idea, “Treatment 1”, it’s not on the list, but how could it not help? CXO Mr. David has talked to me about “Treatment D” – seems his staff would have to change how they are doing things, so let mark that as hold and I’ll circle back with him, um, soon … ish.

4. Identification of Risk Treatments
Treat first, ask questions later:

• “Risk Transfer”, I like the ring of that! If it’s outside my department and budget, it doesn’t exist, and free!
• “Risk Retention” I can live with that, but let’s not really tell anyone. It’s better if they think we’re covered. And it’s free!
• “Risk Mitigation” of our server hangs and faults? Reboot! It’s fast and will keep our metrics high. The root-cause analysis will have to wait until it fails in non-production hours, or Saturday evenings between 11:45pm and Midnight.
• “Risk Avoidance.” Well, it’s not like we can’t do this project, nor change the budget or timeline. "Um, Yeah... I'm gonna need you to come in on Saturday* [and get those functional points done, but don’t worry about checking for buffer overflow, it’ll be fine]”

3. Determine Risk associated with Threats
I didn’t have time to go through the prior years change control logs, organization assets, or lessons learned document, but I talked over likelihood of occurrence with the team.

Look at this nice chart – it’s ordered and orderly: the threat, the rate of occurrence, the impact, and the risk value and description. Very comforting despite the false precision. It’s math. How can you argue with math? Put it in a PowerPoint and it’s Gold.

2. Assessment of Threats
Fire! Now what happens? Probably, we’re all on our way to being fired. Time to CYA. Along the way, let’s limit to one each resulting problem from any one source issue. Let’s recount “war stories” and see if we find the correlative cause post-hoc. How does one measure “we’re out of business”? Doesn’t matter, we’re going to toss out the outliers anyway.

Time to quantify the qualitative.

1. Identification of Threats
Look at this Risk Management process! How much is this going to cost me? Can you just go take care of it while WE do something useful like getting the project done?

After extensive analysis of sources and problems, running various scenarios and checking best practices, we’ve identified the root risks: 1) We started this project, and 2) We’ve chartered an unyielding Project Triangle.

Not Doing the Wrong Thing
In Part II I’ll flip this around and look at what can be done.

* Quoting “Office Space”, as if that needed any introduction.