A participant in a workshop alleged that coconuts are more dangerous in some parts of the world than sharks. Apparently he has seen statistics showing that in the South Pacific there are substantially more deaths related to falling coconuts than shark attacks.
So at a typical resort by the beach, people will be worried about sharks when in the water, but be quite relaxed about sitting under (a potentially lethal) coconut tree.
I guess sharks are a bit scarier than falling coconuts. Many of us have seen Jaws but nobody has yet agreed to film my script for “Coconut Apocalypse” where a resort tries to cover up the rising fatalities caused by a new heavier and more lethal variety of coconut. Indeed I have never seen a horror movie about plunging nuts of any kind.
This is a specific example of something known as “Risk Outrage”. The amount people worry about a particular risk is not always related to the danger posed by the risk. Rather it is often related to the outrage in the media last time it happened or the grumpiness of an executive 3 years ago.
And in addition to causing people to fear death by shark more than death by coconut it also results in projects spending inordinate time and money mitigating one risk while ignoring another risk that the team know (in the back of their minds) is already impacting them.
For example they might ignore the likelihood of a restrucuture or a lack of DBA’s because they seem so likely. These are like the “project coconuts”. At the same time they might panic about dropping a feature or about the business changing their mind.
We all know that part of the project manager’s job is to monitor the likelihood and impact of different risks. But I think the PM should also be monitoring risk outrage.
This then becomes a communication exercise – calming people down when they are panicing about sharks and raising the outrage people feel about “deaths due to coconuts”.
One way to do this is to measure it. You may be familiar with the risk likelihood and impact graph:
But if you want to increase (or decrease) the focus of the team on a particular set of risks compared to others, you can graph risk against focus. Or if you want to remind the product team that a risk will have a seemingly low impact but will actually really annoy stakeholders or customers then you can graph “risk as likelihood and real impact” versus “likely outrage” if it does blow up:
So now I am going to claim that the PM must not just make sure that risks are recorded correctly, but more importantly that the team focus on the greatest risks and not just the most glamorous or extreme. In other words if a restructure or competitor release occurs every project, then the team should actively monitor and mitigate this, as opposed to just ignoring it because it is so common as to be mundane.
But now I am going to add one final point. The PM should also be monitoring the potential outrage (reaction) of customers and stakeholders and actively working to make bad outcomes more palitable, perhaps through public relations, scenario planning. And he/she should be getting people to stress more about seemingly absurd (or more often “Unmentionable”) risks, perhaps through public relations, advertising, scare campaigns, statistical analysis or scenario planning.
What do you think – is PR and scare campaigns to get people to worry more about falling coconuts and less about sharks good project management, playing politics or crazy talk?
James King 