According to research by PMI – only 57% of projects are finished in budget and 52% finished on time.  15% of projects are deemed as a total failure – that is a project disaster.

The risk of project disaster goes up for projects executed over a long timeframe or with higher-than-average complexity.  Supply chain projects often fall into this category.

When a real disaster strikes, there is usually extensive investigation of the causes behind the tragedy.  The public demands that it must never happen again; lessons must be learnt.  Over time, those lessons come to be better understood and can be applied in new contexts.

The Challenger Space Shuttle tragedy is one case-study of a failure in organisational decision-making.  It has valuable lessons – both for lawyers and managers who need to consider legal and other types of risk in their supply chain projects.

In this article, I look at some causes of the Challenger disaster, and the lessons for managers working on a supply chain project.  Then, I talk about the Project Pre-Mortem technique, which I’ve previously used at the start of supply chain projects to reduce the risk of these types of problem.

The Challenger Space Shuttle disaster

On 28 January 1986, just 73 seconds after lift-off, the space shuttle Challenger tragically exploded over Florida’s Cape Canaveral.  All seven crew members were killed.  By that time, space shuttle missions had become a frequent occurrence for NASA.  However, public and media attention for this mission was particularly high.  The Challenger was due to carry the first civilian into space: a teacher, Christa McAuliffe.  The iconic image of the exploding shuttle came to haunt an American generation. The tragedy set back the NASA space program many years.

The technical cause of the Challenger disaster was later identified as a failure of an “o-ring”.  This was a rubber seal connecting segments of the huge rocket which launched the shuttle into space.  The rocket booster had been manufactured by a contractor, Morton Thiokol.

The night before launch, Morton Thiokol held a conference call with NASA.  The launch had previously been delayed on several occasions.  NASA was now under enormous pressure to launch.  During the tense conference call, the specific issue of the o-ring was discussed.  In particular, the weather forecast for launch was for a cold day.  The predicted temperatures were to be lower than the limit at which the behaviour of the o-ring’s rubber material could be accurately predicted.  As a result, several Morton Thiokol engineers refused to give the sign-off that was necessary for launch.

NASA indicated its lack of patience for any further delay to the launch date.  The risk of o-ring failure was not a new issue.  It had been raised before.  However, previous launches had been successful and the risk had come to be accepted.  For this launch, NASA put the engineers in a difficult position. They would have to prove that the o-ring would definitely fail, not just that there was a risk that it might.  The engineers were unable to do so.  NASA notoriously then asked Robert Lund, Morton Thiokol’s vice-president of engineering, to “take off your engineering hat and put on your management hat”.

Over-ruling the advice of his engineering team, Lund relented. Morton Thiokol agreed to the launch.

The ultimate tragedy, therefore, was that the technical failure that killed the crew had been identified as a risk and discussed just the night before.

What went wrong?

Studies of the decision-making process that led to this tragedy focus on the problems of go-fever (also known as launch fever) and groupthink.  Go-fever is a term used to describe situations where the desire or pressure to get on with a project or deal comes at the expense of overlooking potential problems. Likewise, “groupthink” is a related phenomenon. Groups often reach bad or irrational decisions, due to the very human, subconscious desire to maintain harmony and to avoid conflict amongst group members.

We can see immediately how these phenomena might be relevant for managers dealing with legal, contract and other risks on a supply chain project.  Legal advice on a project or transaction frequently identifies risks.  However, for some projects, particularly where the stakes are high, where planning is at an advanced stage, or where legal advice has been obtained late, there can be strong momentum for “launch”.  At this point, launch fever may hinder objective assessment of the legal risk.  Like the Morton Thiokol engineers, the manager might not be able to prove that a legal risk will eventuate. Similarly, the risk may have been accepted on previous projects without any adverse consequence.  This does not mean the risk has gone away.  Unfortunately, a poor, or risky, decision can soon become an inevitable conclusion.

The problem of groupthink is sometimes wrapped up with another common criticism of lawyers.  This is that lawyers are “uncommercial”.  They “see risks everywhere” and that those risks are “just theoretical”.  If it was up to the lawyers, “nothing would ever get done”.  When confronted with this viewpoint, there is a challenge for lawyers in getting the balance right.  On the one hand, the lawyer has a duty to identify the risks and to raise these with the client. On the other, risks need to be presented in a way that makes it more likely that the advice will not be dismissed by the group.  To influence a better, more informed decision, the lawyer needs to be sensitive to the group’s dynamics and attitude to risk.

By being able to identify the legal risk, whilst also being aware of the organisational risk that comes from the decision-making process, a lawyer can become better placed to add value to their organisation’s decision-making processes.

The “Project Pre-mortem”

For teams working on a supply chain project, there is a great technique that can be used to overcome these problems and which I have successfully used before.  This is the idea of a “project pre-mortem”*.

According to good project management practice, projects should end with a post-mortem, or de-brief, to investigate what did not work.  The group asks itself: what could be done better next time?  The problem is that, by this time, the project has already been completed.  It is too late.  The project has not been as successful as it could have been.  In addition, more significant projects occur less frequently, or may involve different personnel.  By the time another similar project starts, lessons from the last de-brief may have evaporated.

Similarly, many projects may start with a risk analysis.  A risk analysis can suffer from the same problems that led to the Challenger disaster, especially:

• Over-confidence, due to the desire to be seen as decisive.
• Employees defer to the “experience” of the group, or more senior managers. They fear that, if nobody else is raising the problem, then perhaps their concern does not have merit – the groupthink problem.
• Those outside the immediate team not wanting to be seen as being negative about a popular initiative.  For example, this is the same problem as a lawyer risking being seen as “uncommercial” for identifying “theoretical” risks.

The “pre-mortem” approach is different.  At the very outset, the lawyer, or project leader, asks all members of the group to imagine the future.  The project has already ended.  It has been a spectacular failure, a disaster.  The team is asked to spend a few minutes, individually, writing down as many reasons as possible as to what they think caused that failure.

The value of this approach is that, by already imagining the project has failed, no individual has to challenge the team’s groupthink.  Instead, the onus is reversed. It becomes part of the team’s challenge to identify as many causes of failure as possible.  By suggesting possible risks, or causes of failure, each team member is now making a positive contribution to the group’s work, not challenging it.  Each team member also brings their unique skill set and experience to the problem.

The team’s list of risks can then be incorporated into planning the project. The team can develop strategies to minimise, or mitigate, the risks of failure.  Ultimately these could save the project, and even the organisation, from disaster.

Notes:

* The idea of a Project Pre-mortem is not new. It comes from the work of a research psychologist, Gary Klein (see, for example, Klein, G. (2007). “Performing a Project Premortem”. Harvard Business Review 85 (9): 18–19