One of the biggest challenges for any decision-making team is to overcome the danger of group-think and the strong possibility of a failure to examine all dimensions of the issue. A combination of cognitive biases, personal prejudices, and group dynamics conspire to obscure certain critical aspects of the project. This results in incomplete project implementation plans, whose fault-lines get revealed when faced with unanticipated obstacles.
How do we overcome such blind-spots? How can project teams locate weaknesses in their implementation plans? Gary Klein advocates the use of pre-mortems, wherein the possible failure channels in any project plan can be identified through prospective hindsight. It is based on a 1989 research work by Deborah J. Mitchell, Jay Russo, and Nancy Pennington, who found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%. He writes,
"A premortem is the hypothetical opposite of a postmortem... A premortem in a business setting comes at the beginning of a project rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the "patient" has died, and so asks what did go wrong. The team members' task is to generate plausible reasons for the project’s failure.
A typical premortem begins after the team has been briefed on the plan. The leader starts the exercise by informing everyone that the project has failed spectacularly. Over the next few minutes those in the room independently write down every reason they can think of for the failure — especially the kinds of things they ordinarily wouldn’t mention as potential problems, for fear of being impolitic...
Next the leader asks each team member, starting with the project manager, to read one reason from his or her list; everyone states a different reason until all have been recorded. After the session is over, the project manager reviews the list, looking for ways to strengthen the plan."
The effectiveness of pre-mortem lies in its clever use of framing effect. The team members are primed by telling them that the "project has failed". Their prospective hindsight analysis is based on this failure assumption. This frees them up from their cognitive shackles that restrained the team members from giving full vent to all their apprehensions while doing the project conceptualization brain storming.
Given the aforementioned dynamics of pre-mortems, its effectiveness is critically dependent on the most appropriate technique of framing. In simple terms, how do convey the "project failure" message in a manner that cognitively detaches and transports team members from their present ex-ante analysis role to one that enables prospective hindsight?
Pre-mortem, if effectively executed, is an obviously powerful tool to strengthen project implementation plans in both private and public sectors. In fact, I am inclined to believe that it is likely to be even more effective in public bureaucracies where ex-ante analysis is always held back by strong currents of political correctness and bureaucratic hierarchy norms. Pre-mortems on effectively primed (about the program failure) team members has the potential to yield remarkable results.
Here is the chronology of a pre-mortem
Step 1: Preparation. Team members take out sheets of paper and get relaxed in their chairs. They should already be familiar with the plan, or else have the plan described to them so they can understand what is supposed to be happening.
Step 2: Imagine a fiasco. When I conduct the Pre-Mortem, I say I am looking into a crystal ball and, oh no, I am seeing that the project has failed. It isn’t a simple failure either. It is a total, embarrassing, devastating failure. The people on the team are no longer talking to each other. Our company is not talking to the sponsors. Things have gone as wrong as they could. However, we could only afford an inexpensive model of the crystal ball so we cannot make out the reason for the failure. Then I ask, "What could have caused this?"
Step 3: Generate reasons for failure. The people on the team spend the next three minuted writing down all the reasons why they believe the failure occurred. Here is where intuitions of the team members come into play. Each person has a different set of experiences, a different set of scars, and a different mental model to bring to this task. You want to see what the collective knowledge in the room can produce.
Step 4: Consolidate the lists. When each member of the group is done writing, the facilitator goes around the room, asking each person to state one item from his or her list. Each item is recorded in a whiteboard. This process continues until every member of the group has revealed every item on their list. By the end of this step, you should have a comprehensive list of the group’s concerns with the plan as hand.
Step 5: Revisit the plan. The team can address the two or three items of greatest concern, and then schedule another meeting to discuss ideas for avoiding or minimising other problems.
Step 6: Periodically review the list. Some project leaders take out the list every the list every three to four months to keep the spectre of failure fresh, and re-sensitise the team to the problems that may be emerging.
No comments:
Post a Comment