BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Kick-off Your Transformation by Imagining It Had Failed

Kick-off Your Transformation by Imagining It Had Failed

Bookmarks

Key Takeaways

  • Large scale change initiatives (Lean, Agile, etc.) have a worryingly high failure rate. A chief reason for which is that serious risks are not identified early
  • People knowledgeable about the change initiative and its weaknesses are often reluctant to speak up about any serious misgivings they have, for fear of ruffling feathers or alienating colleagues
  • One way to create the requisite safety for everyone to speak openly about the risks they see – however unpalatable or impolitic they may be – is by running a pre-mortem workshop. Pre-mortems leverage a psychological technique called 'prospective hindsight' – imagining that the transformation had already failed, and walking backwards from there to investigate what led to the failure
  • This technique had already been proven to increases the ability to correctly identify reasons for future outcomes by 30%
  • Facilitate a pre-mortem early in your transformation to maximize the value you gain from the activity and the insights it generates

What is a pre-mortem?

When asked by the editor of the online science and technology magazine Edge.org to share one brilliant but overlooked concept or idea that he believes everyone should know, the Nobel laureate Richard H. Thaler, father of behavioural economics, former president of the American Economic Association and an intellectual giant of our time, did not hesitate. “The Pre-mortem!”, he said.

The idea of the pre-mortem is deceptively simple: before a major decision is made or a large project or initiative is undertaken, those involved in the effort get together to engage in what might seem like an oddly counterintuitive activity: imagining that they’re at some time in the future where the decision/project/initiative has been implemented and the results were a catastrophic failure, then writing a brief history of that failure - we failed, what could possibly be the reason? 

Originally developed by applied psychologist Gary Klein and popularized by Nobel Laureate and best-selling author Daniel Kahneman, the concept of pre-mortem is based on research conducted by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, which found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%. The purpose of the pre-mortem then is to leverage the unique mindset the team is in when engaged in prospective hindsight to identify risks at the outset of a major project or initiative.

How is that different from traditional risk analysis at the beginning of a new project or initiative? Instead of asking what might go wrong, in a pre-mortem we assume that the project has failed, and the question is what did go wrong. The difference might appear subtle, but the change in mindset is actually profound. This illusion of outcome certainty makes it safe for those who are knowledgeable about the initiative and concerned about its weaknesses but reluctant to share to speak up (especially about the types of things that are uncomfortable or awkward to talk about). Also, working backwards from a known outcome (i.e. asking why something did happen rather than why it might happen) is a great way to spur the team’s creativity and imagination. 

            In all the years I’ve been involved in Lean, Agile & DevOps change initiatives in organizations large and small, it always struck me just how overconfident most of these organizations were as they kicked-off massive and almost unfathomably complex transformation initiatives. Never mind research and statistics that show that successful large-scale transformations are the exception not the norm, optimism bias and groupthink reign supreme. Team members and stakeholders with legitimate concerns are often reluctant to share their scepticism for fear of being labelled to have a fixed mindset or to be classified as ‘part of the old-school resistance to the new way of working’. A devil’s advocate is rarely popular, particularly when the excitement of a new change initiative that was promised to transform everything for the better is soaring in the organization. I have found that running a pre-mortem exercise early in a transformation often generates profound insights, without which the transformation could have been seriously derailed or failed altogether.

How to prepare for a pre-mortem

As with any workshop, it is important to prepare well for the pre-mortem. This includes carrying out activities that range from the relatively straightforward, like arranging supplies and room bookings and getting time on people’s calendars, to the more complex, like ensuring that there’s enough shared context to allow everyone to participate and add value.

Here’s a simple check list I use to guide the workshop preparation process:

  • A date and time is set for the workshop, and a big enough meeting/conference room is booked (if face-to-face).
  • Workshop participants are identified and invited. It should come as no surprise that having the right stakeholders in the room is essential to the success of the pre-mortem. In addition to the transformation core team/working group, invite representatives from teams/departments/units etc. that are affected by or will affect the transformation and who are familiar with the initiative

