Category: Risk

A prophets of doom workshop

On By James KingIn Implementation, RiskLeave a comment

In the past I have used some pretty dodgy approaches to defining risks in a project, from formal approaches like fault tree analysis through to informal approaches like “the evil genius” and “an international standard for being scared“.

So this article is not really a new one.  It is more a combination of evil geniuses and international standards for being scared.  But I think this workshop should work well when starting any project and particularly small projects with a simple project charter.

Continue reading “A prophets of doom workshop” →

Advertisements

An international standard for being scared?

On By James KingIn Risk5 Comments

I sometimes quote ISO90210 (not a real standard) to represent a common approach that, while often used, is not a formally recognised standard.  It is more a common but informal way people approach something.

In this case I am looking at how to be scared. 

Apparently there is a standard approach to being scared that inolves the amygdalae in our brain and us cheking our big catalogue of things to be scared of when any event happens. But that is a biological response and I am more interested here in a project management response.

So here is where I start – the ISO90210 standard for being scared at the start of a project (or halfway through):

  1. For both Product risk and project risk (see below for the definitions), write down a list of:
    • What could go wrong?
    • What would cause it?
    • When and how would we find out?
    • What would happen after we found out?
  2. Once you have a long list, review the list and look for patterns:
    • Are any 2 things symptoms of the same underlying cause or event?
    • Do several bad things result in a similar bad outcome?
    • What is the level of risk outrage – ie how pissed off would the stakeholders be with each, regardless of how bad or mild it really is?
    • Ask yourself – If one or two of these did happen, which ones would they be?
    • Ask yourself – If there is one thing we know we should deal with, but probably won’t, what would it be?
  3. Consolidate your list into the top three (or 1 or 5):
    • Which 3 things should we be the most worried about?
    • Why them in particular?

 Then you have a consolidated list of what you should be the most scared of. The final steps are:

  1. Compare your list to what others came up with; and
  2. Discuss what we should do about the combined list of concerns.

Note – it is worth looking at both product risk and process risk:

  • Product risk is the risk that we will deliver the project but that the product we deliver will not do what we want (it will fail to meet expectations or do unwanted things). For example it might not sell or it might canabalise demand for another product; and
  • Process risk (or project risk) is the risk the project won’t deliver the product we have asked for when we want it. Examples include too many bugs, a restructure impacting the team and so forth.

At least if you are going to be scared (which you should be on every project), you can now do it properly.

A risk register for lazy project teams

On By James KingIn Agile development, Risk, Techniques2 Comments

I told someone this article was already up on my blog and then realised I never got around to publishing it. Sorry about that.

Successful projects are generally successful because of the way they managed their risks; so I generally try to hire lucky project managers and surround them with a team of people who have (or are due for) some good karma, in order to avoid having bad things happen on the project.

But sometimes that is not enough, so I like to put in place risk registers, risk and innovation meetings and a bunch of other things to make sure I am managing my risks effectively.

But sometimes that is too much overhead for a small team to bear, so what can the team do that is easy, yet still reasonably effective?

Continue reading “A risk register for lazy project teams” →

Unusual risk analysis techniques

On By James KingIn Risk, Techniques1 Comment

I think risk management is really cool … and certainly more fun than the alternative.

Unfortunately many people find the traditional approaches to analysing risks dry and un-innovative; which is a problem because identification and analysis of risk is actually a creative process.

So here are a couple of “unusual” approaches that might work for your team.  Continue reading “Unusual risk analysis techniques” →

Risks in IT Operations – some analysis tools

On By James KingIn Consulting, Implementation, Risk, TechniquesLeave a comment

Not long ago an airline (Virgin Blue) had a complete meltdown of their ticketing system and just last week a major Australian bank (NAB) had a full on disaster where they couldn’t pay people money they owed for several days.

Both were apparently due to failures in IT operations (IT systems and IT processes) and both must have been dreadful for those involved.

Continue reading “Risks in IT Operations – some analysis tools” →

Risk outrage – look out for falling coconuts

On By James KingIn Implementation, RiskLeave a comment

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?