I recently ran, what was probably a first in South Africa (?) (SA readers please reply if you've seen this implemented in other companies), and definitely a first for the company in question, a project premortem. I had asked around the various stakeholders which included people with decades of working experience, and no-one had known about this concept of "project premortems". Sure, people were familiar with project postmortems (or end-of-project reviews, more recently called "Retrospectives" in agile parlance) but this "premortem" concept was an enigma, as it was to me, before I came across the concept from a book (2014 release) I read earlier this year, Scaling up Excellence
by Robert Sutton & Huggy Rao. Although this book's core messages are around scaling up organisations, a lot of the findings are equally applicable to the context of running large, complex projects. In my world, I manage large technical programs that involves many separate business units, clients & third-parties, with large development teams...The idea is now seeded in the company, people are talking about it, and it was well received by some CEOs, who have started using this concept in their high-level steering meetings (awesome)...
I am a huge fan of Sutton, having first come across his work in Good Boss, Bad Boss: How to Be the Best... and Learn from the Worst
and The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn't
. I also keep up with his blog at work matters, follow him on twitter & listen to podcasts whenever he talks at Stanford's ETL lectures, and he is also my personal connection on LinkedIn.
As a program manager I have run various planning scenario workshops in my time, the classic risk brainstorming sessions, best-worst-case scenarios, etc - but I had never labelled the event as a "project pre-mortem", the name resonates with so many people because of their encounters with the classic project management tool of "project post-mortems". Not only the naming resonated well, the concept and implementation of this activity is in harmony with Management 3.0 concepts and practices of inclusion & transparency in agile practices. I was looking forward to changing tact, to experiment and try this out on a bunch of people (old-timers and youngsters) who are relatively receptive to new ideas and ways-of-working. It wasn't a complete success especially finding time out from a busy project that's already in motion, people came to the workshop a little skeptical, felt out-of-their-comfort zone, but nevertheless respected the process and participated as best as they could.
What's a "premortem" then?
Before I describe my custom implementation of this premortem, quoting Scaling up Excellence, Chapter 8, "Look Back from the Future", pages 264-265:
As highlighted earlier, I help co-ordinate and steer large-scale projects that involve a few teams from different business units (with their own CEOs/CTOs), that must come together to develop a technical platform (set top box) and product/brand features (which is not owned by the engineering team responsible for the STB) and various operational management entities. We have over 150 people working on the project, scattered across the business. The project has been ongoing for a few months already, we've had team-wide or component-wide risk sessions, retrospectives and work was well underway. With an imminent release ahead of us, I wanted to hold this premortem with the primary focus of surfacing any issues / concerns that have either fell through the cracks, or swept under the carpet (which is often the case), ensuring we identify accountable owners for maintaining control and steering of topics to result in a positive outcome.
Additionally to this, I was also playing part role as consultant and coach, to get a mix of people together, into a team, with senior managers present, such that we can observe group/team dynamics and the characteristics that emerged out of the interaction. So the activity also served in building team morale, help break down the silos, surfacing "us/them" dynamics and personal biases. I also used it to get a sense for the passionate individuals that through their story telling, interactions, etc - hinted to me identifying candidates who will be driven and motivated to help us get past roadblocks, even the roadblocks were out their usual area of control.
So the first challenge was in identifying the core group of people to participate. I settled for three groups. I aimed to keep the team size to roughly seven plus minus two, maximum of nine, number eight excluded (check out Jurgen Appelo's take on ideal team size 5+-2, I think (?) Sutton also promotes team sizes up to 9). Nine was challenging indeed, I had to exclude many people to get to 9, which felt manageable for group dialogues. I ended up with three teams of 9 members each:
by Robert Sutton & Huggy Rao. Although this book's core messages are around scaling up organisations, a lot of the findings are equally applicable to the context of running large, complex projects. In my world, I manage large technical programs that involves many separate business units, clients & third-parties, with large development teams...The idea is now seeded in the company, people are talking about it, and it was well received by some CEOs, who have started using this concept in their high-level steering meetings (awesome)...I am a huge fan of Sutton, having first come across his work in Good Boss, Bad Boss: How to Be the Best... and Learn from the Worst
and The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn't. I also keep up with his blog at work matters, follow him on twitter & listen to podcasts whenever he talks at Stanford's ETL lectures, and he is also my personal connection on LinkedIn.As a program manager I have run various planning scenario workshops in my time, the classic risk brainstorming sessions, best-worst-case scenarios, etc - but I had never labelled the event as a "project pre-mortem", the name resonates with so many people because of their encounters with the classic project management tool of "project post-mortems". Not only the naming resonated well, the concept and implementation of this activity is in harmony with Management 3.0 concepts and practices of inclusion & transparency in agile practices. I was looking forward to changing tact, to experiment and try this out on a bunch of people (old-timers and youngsters) who are relatively receptive to new ideas and ways-of-working. It wasn't a complete success especially finding time out from a busy project that's already in motion, people came to the workshop a little skeptical, felt out-of-their-comfort zone, but nevertheless respected the process and participated as best as they could.
What's a "premortem" then?
Before I describe my custom implementation of this premortem, quoting Scaling up Excellence
, Chapter 8, "Look Back from the Future", pages 264-265:...We close with an additional twist, a mind trick that goads and guides people to act on what they know and, in turn, amplifies their odds of success. We build on Nobel winner Daniel Kahneman's favorite approach for making better decisions. This may sound weird, but it's a form of imaginary time travel. It is called "the premortem". Kahneman credits psychologist Gary Klein with inventing the premortem technique and applying it to help many project teams avert real failures and the ugly postmortems that often follow.
A scaling premortem works something like this: when your team is on the verge of making and implementing a big decision, call a meeting and ask each member to imagine that is is, say, a year later. Split them into two groups. Have one group imagine that the effort was an unmitigated disaster. Have the other one pretend it was a roaring success. Ask each member to work independently and generate reasons, or better yet, write a story, about why the success or failure occurred. Instruct them to be as detailed as possible and, as Klein emphasizes, to identify causes that they wouldn't usually mention "for fear of being impolitic". Next, have each person in the "failure" group read his or her list or story aloud, and record and collate the reasons. Repeat this process with the "success" group. Finally use the reasons from both groups to strengthen your scaling plan. If you uncover overwhelming and impassable roadblocks, then go back to the drawing board...How I customised the premortem for our context
As highlighted earlier, I help co-ordinate and steer large-scale projects that involve a few teams from different business units (with their own CEOs/CTOs), that must come together to develop a technical platform (set top box) and product/brand features (which is not owned by the engineering team responsible for the STB) and various operational management entities. We have over 150 people working on the project, scattered across the business. The project has been ongoing for a few months already, we've had team-wide or component-wide risk sessions, retrospectives and work was well underway. With an imminent release ahead of us, I wanted to hold this premortem with the primary focus of surfacing any issues / concerns that have either fell through the cracks, or swept under the carpet (which is often the case), ensuring we identify accountable owners for maintaining control and steering of topics to result in a positive outcome.
Additionally to this, I was also playing part role as consultant and coach, to get a mix of people together, into a team, with senior managers present, such that we can observe group/team dynamics and the characteristics that emerged out of the interaction. So the activity also served in building team morale, help break down the silos, surfacing "us/them" dynamics and personal biases. I also used it to get a sense for the passionate individuals that through their story telling, interactions, etc - hinted to me identifying candidates who will be driven and motivated to help us get past roadblocks, even the roadblocks were out their usual area of control.
So the first challenge was in identifying the core group of people to participate. I settled for three groups. I aimed to keep the team size to roughly seven plus minus two, maximum of nine, number eight excluded (check out Jurgen Appelo's take on ideal team size 5+-2, I think (?) Sutton also promotes team sizes up to 9). Nine was challenging indeed, I had to exclude many people to get to 9, which felt manageable for group dialogues. I ended up with three teams of 9 members each:
- Team A: Complete Success Team
- Team B: Royal Disaster Team
- Team O: Management Observers & Decision Makers
In terms of team member allocation, I set this up myself, because I know the people on my project, and the kind of biases and natural dispositions they have. So I mixed the teams forcing people out-of-their comfort zones, e.g. If you generally are pessimistic, I put you in the Optimistic team. If you don't usually work with outside teams, I mix you up so you get insight and appreciation into other team's contributions (e.g. not everything is about developers!).
I also self selected the team based on their expertise and previous experience with project deliveries. I saw these people as being seasoned with a variety of experiences, and from my interactions with them, would be vocal in sharing their concerns. I needed people with voice, that would engage in high levels of participation - no back-benchers allowed. Space was also a limiting factor.
I threw into the mix a separate group consisting of senior managers & senior technical leaders. These guys were tasked with observing the exercise in motion, listening to the stories from both groups, and then using their knowledge of the business & project, to help the two groups identify the common themes that emerged. Following that, and borrowing from agile practices, each manager was given three voting cards to use to vote on the topics. They could either use all their votes up in one go if they felt strongly about a particular topic, or share their votes across the topics. The topics would be arranged in descending order of votes, the highest voted topics indicating core areas to address.
Once the voting was over, we went back to the two groups and presented the outcomes (the two groups were privy to the management discussions). We then opened it up to the floor, looking for people to volunteer to take ownership of the topics.
Time was of the essence. I had only allocated two hours for the session. The meeting started ten minutes late to allow time for people to walk across the campus, and for me to open the session with the instructions. We also had to finish ten minutes early to allow time for people to make their next meeting. So the timebox was quite intense, we needed people to engage and collaborate quickly, and use rapid decision making...
This is agenda - I facilitated and was also part of the voting panel:
I had prepared the teams with advanced notice of about a week to allow them to think about this concept and to take note of their team allocations:
 |
| Cross-functional teams split |
The above team split represented a fair cross section of the organisation with a stake in the project, I tried to maintain a broad cross-functional base. Kudos to the teams for showing up and participating.
Some might argue that letting managers vote goes against the agile philosophy of empowering the teams. The management team selected here have all the necessary experiences to process the team's feedback. The teams were allowed to voice any objections to the proposed format - everyone felt included, acknowledged transparency and didn't see that as a hindrance. In fact, we count on our managers to offer insights that people-on-the-ground fail to appreciate, self-organised or not, there is still a need for management oversight especially when it comes to hardcore, critical delivery projects. I felt the additional group for managers that was equally cross-functional was a good forum for decision making and guidance, especially if people / infrastructure resources, support and escalations are required.
I am considering experimenting with premortems as part of the sprint planning (futurespective?) or at the start of release planning - giving the foot soldiers the opportunity to fully participate in the absence of "the management team"!...
Results & Assessment
This was our first attempt of a premortem. Time was short, we had to think fast. Topics came out that were reasonably known, there weren't any serious cracks, although the voting also gravitated to hot areas, leaving some topics without much attention but nevertheless important. We derived a list of areas to focus on, identified owners & briefly touched on the expectations & outcomes, leaving the detail for me to have on a one-on-one basis with the respective owners.
In observing the activities, the way-people-interacted and the different approaches of the teams, it did highlight areas of good collaboration but also some instances of dysfunction. For this type of meeting to have impact, people need to be fully present and immersed in the activities.
Although we had a team of managers observing, the space that was created was safe, people weren't intimidated by that presence. Management left the session with an appreciation their people have applied their minds and are indeed cognisant of the challenges and potential pitfalls that lay ahead. I actually wanted to let that point stick, because the management culture easily gets into command-and-control, micromanaging mode - at least from observing their people in action, thinking out-of-the-box, it had the desired effect of appreciation.
Time-wise, it was an expensive meeting. We don't have the luxury of getting key people in a room for more than two hours, we had to do what we could in the timebox allocated. Yes, we may have missed or rushed through the conversations, didn't get a chance to have spurious debates with people playing devil's advocate, but at least we covered as much as we could.
Did it work? Did the Idea Stick?
I shared the results of the session in a presentation, summarising the topics, areas to tackle and assigned owners responsible - with the senior managers (CEOs / GMs) that were unable to attend the session (actually I didn't invite some folk intentionally). One CEO immediately replied saying "This is really useful! a premortem...what a great concept!" - I hear this same CEO triggered an impromptu premortem(only yesterday!) with the rest of the Exec members. The seed was planted...the idea seems to have stuck!
At a another unrelated end-of-project close-out session held last week that involved a third-party supplier, a delegate challenged that we keep having these close-out meetings, yet we keep tripping up on the same mistakes, how do we change this?? One member, who didn't attend my premortem session, but had seen the notes and been part of my initial idea soundboard, jumped up at said, that maybe from now on, we should start every project off with a premortem, and that I should run them!
Another colleague for a completely different business unit, who is a good friend and very respectable hotshot project manager, had never heard of a premortem until I shared the concept. He is now talking to his teams about the idea.
So it seems that there is traction and a tendency to this more. I thoroughly enjoyed facilitating and participating in the session. Of course, the proof of the pudding lies in our people working together, anticipating and solving the challenges ahead of time - being diligent and disciplined in spite the time pressures and stress conditions they will be operating in the months running up to launch!Some might argue that letting managers vote goes against the agile philosophy of empowering the teams. The management team selected here have all the necessary experiences to process the team's feedback. The teams were allowed to voice any objections to the proposed format - everyone felt included, acknowledged transparency and didn't see that as a hindrance. In fact, we count on our managers to offer insights that people-on-the-ground fail to appreciate, self-organised or not, there is still a need for management oversight especially when it comes to hardcore, critical delivery projects. I felt the additional group for managers that was equally cross-functional was a good forum for decision making and guidance, especially if people / infrastructure resources, support and escalations are required.
I am considering experimenting with premortems as part of the sprint planning (futurespective?) or at the start of release planning - giving the foot soldiers the opportunity to fully participate in the absence of "the management team"!...
Results & Assessment
This was our first attempt of a premortem. Time was short, we had to think fast. Topics came out that were reasonably known, there weren't any serious cracks, although the voting also gravitated to hot areas, leaving some topics without much attention but nevertheless important. We derived a list of areas to focus on, identified owners & briefly touched on the expectations & outcomes, leaving the detail for me to have on a one-on-one basis with the respective owners.
 |
| Topics generated |
In observing the activities, the way-people-interacted and the different approaches of the teams, it did highlight areas of good collaboration but also some instances of dysfunction. For this type of meeting to have impact, people need to be fully present and immersed in the activities.
Although we had a team of managers observing, the space that was created was safe, people weren't intimidated by that presence. Management left the session with an appreciation their people have applied their minds and are indeed cognisant of the challenges and potential pitfalls that lay ahead. I actually wanted to let that point stick, because the management culture easily gets into command-and-control, micromanaging mode - at least from observing their people in action, thinking out-of-the-box, it had the desired effect of appreciation.
 |
| Management Votes |
Time-wise, it was an expensive meeting. We don't have the luxury of getting key people in a room for more than two hours, we had to do what we could in the timebox allocated. Yes, we may have missed or rushed through the conversations, didn't get a chance to have spurious debates with people playing devil's advocate, but at least we covered as much as we could.
Did it work? Did the Idea Stick?
I shared the results of the session in a presentation, summarising the topics, areas to tackle and assigned owners responsible - with the senior managers (CEOs / GMs) that were unable to attend the session (actually I didn't invite some folk intentionally). One CEO immediately replied saying "This is really useful! a premortem...what a great concept!" - I hear this same CEO triggered an impromptu premortem(only yesterday!) with the rest of the Exec members. The seed was planted...the idea seems to have stuck!
At a another unrelated end-of-project close-out session held last week that involved a third-party supplier, a delegate challenged that we keep having these close-out meetings, yet we keep tripping up on the same mistakes, how do we change this?? One member, who didn't attend my premortem session, but had seen the notes and been part of my initial idea soundboard, jumped up at said, that maybe from now on, we should start every project off with a premortem, and that I should run them!
Another colleague for a completely different business unit, who is a good friend and very respectable hotshot project manager, had never heard of a premortem until I shared the concept. He is now talking to his teams about the idea.
No comments:
Post a Comment