Take your time to explain the purpose and flow of the workshop and the science behind pre-mortems to the people you invite (and expect a few quizzical looks as the concept will sound odd to some upon first hearing it).

  • Those invited have confirmed their attendance or nominated someone to attend on their behalf.
  • The transformation’s ‘elevator pitch’ is shared with the participants. Make sure to share key, high-level information about the transformation, such as a description of the problems it intends to solve, the opportunities that lie in solving them, the scope of the change, etc. with the participants (e.g. as a 1-page Lean Canvas). Even though everyone attending should already be familiar with the overall objectives and initial approach of the transformation, it never hurts to share a high-level description of the what, why and how of the transformation with the team ahead of the pre-mortem to ensure that everyone has a well-rounded view of the challenge at hand.
  • A short session is held with workshop participants to answer questions about the workshop, discuss expectations, etc. 
  • Logistics is sorted out.  Make sure there are enough post-its, glue, sharpies, etc. If the workshop is to be conducted face-to-face, arrange for refreshments and light snacks to be provided during the workshop (no sugar though as it hinders creative work, and this exercise is heavy on creativity).
  • Workshop participants are given their homework. Help the team prepare for the workshop and get into the requisite mindset by asking them to contemplate two questions ahead of the exercise: 
    • how would you define “failure” in the context of this transformation? 
    • imagine that the transformation had failed, and you were asked to write a brief internal memo explaining what happened to people in the organization. What would you write?

How to run a pre-mortem

  1. Present the challenge

“It’s two years from today”, begin by saying. “Despite all our hopes and fervent efforts, the transformation has failed miserably”. Take a pause here, giving that fact time to sink in. “Our purpose today is to learn as much as we can about why we’ve failed, and to share any insights we have gleaned from this experience”. 

  1. Collaboratively develop a definition of failure 

You encouraged the team to imagine that the transformation had failed spectacularly, but what does spectacular failure actually mean? Does it mean that *not all* of the objectives were met? *None* of the objectives were met? Does it mean a grave loss of reputation? Or that the entire organization is set back ten years? Etc. In order to spur the team’s creativity to imagine what could have led to an outcome, you first need to have clarity (and a shared understanding) of that outcome.

As part of workshop prep, you’ve asked the team to contemplate what failure means to them. You can build on that to develop a collaborative definition of failure. I like to use the 1-2-4-ALL liberating structure to facilitate this part:

  • First, each team member silently brainstorms as many failure criteria as they can think of (or reflects on the ideas they already prepared for the workshop), then prioritizes their personal top 3 (could include anything from impact on customer and business value created, to customer satisfaction, employee satisfaction, operational metrics, reputation, market position, etc. – encourage the team to quantify the failure criteria e.g. a n% drop in the organization’s Net Promotor Score)
  • When the timebox expires, team members form pairs, and building on the top 3 failure criteria identified individually, the pair discuss similarities and differences, and come up with the top 3 for the pair
  • Team members then form foursomes (pairs of pairs), share and discuss what they came up with the pairs, notice similarities and differences, and come up with the top 3 failure criteria for the foursome
  • Finally, all team members get together as one group, and each foursome present their failure criteria. Similarities and differences are identified and discussed, and a final definition of failure for the whole team
  1. Write the story of what happened

An effective way to get the team into the right mindset – i.e. to think as if they’re not merely looking into the future but are actually in it – is to have everyone participate in telling the story of the transformation. What did happen? What noteworthy events took place? What were the highs and lows of the transformation? The power of this exercise is that it challenges the team to ‘go deep’ into this prospective hindsight narrative, constructing a plausible chain of events that must logically lead to the outcome (the failure of the transformation). This opens a broader spectrum of potential reasons for failure, further enriching the conversation and providing us with a goldmine of potential insights. 

One way to collaboratively write the story of the transformation is by constructing a timeline.

Ask the team to break into small groups of 3 or 4. Each small group will work to chronologically list significant events that they believe led to the failure of the transformation. The timeline should be divided into meaningful time periods (taking into account how long back we are looking) – e.g. quarterly. 

First, each small group is given a few minutes to deliberate the main elements of the story: who are the stakeholders who played a part in how events transpired? What are some of the significant milestones of the transformation? Here I’d encourage the participants to share the internal memo briefs they prepared (workshop homework) with the rest of their small group as a means of establishing some shared context.

Then, one team member writes the first significant event on a post-it and places it on the leftmost side of the timeline. The team member to their left (or right) picks up the thread, answering the question “then what happened?” by writing another significant event that followed the first one and adding it to the timeline (or they could simply say ‘pass’ and we move to the next person). The team continues in this fashion until we arrive at the end point of the timeline (e.g. present day).  Left-to-right, the timeline should read like a story. Upon walking the timeline, one should be left with the feeling that this is a plausible scenario what could lead to the failure of the transformation.

In essence, this is an exercise in storytelling. Encourage the participants not to shy away from unexpected twists and turns (story twists – e.g. the transformation was going smoothly until an important transformation sponsor resigned unexpectedly – is where you’d find many insights about the things people are uncomfortable to share). 

The breakout groups will then take turns showcasing the timelines they constructed. This is a great opportunity to share mental models and assumptions, as everyone in the team gets a glimpse of how everyone else is thinking.

A representative of each breakout group walks the rest of the team along the timeline they built, clarifying events and explaining critical junctures (twists in the story). The team is encouraged to ask questions about any events/jumps that puzzle or surprise them (or anything that simply stands out). When walking along and examining the timeline, team members are not only seeing the story/narrative that someone else has built but are also trying to connect it to the one that they themselves have built. 

  1. Generate insights

Ask the team to imagine that we’re gathered together to contemplate the lessons we have learned being part of this transformation initiative. It is incredibly safe, there’s no blame or finger-pointing – we just want to share the insights that this initiative has revealed about how we work and the environment and context in which we work.

Ask the team to go back to their breakout groups, and ask each group to answer two questions, inspired by the timeline they have built, the timelines that other groups have built, and the questions, observations and conversation with the rest of the team:

  • What are the top 3 lessons that you’ve learned from this failure? 
  • What are the top 3 assumptions that we made at the beginning of the transformation that turned out to be wrong? 

            It is up to each group to decide how to consolidate and prioritize their ideas so that the top three lessons and assumptions are identified and shared with the wider team. My preference is to use a slightly modified version of the 1-2-4-ALL Liberating Structure: 

  • First, each group member silently brainstorms as many lessons and assumptions as they can think of, then prioritize their personal top 3
  • When the timebox expires, group members form pairs, and building on the top 3 lessons and assumptions identified individually, the pair discuss and come up with the top 3 lessons learned and assumptions for the pair
  • All group members then get together and discuss lessons and assumptions identified within the pairs, and eventually come up with the top 3 lessons and assumptions for the entire sub-group.

Share insights with the wider team

It is now time for each breakout group to share their top 3 lessons and assumptions with the rest of the team. A representative goes through the top 3 lessons learned and assumptions, explaining each lesson/assumption in detail and arguing for why it was deemed such an important learning that it had to be shared with the rest of the team. Specifically, team members are encouraged to elaborate (and ask questions to clarify) the following points:

  • In what way has the learning or assumption impacted the transformation?
  • Why do we think the assumption was made in the first place? What structural/procedural/cultural etc. elements do we believe have led to the failure that taught us the lesson?
  • Shifting back from the future to the present mindset, how can we leverage this insight moving forward to strengthen our plan and ensure that our transformation is successful?

As with showcasing the timelines earlier (and with any discovery work in general), this part of the exercise creates the most value when the thorough and probing questions of the team help expand the problem space – the more we explore (and challenge) those learnings and assumptions as a team, the more we learn. The learning we acquire from this activity takes many shapes: new ideas to experiment with, potential risks we haven’t considered, powerful questions and ‘what is’ scenarios we need to explore further, assumptions some in the team are making that others do not share, deep insights that should influence how we approach the transformation, etc. 

  1. Wrap up

The purpose of this workshop is help those involved in the transformation go beyond the surface to identify serious and complex risks that could jeopardize the entire initiative and to devise mitigation strategies. As discussed above, these risks are gleaned from the insights we gather as we engage in prospective hindsight. The initial transformation plan is updated to reflect the immediate concerns raised during the workshop (what should be kept, changed, sped up, delayed, probed further, etc. as a result of what we uncovered during the pre-mortem?). Throughout the transformation initiative, those risks are re-visited, and mitigation strategies are updated to reflect new realities. 

About the Author

Ayman Idris is an Australia-based Agile transformation consultant, trainer, author, and speaker. He has over a decade of experience helping organizations leverage agility to maximize business value and customer value, while building an environment that nurtures and grows people. He has helped organizations in four continents to adopt Agile ways of working, in sectors spanning healthcare, government, banking, telecom, manufacturing, and high tech. 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT