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.

You begin by writing your objective on the top of a sheet of paper and then putting a long line under it:

Next, draw a line down the middle of the page. The line is called the “force field” and it represents the current equilibrium or the current state of the world.

The idea of the force field is that:

• Some things will push it across the page to the right, or closer to complete success. This are called the “enablers”; while
• Other things will constrain the line from moving to the right (toward success) or will even push it back to the left (failure and despair). These are called the constraints.

Next, write down everything you can think of in both the enabler and constraint columns. You can do this on your own but it works even better if you have a group to brainstorm with.

For example, if “executive support” is needed for success you would write that down in the left of the column. If “Inadequate training” is a risk or a current constraint then write it down in the right hand column.

You will probably notice that if you put something in one column you can just write “no that thing” in the other one – so if “insufficient training” is a constraint, then you could write “adequate training” in as an enabler. So you can just put the current situation in, or you can duplicate your ideas if you like.

Once you run out of energy brainstorming ideas then it is time to begin the analysis.

I usually do the following steps:

Assess the current state:

• For each enabler, how confident am I that it is happening and will continue to happen?
  • If it is not in place, how can I create or encourage it?
  • If it is in place, how can I protect it or increase it?
• For each constraint, how much is it currently impacting me?
  • If it is not in place, what could cause it to happen? How can I stop or mitigate it?
  • If it is in place, what can I do to manage it or minimise its impact?

Look for risks and potential opportunities

• What is the risk of losing one of the enablers? What would happen if I did lose it?
• What would happen if I could remove one of the constraints? Would that help or is another constraint going to mean I am no better off?
• Which constraints are real and which could be removed easily?
• Which enablers are promised but are not likely to have a real impact?
• Are there exceptions to the way the enablers and constraints I have listed? What are they?

Look for the biggest opportunity

• Which constraint is the primary or most significant one? What would happen if it did not exist? What could we then do?
• What factors or forces that are not in place could be become real enablers if we could create or access them? How can we bring them into play?

Look for enablers and constraints that might jump the fence

• How could each enabler become a constraint?
• For example executive support is a good thing, but is it also acting as a constraint? If it is not doing so yet, are there circumstances where it might.
• Will the presence of the executive mean that the project is likely to focus on the wins for his area of the business instead of real value; or could it make it more likely that team members will try to impress the executive rather than solve the problem?
• Are we over-using an enabler to make up for (“accommodate”) an issue that should be resolved. For example the need for exec support might be caused in part by poor communications between business divisions at a more junior level.
• How can some of the constraints become enablers?
• The lack of training means we have to train our staff, so maybe we can involve some clients and vendors in the training to share views, learn to work together and even standardise approaches.
• If a constraint impacts our competitors then we could gain an advantage by managing it better than others do.
• Or if a constraint limits our opportunities then maybe we can really focus on the ones that we can do well. If we can only do small batches of work compared to our competitors then maybe we could do some special runs around the holidays with modified packaging.

Add salt to taste

That’s all there is to it really. You can do it in a workshop or use it to get your own thoughts together after a series of interviews.

You might be able to see how I use it in some different situations in these articles on using the 7-S or Arenas of Change frameworks to assess a team’s readiness for change.

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?

What sometimes helps is a minimalist version of a risk register that the team can use as part of their existing workload ragther than as a separate activity.

Assuming the team have some kind of regular planning meeting (sprint planning, iteration planning, production support team meeting or something), then they can sneak a discussion of risks into those meetings.

But risks generally eventuate, mature or even fade away between meetings rather than waiting for a meeting to change their status.

Just as dangerously, risks often hide themselves among un-verified assumptions and uncommunicated decisions.

So I am hoping that this risk register will help those teams that are on projects too small or relaxed to do hard core risk identification, analysis, assessment and treatment.

All the team needs to do is

1. Find a spot on the wall.
2. Draw a table on the wall to capture the risks and similar concerns
• Enter anything they think they should worry about (risks, open issues, new questions or potential concerns). The best approach is to use post-it notes so you can move them easily and gravity can make some disappear (er .. that is to say the best approach is to use cards that can be moved but won’t fall off the wall).
• When a risk or issue is closed the team move it to the second row of the table – the “done” row.
3. Next the team add a table for decisions and assumptions that are made during the week.
• When a decision is made that others might need to know about, add it to the first column of the table.  Then put N/A in the second column if the decision does not have to be validated or communicated to someone else. Or put the person/group with whom the decision should be validated.
• If you or one of the team need to make an assumption during the week as part of the work you are doing, add it to the register in the same way that you enter decisions.
• If and when a decision or assumption is validated then put a tick next to it or draw a line through it.
4. Go through the register as a team when you have your meetings and confirm that everyone knows what risks, issues, decisions etc were added or moved during the week.

You might decide do a whole lot more to manage risks on your projects. Whether or not you do though, you might like to consider this humble register as a lazy (or low maintenance) way to maintain a focus on risks without incurring a lot of overhead.

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. 

The (risk) story telling competition

The story telling competition is a light and breezy version of scenario planning – a common strategy setting process as well as a risk management one.

Firstly break the group into small teams of 2-4 people.  Then:

1. Define the solution space (ie let the team know what system, organisation or “thing” you are analysing).
2. Have the group talk freely for five minutes about the “thing” so they have a feel for what they are analysing and what sort of risks might exist.
3. After the five minutes is up, ask each group to come up with a short story where a character (the hero of the story) is impacted by a risk being realised.  For example the story might be about Mary from the call centre getting a call to say the system is down and then finds that things are worse than expected. This should take 10-15 minutes.
4. Have each group pair up with another group and share their stories.  Then have them create a combined story where both incidents occurred.  Allow another 15 minutes for story telling and combining stories, so there is not too much time to get off-track.
5. Have each group present their story to the whole team, or if you prefer have them write it up and post it on the wall in sketch form and then allow the team to browse through the stories.
6. (Optionally) Get the team to vote for which story is the best on the basis of
   • Scariness;
   • Unexpected-ness; and
   • Likelihood of actually occurring at some point.
7. Now get people to go back to smaller groups and answer the following questions on their stories:
   • How was the issue or problem discovered?  How else could it have been found out?  How could it have been predicted or found earlier?
   • What caused the incident to occur (ie what was the trigger for the risk)? What caused this trigger to happen?
   • What could have been done to make the incident less bad? What could have made the incident Less likely?
   • IF the incident didn’t occur the way it happened in the story, what else might have happened that was similar?
8. Finally, have each group discuss and report back on the most important question – What can we do in the real world to manage this risk?

The competition could theoretically be run over several days but I have only run it in a workshop.

The evil genius

Positive thinking is thought to improve creativity. But in risk analysis people often use negative thinking (“what should we not do?”, “what is wrong with this plan?”).

So the evil genius workshop is designed to allow the team to think in positive terms about how to destroy their project, process or system.

To run this workshop:

1. Tell the team that they are working for the evil wizard who is responsible for sabotaging well meaning projects around here. If they doubt there is such a genius, ask them how if things always seem to go wrong at the worst possible time, in the worst way.  Then tell them that this requires careful planning and execution … as well as a real talent for evil and chaos.
2. Break groups into small teams (2-7) of “evil consulting teams”.
3. Have each team brainstorm possible ways that we could sabotage the project using any or all of:
   • The services of Lord Murphy who can make sure bad luck occurs at the worst time;
   • The wand of miscommunication to ensure people are working at cross-purposes when they really need to be working together.
   • Any evil minions or other dodgy techniques they can think of.
4. Have the group then brainstorm ways that they could enhance the chaos they are unleashing or protect their evil plans from discovery and mitigation.
5. Have each team write their suggestions on post-it notes and then explain them as they up them up on the wall.  Optionally, you can ask them to record suggestions in the format (what could we have go wrong; why is this bad; what could we trigger to make it happen and what could we do to make it worse).
6. Once all teams have completed their reports, ask the wider group to group the suggestions together however they see fit (resist the urge to classify them methodically and allow people to keep moving post-it notes around until they settle.
7. Optionally, have people vote on the 3-7 scariest or “most vulnerable” suggestions.
8. Finally, ask people to go back to their original groups and have them select some “suggestions” to work on (not necessarily their own).  At this point they stop working for the evil genius and instead review how the team could anticipate, mitigate and manage each risk.

I find these techniques work really well with some teams and not so well with others. So let me know how you go if you try them out.

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

I sometimes run risk management workshops and I have a number of approaches to help your team assess and manage the risks they face. 

At the most basic level we create a risk register in line with Australian and international risk standards.  This seems straight forward yet many project and IT managers miss some of the risk basics like triggers (the warning sign that a risk is materialising or becoming more likely).

Less often, but just as valuable I work with managers on how to better communicate risks, both to manage them when they are risks or prepare a communication plan to deal more effectively with stakeholders during a crisis. 

Most often I run workshops on how to identify and analyse the risks the team faces.

So I would love to come and help you better understand, communicate and manage your risks, particularly over January and February where I traditionally have a light workload.

But if you want to do it yourself, here are some of my favourite tools.  Rather than fully explain them I thought I would quickly show you some and then attach a long case study from a university assignment I did a long time ago.  If you are mildly interested, then enjoy the diagrams and if you are more interested then grab a coffee or tea and then read through the case study.  I hope you will find that the tools are quite useful on their own or as a set.

Step one in risk management is to understand the context within which risks exist.  I don’t have any examples here, but always start with a general understanding.

Then, identify what could go wrong.  I often use FMEA (Failure Mode and Effect Analysis) for processes – it sounds like fun but it is really just a set of questions (What could go wrong? What would cause that to happen?, How/when would we find out? How could we find out sooner? What would we do? How could we avoid it?).

But for meaty problems like IT system failure, the failure of a key process (such as software releases) and so forth it is better to do a workshop or some analysis using a fault tree.

A fault tree simply breaks down a risk to show what could cause it.  But the real power is that is includes the words “and” and “or”.  So you can represent “this could be caused by a backup failure and either a failure to test the back up or a crash before the next test”.

Once you have a giant list of causes then you want to go through the impacts.  People often just list one impact or label the impact “high, medium or low”, but in fact there can often be a range of impacts from trivial to catastrophic.  So a good way to workshop and represent this is to show the potential impacts in an event tree:

This helps the team prepare for the scary scenarios and also for the less scare (often more common) ones.

Finally we want to look at the controls and barriers that protect us from the risk and the actions we would take to detect and mitigate the problem if it does materialise.

This is particularly important because people often over-protect themselves from one part of the risk but fail to notice that they are heavily exposed to another cause, or they have no plan for a particular outcome.

The over all causes, barriers, mitigations and outcomes can then be displayed in a bow tie (or butterfly) diagram:

So there you have it – a vague structure to run a workshop or do some analysis and some cool (I think) ways to capture and display the information you generate.

Please call me if you would like my help, either running some of these workshops or coaching your crew in how to do it.  But also feel free to read through the attached case study if you would like to work out how to do it yourself.

Case study:

James King Randomcorp case study on risk management

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?

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.

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.

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.

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.