Skip to main content

Risk = Hazard + Outrage

I read this book Freakonomics [A Rogue Economist Explores the Hidden Side of Everything by Steven D. Levitt, Stephen J. Dubner ] around an year back. The book presents data that many of us are familiar with and leads us to conclusions that are different. One interesting point that caught my attention, in the book was about Risk Management. The authors explain convincingly why Congress funds more for fighting terrorism than researching heart disease, even though heart disease kills more people than terrorism every year.

The authors quote the formula Risk = Hazard + Outrage in their explanation. The formula is the brain child of a person called Peter Sandmann. Outrage is defined as how people react to a 'perceived' ( not yet happened) or 'realized' (happened)  risk. People usually exhibit Outrage through emotions like fear, anger or frustration. Hazard is the actual 'effect' of the risk. Managing this 'effect' is covered by traditional risk management and is explained through the formula Risk = Magnitude of Impact x Probability of occurrence.

I related this formula to how we manage risks in our projects - pre and post realization of risks - and came up with the following thoughts.

#1 The risks we normally identify and manage are the ones that have a higher Outrage factor and lower hazard factor.

Take the example of an architectural decision, decided early in the project. Sometimes, these architectural decisions don't get the kind of attention they deserve. If you go by the formula given above, the outrage factor is less in this scenario, though the hazard factor (long term impact ) is high. Compare this to a bug found at the customer site, say in UAT phase. Look at the reaction of everyone to the bug. Here the hazard factor is relatively less and outrage factor is obviously higher. Compare the reactions in the two scenarios and you will understand

#2 We must actually concentrate on risks with a higher hazard factor.
Usually these kind of risks ( like people issues, architectural decisions) have a lower outrage factor ( before realization) and go un-noticed. But these type of Risks, when realized, have a bigger impact on the final outcome of the project.

#3 Risk Mitigation.
When a risk is realized, we should work more on the outrage factor ( with customers, Senior Management and other stake holders) to reduce its immediate impact. This will have a better outcome in managing the fall out of the risk, than working only on the hazard factor (as prescribed by traditional risk mitigation techniques).

#4 Highlighting a Risk.
When you want to highlight a risk to the concerned stakeholders, try to work on the outrage factor in the stake holders mind. The risks should get immediate attention.

Your thoughts are welcome.



Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …