Back to the Future Risk Analysis

Back to the future risk analysis

Take advantage of twenty-twenty hindsight when it’s most needed — at the start of the project!

The way to get a retrospective view at the beginning of the project is to use Gary Klein‘s risk analysis technique, the project premortem. This is a meeting before project execution starts. The attendees of the meeting are asked to imagine the project has failed and to give the reasons why. In this exercise the participants use the same perspective that is used for events in the past to look at a future event.

The premortem is based on research published in 1989 by Deborah J. Mitchell (The Wharton School), J. Edward Russo (Cornell University), and Nancy Pennington (University of Colorado). The study looked at why moving forward in time changes the explanations given for events.

There was earlier research showing that longer descriptions, with more detail, are given for past events. This was also true when looking at future events as if they were in the past. These studies had used scenarios where a forward (future) view always had uncertain outcomes and the backward view always had sure outcomes.

Other research had shown similar effects when certainty of the outcome was the variable. People act differently when the result is a certain, even if it is unknown. For example, people will bet less on a roll of the dice if they have been thrown and the result hidden. They are more willing to make a bigger bet before they have been thrown.

The researchers wanted to know why they were getting longer and more detailed descriptions because it could help people in making better decisions. This led them to set up two experiments and they were able to show that it is the certainty of the outcome that affects the explanations.

When you are uncertain of the outcome, your mind will try to predict what will happen. When you know what will happen, like when looking at the past, you will look at reasons why things turned out as they did. “Why” explanations have context; the who, what, where and when of the event makes the descriptions longer and more detailed.

In projects we also have to deal with organizational and group dynamics. As Daniel Kahnemann points out in “Thinking, Fast and Slow“, people avoid publicly expressing doubts about a project endorsed by management because their loyalty could be questioned. Using a scenario where the project has already failed takes away the stigma of being doubter and allows more risks to be exposed.

Putting it all together, we now have the protocol to use for the premortem:

  • We change the team’s perspective by making the result certain. We get better explanations because we are not predicting possible outcomes.
  • We assume that things went wrong to find why things could go wrong. Nobody is putting themselves in the position of predicting failure because it is already assumed.
  • We ask why to find the causes of risks to the project. The reasons why things could go wrong are not hidden because no one is trying to shift blame.

One of the keys to a good risk analysis is identifying as many of the project risks as possible. The project premortem makes the team look at why things can go wrong instead of simply looking at what could go wrong. It allows the team to bring up doubts that are sometimes held back. It’s Monday morning quarterbacking on Saturday.

Related:
Performing a Project PremortemPerforming a Project Premortem by Gary Klein (hbr.org)
Pre-mortem — Wikipedia article on pre-portem (wikipedia.org)
Back to the future — Study by Deborah J. Mitchell, J. Edward Russo and Nancy Pennington (wiley.com)

Critical Path and Critical Deliverables

Critical path scheduleThe Critical Path is a mathematical analysis that identifying the sequence of activities that add up to the longest overall duration. In other words, this is the quickest the project can be done. However, this analysis does not take into consideration the criticality of the deliverables. It only identifies the longest (duration) sequence of activities, regardless of their importance.

Do not focus only on the critical path when you are evaluating which deliverables to watch closely. Also focus on your critical deliverables. A critical deliverable is a deliverable with a lot of risk, either by the impact, its likelihood or a combination of both. Some of these may or may not be on the critical path yet they may be more important for staying on schedule.

For example, a software project has the online help system as a part of the critical path. Nevertheless, the project can survive a late delivery of the online help system. This same project has the installation of a Server as deliverable with a large float associated with it. It is not on the critical path, yet if the server is not ready in time, the effect to the project is very high. It is sensible to make extra efforts to make sure that there are no delays to the Server.

This is risk management and managing risk is not an isolated activity. It is a part of many project activities, including schedule management.

Remember there are other factors to consider when identifying items for which a timely delivery is critical. Remember the critical deliverables.