As we all know – projects fail at a regular rate. Particularly software projects. Gary Klein has referred to doing a thorough review of a project before it actually commences by visualising that it has finished in outright failure – something he labels a pre-mortem.
We all do post mortems on projects – particularly ones that flame out spectacularly and where one often is seeking to…. as the old adage goes: ‘to reward the guilty and punish the innocent.’ So this is an innovative suggestion to think about what could go wrong with the project before it even commences.
The suggestion for a pre-mortem from Deborah J. Mitchell (et al.) of Wharton School of Business is to imagine that the project has already occurred, and to detail the reasons for failure. This is said to help improve the identification of risks ‘by 30%’. I do wonder about the precision quoted here, but nonetheless, the concept is good.
What team members are expected to do at a pre-mortem session is to imagine the project has been concluded, and there have been multiple sources of failure. The idea then is to identify what these failures are.
How do we do it?
It is relatively simple. The project team is gathered together, and an action-packed summary is given of the overall project – particularly resources required, critical elements, and outcomes desired with timelines clearly defined.
The Project Manager then asks everyone to visualise that we have concluded the project but that it has failed spectacularly. She then requests everyone to write down independently what the reasons for failure are (in an anonymous manner). They are to be as imaginative as possible in their thinking. Nothing is too far-fetched to consider. All the reasons are then read out by the project manager and discussed by the team. Hopefully, a series of action points are then taken as a result of this meeting.
Typical examples of Successful Pre-mortems
A list of a few interesting ones include:
The construction of a power station in a remote area was considered where potential failure was attributed to the main contractor going bust due to miscalculating the construction delays due to the impending rainy season. This assessment then resulted in safeguards being put in place to protect the client from the financial failure of the contractor. On the real project, this almost happened but the additional financial safeguards protected the client.
The impending construction of an iron plant was considered for the situation where the valuable electronics of the variable speed drives were damaged by an unexpected voltage spike through the system. Additional safeguards with surge protection were put in place on the project at significant additional cost. On the real project, there was indeed a voltage spike due to the installation of power factor correction equipment unconnected to the project. The sensitive electronic equipment was protected.
Finally, consideration was given to a large industrial PLC programming project for a control system as to the loss of some of the key programmers halfway through the project. Additional support programmers were put in place to critique the code. And, one of the key architects of the programming did get seriously ill. This protected the programming schedule.
What are the benefits of this pre-assessment process?
Besides the apparent major benefit of avoiding a project failure, other benefits include team members feeling valued no matter how outlandish their opinions are. It also fine tunes the antennae of team members to look out for potential problems and to be pro-active about dealing with them. Along with my usual mantra of 'When there is any doubt, there is no doubt.'
Thanks to Gary Klein for a thought-provoking discussion in Harvard Business Review.
Winston Churchill makes a brilliant remark relating to pre-mortems: "Let our advance worrying become advance thinking and planning."
Yours in engineering learning