“Why didn’t you speak up about that, at the time? This project has turned into a disaster.”
Having spent a good chunk of my professional life in the project world, I’ve both asked that question, and, sigh, been the one having to answer that question.
Projects fail, often, if not at a spectacular rate. One big reason is that too many people are reluctant, fearful even, to ‘speak up’ with their concerns; team chemistry is suspect. The need to speak up is especially important during the project planning phase. By making it safe for people who are knowledgeable about the proposed project, and worried about its weaknesses, to speak up, you help avoid a false start to the project.
Like most important things in life, a good start goes a long way.
There may no better technique to get your project team on the same page, avoid a false start, and improve the odds for project success, than a premortem (aka pre-mortem) analysis.
Premortem
Premortem is the brainchild of psychologist Gary Klein. He outlines it in his 2007 Harvard Business Review article.
“A premortem is the hypothetical opposite of a postmortem. A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient. 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 premortem works on ‘prospective hindsight’. By imagining failure in advance – by thinking backwards, through to what might cause a false start – you can anticipate some of the potential problems and avoid them once the actual project begins. “Research shows that just imagining that an event has already occurred increases the ability to correctly identify reasons for future outcomes by 30%.”
A premortem is not your traditional project risk assessment. It’s better. (I explain how that is, later in this post).
Applying a premortem analysis to an agile software development team and project
Scenario
[The following scenario involves a software development project team (I’ve been part of many). Agile refers to the Agile approach to software development. Among other things, the agile approach emphasizes: interpersonal interactions and relationships, collaborating closely with the customer throughout the project life cycle, and responding to change over (rigidly) following a plan. That all sounds good, right? That said, agile projects result in their share of failures.]
You have been assigned to an agile project team, to develop a new function and module for an important customer. This is the first time the team has worked together. Team members don’t know each other very well. The team leader has asked you participate in a premortem analysis. The leader starts off by asking the team,
“Assume its nine months from now and our project is a complete disaster. What went wrong?”
Analysis
Applying the power of prospective hindsight, and a simple premortem lens of: 1) asking what happened (i.e. what failed), 2) what insights do we have as to why it happened, and 3) converting the insight into tangible actions (insights are intentions; actions/behaviours bring good thoughts to life), here is the team’s prospective, premortem, analysis:
Fail #1: Fear of “speaking up”
- (Looking back) What happened: To avoid not being seen as a “team player”, people didn’t offer up their thinking or evidence, and pretended to agree (even if they didn’t), when decisions were being made. As a result, poor decisions were made, leading to extra development iterations and project delays
- Insight: We need to “speak up” when we disagree with decisions being made
- (Proposed) Action: At the beginning of the project, the whole team participated in a “speaking up” workshop; focused on building dialogue skills, psychological safety, and routines that provide opportunities for safely “speaking up”.
Fail #2: Breakdown in communication with customer
- (Looking back) What happened: We started off strong, working with the customer. We involved them in all our decision-making. However, as development proceeded, the problems became more detailed and complex. Keeping the customer in the loop seemed to fall off the end of our desks. By the end of the project, the customer felt blindsided by the end product, and refused to accept our work. “It’s not at all what I was expecting to get.”
- Insight: We need to involve the customer throughout, even when the going gets tough.
- (Proposed) Action: Right from the get-go, we scheduled the customer into our weekly team meeting. More than that, we put them on the agenda, of every meeting; provide them a forum to: observe and listen, ask questions, and provide input.
Fail #3: Lack of trust between team members
- (Looking back) What happened: We were a new team. It was our first time, working together. Building interpersonal rapport and trust was a challenge. We didn’t socialize. We never got to really know each other. As the project unfolded and deliverable deadlines loomed, tensions between us began to manifest themselves in destructive ways. At one point, we had to involve HR, and a team member was replaced, at great expense, both project wise, and relationship-wise.
- Insight: Building team rapport is essential for project success.
- (Proposed) Action: At one of our first meetings as a team, we spent the entire meeting in group conversation answering the question, “How do we want to work together?” From that we identified ‘getting to know each other’ as integral to our success, and incorporated regular team building interactions, both formal and informal ones, into our project schedule.
A premortem is different from your traditional risk analysis
Now, other project veterans might argue that a premortem is nothing but a new name for something that’s been around for, like forever, the risk analysis. Not so. As an experienced business analyst (including twenty years as a business analyst in the infotech consulting field), I believe a premortem analysis offers a more authentic take on project risks. Here’s why:
- Starting with the assumption that something went terribly wrong, and analyzing the situation through backward linkages, is a system thinking approach to managing risk. It will help you better understand potential problems, through the connections and relationships, and how they effect the overall outcomes of the project.
- Starting with a premortem, the premise that the project failed, removes a lot of bias; e.g., optimism bias and confirmation bias. Whereas an initial risk assessment might say something like, “We have a big risk of (insert risk here), but we’ve taken the following steps to deal with that risk.” A premortem analysis offers a more honest assessment, “The steps we would normally propose to mitigate that risk are totally inadequate, because….”
- By working from a position where the project has totally failed, you (team member) will be more inclined to enthusiastically, freely, put forward ideas as to why that failure happened. Conducting a premortem is more open and creative than putting together a risk matrix (a common deliverable associated with risk analysis), where one often feels like they are just ticking off boxes, and offering only generalized problems and solutions.
For more about premortems, and other imaginative techniques, I suggest checking out Bryce Hoffman’s book, Red Teaming. In When: The Scientific Secrets of Perfect Timing, author Daniel Pink details the premortem he did before writing that book. Liberating Structures offers up related working-backward techniques (e.g., Nine Whys). Going way back in time, learn from the world of the ancient stoics, who “saw negative visualization as the most powerful technique in their psychological toolkit”, as A Guide To The Good Life.
How about you?
Have you undertaken a premortem analysis for a project? Did it save your bacon?
Speak Your Mind