James King

What you do next matters

Archive for the ‘Risk’ Category

An international standard for being scared?

Posted by James King on November 4, 2011

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.

Posted in Risk | Tagged: , , | 3 Comments »

How to use force field analysis

Posted by James King on July 3, 2011

Force field analysis is a good way to analyse the constraints and the drivers of success when leading change, delivering projects or problem solving in general.

Read the rest of this entry »

Posted in Idea management, Investigation, Risk | Tagged: , | Leave a Comment »

A risk register for lazy project teams

Posted by James King on June 27, 2011

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?

Read the rest of this entry »

Posted in Agile development, Risk, Techniques | Tagged: , | 1 Comment »

Unusual risk analysis techniques

Posted by James King on December 17, 2010

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.  Read the rest of this entry »

Posted in Risk, Techniques | Tagged: , , | Leave a Comment »

Risks in IT Operations – some analysis tools

Posted by James King on December 1, 2010

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.

Read the rest of this entry »

Posted in Consulting, Implementation, Risk, Techniques | Leave a Comment »

Risk outrage – look out for falling coconuts

Posted by James King on November 7, 2010

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?

Posted in Implementation, Risk | Leave a Comment »

Questions for project audits – part two

Posted by James King on July 24, 2010

When auditing a project (or taking over a project or even taking on a senior role in a team) I like to go and talk to everyone in the team.

When I do, I generally ask them the same questions to get a better feel for what is going on.

I really liked a set of questions I picked up from a book called “The First 90 Days”, so I use a modified set of them:

What is your role?

  • What does that mean?
  • How would you explain it to my mother?
  • How would others explain what you do?

How confident are you the project will meet it’s objectives?

  • What are the objectives?  Really?
  • How clear are you on the objectives?
  • What do management think the project is doing?
  • What do others think?
  • If it fails, where will it probably have gone wrong?

What is the biggest issue facing the project?

  • What would happen if we could get rid of that problem?
  • What would need to change to get rid of it?
  • How could we deal with that problem?
  • How is it impacting us/the project?  How does it impact you?
  • How are we currently dealing with it?
  • Why is it still there?  What is stopping us deal with it?
  • What should we do about it now?

What is the biggest unexploited opportunity in the team?

  • What would have to change for us to exploit it?
  • What would happen if we did?

What would you do if you were me?

Most projects are really really complicated.  But most people know how well it is going or how scary it is if they have time to think about it.  So I find you get a pretty good overall understanding if you just ask everybody these questions.

Posted in Investigation, Reflection, Risk | Leave a Comment »

Questions for project audits – part one

Posted by James King on July 24, 2010

I was talking to a colleague recently and promised to share some of the questions I ask when auditing a project (or taking one over).

My first question is generally “what is the project about?” But that generally leads to a vague answer.  So I use my “question compass”:

My question compass

These are the questions I use to get a basic orientation when analyzing just about anything.  By way of explanation though, I don’t always use the exact wording shown.

When asking “what do you mean” I use a technique that sounds really simple and is surprisingly effective – the “nouns and verbs” technique.

I listen for a noun in a sentence and then ask “what do you mean by ‘noun’?”.  When I get a response I ask about one of the verbs in the response “How do people currently ‘verb’?” or “How do you envision people will ‘verb’”.

I keep doing this for a little while even if I think I know what people mean because it is amazing how often it clarifies my understanding.  Then I pick one of the things the person said and ask “why are we doing this project?”.

I do use the famous 5-whys technique to probe more deeply (ie ask why several times) but I also add the question “why else?”.

I was once told that we do things for two reasons – the right reason (the one we tell people) and the real reason.  I think it is a quote from someone famous.  But it certainly clarifies my thinking when I ask this question.

My next question is “Is that true?” and I ask this one in a number of ways:

  • What would the team say the purpose is if I asked them?
  • Do all the steering committee share the same understanding?
  • How do you know that is true?  How do others know?
  • How would you know if that was not the case? (my favourite question).

Almost there – but I still have one last question – “So what?”.  Like asking if something is true, asking so what can seem a bit blunt.  So I ask it in a couple of different ways:

  • What impact is that having?
  • What would happen if we didn’t do it?
  • What would the impact be over the long term if we don’t do it?
  • What will happen if we do it?  What else will happen? What won’t happen?
  • What are you hoping won’t happen if we do that?
  • What will the team/customer say when it happens?

After these questions I generally at least have some idea of what is going on – which is often the best place to start.

Posted in Investigation, Leading change, Measurement, Reflection, Risk | Leave a Comment »

Finally launched my agile training game

Posted by James King on April 5, 2010

We set up a stand at the recent Software Development Conference to run the Agile Release Planning Game I designed.

It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.

In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing.  They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.

Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research.  In doing so they must make trade-offs between quality and velocity.

The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.

The game is designed to be led by a facilitator, but can be run without one.  The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.

Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.

In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.

Let me know if you are interested in learning more, or even trying the game for yourself.

Posted in Capability growth, Decisions, Events, Games, Products, Risk | 6 Comments »

Estimating the cost impact of risks

Posted by James King on September 21, 2009

We all know that managing risk is important.  In fact, Graham Downes recently suggested (in a comment on this blog) that the best way to stop eager young project managers from being “blown up” is  to teach them to better manage risk.

But even when they manage risk actively, I see a lot of teams rating the cost of a risk blowing up on them as “TBA” (ie – to  be advised … ie we don’t know).

Some projects even end with a whole pile of risks listed as high impact with a dollar impact of TBA.

If this is the case, then possibly it is better to not worry about having a column in the risk register to cover dollar impact. Instead, focus on making the impact relevant and real to the team.

I do like to rate the dollar impact of my risks and like other people I often don’t have the time to assess the dollar impact of every risk properly. But I do like to rank my risks by dollar impact to have a look at the scariest ones.

So what I do is allocate a cost to the risk on a scale of really bad to really trivial.  I do this as follows:

  • Decide on what would represent a huge cost in the context of the project, one that makes it worth canning the whole project.  I often do this by simply doubling the budget of the project.
  • Assign this dollar value as “category A”.  So for example if $10m is a really scary figure for the project, then “A” means “any risk whose impact could have an impact of over $10m”.
  • Then assign category B, category C and so on to smaller numbers so that you have a scale with wide ranges for each letter.  It might look like this – A = greater than $10m; B = $2m – $10m; C= $500K – $2m; D=$100k – $500K; E= $20K – $100K; F= $5K – $20K and so on.
  • Eventually you will get to amounts that are small enough to agree not to worry about them as risks.

The trick is to have broad ranges so that it is easy to guess where a risk should fit. The mathmatically pure among you may notice that a risk could fall into category A and B if it is exactly $2m. I claim this doesn’t matter and that you should in this case assign it to the higher category.

Adding a scale for risks allows the team to assign a (very) rough dollar value without too much analysis, yet allows you to categorise risks as really scary or not so bad.

This, I think, makes it easier to deal with the bulk of the risks.  Of course you can still assess the dollar impact of certain risks in more detail if appropriate.

Posted in Risk, Techniques | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 94 other followers