On Pre-mortems

Pre-mortem analysis is a project management strategy and risk-reducing tool that will help you prepare for any unforeseen events in the life of an important project. Not that I am uncovering anything new here, as this concept or technique became more popular after a well-known HBR article in 2007.

The idea is to conduct a workshop (with a deliverable final shared document) where participants gather to think about everything that could happen on a project (be it good or bad, but consider risks especially) and create a plan before it happens. A collaborative document that becomes the final deliverable is non-negotiable and also offers a chance for delayed thinking. Not everyone might come up with all valuable insight in a simple workshop.

This tool is about not wasting time, money and capacity on something that can be derailed by risks that were overlooked in a previous phase, or due to alignment issues or organizational constraints. Many risks can be avoided by way of thinking through technical, organizational and process considerations in advance. It does not have to be a painstakingly long or complicated exercise, but having a series of questions as a checklist and to guide thinking about the risks probably helps so that this exercise can be done with consistency multiple times.

A pre-mortem exercise is also a good way to tap into existing but diffuse organizational knowledge (the kind that is not easily formalized and shared) from the various experiences of projects past that each participant can bring to the table. By describing weaknesses that no one else has really thought of or shared, participants feel valued for their insight and experience - which increases engagement - and others learn from those past experiences (oral transmission of organizational folklore, if you want). The exercise also sets the team in the right operating mode to pick up early signs of trouble once the project gets under way, by making them aware of diagnosed risks, constraints or limitations.

While it is impossible to offer a one-size-fits-all question list, the following questions can help steer the exercise and provide some initial spark for discussion. Often it will be the case that a pre-mortem can tend to focus on the narrower scope of the project itself and adjacent technical considerations, but it is not infrequent that pitfalls lie in the wider organizational and cultural side of things.

A climate of psychological safety is needed, obviously, especially when it comes to highlight process & operational, organizational or capabilities risks.

General

• Is there really a clear opportunity or problem to be solved with this project? Is this something we really do or ought to be doing? Are there perhaps other hidden reasons we are trying to do this project?

• How does the project contribute to one or more of the following: organization's innovation goals, defending, maintaining, enhancing or building competitive positions, open new markets, optimize processes, build new revenue streams etc.

• What in the vision scope feels vague, unclear or untenable? or not supported by data?

• What worries you? (each participant should answer this one)

• What excites you? (same)

• What can prevent us from meeting deadlines, market times or other commitments? are those realistic? (especially if there are third parties and/or other external deliverables and dependencies involved)

• What does this project need that we don’t have? is it technology, know-how, capacity? And, conversely, what do we already have that this project needs? (more on this later)

• What do you think we need to do to make this project a success?

• How will we manage to always go on schedule? What lessons have you learned from previous projects?

• What are the organizational gaps or lacking capabilities that could put this project in jeopardy?

• How will we ensure that the project's outcomes are successfully integrated into the organization? This is important to ensure ROI, for example. Therefore, risks should be assessed not only for the project at hand in the shorter term but also from the angle of consolidation of the project, so that the transformational goals are achieved.

• What other external factors could impact the project such as market trends, regulatory changes, public opinion, economic conditions, geopolitical factors, etc.

Technical

Some questions in this realm could be things like:

• Examine the criteria by which you have arrived at the decision to use a specific technology. Maybe use the 5 Why’s technique and ensure hype, bandwagon effects or vendor push is not a key reason why something was chosen (be honest and objective)

• Examine your skill gaps, also the local marketplace and availability of skilled candidates. Think not only the project but also its maintenance and evolution afterwards

• How does this fit in your ecosystem / portfolio / landscape?

• Consider factors such as integration, scalability, reliability, security, and compatibility with existing systems

• Assess fit for purpose and future-proofness of the technology. Can you accommodate the tech with the people you have? Alternatively, what effort do you have to make?

• Try to gauge possible future costs for maintenance, what if you had to migrate?

• Assess how easy it is to maintain updated in terms of versions, patching, security vulnerabilities and so on

• What are the security / privacy considerations? (related to threat modelling and shift-left on Security)

Organizational and Cultural

• How well does this project align with our company's vision, mission and core values and culture? or not aligned with our strategy at company, or at market or BU level?

• Be honest in assessing wow the organizational structure could impact the project's success or failure.

• If there are organizational or capabilities gaps, what organizational changes (if any) would be necessary to support this project?

• Are there bottlenecks in our existing TOM’s or processes that have the potential to negatively impact the project?

• Are there any ethical or regulatory concerns? Alignment risks with ESG, SRI and so on.

• What stakeholders or constituencies could be against the project? Things such as potential conflicts or power dynamics, people who feel their turfs threatened etc.

• Identify all key stakeholders, especially the risky ones that may directly or indirectly impact the project adversely.

• What risks could there lurk in cross-collaborations?

• Pay attention to expectation alignment and management of conflicting priorities.

• Stakeholder engagement strategies through project lifecycle.

• What are the team dynamics and collaboration aspects we need to be specially careful about? That will depend on the specific setup, for example if there is on-site and remote teams, if everything is in-house or are there third-parties and vendors involved as well as other considerations such as the current morale & pre-existing burnout.

• How will we ensure knowledge retention / transfer and throughout the project lifecycle?

• Consider how resources will be allocated and prioritized, are there maybe too many competing projects? Does leadership have the necessary bandwidth or are we in a saturated landscape in terms of the number of projects (probably a bad sign).

• Is the leadership convinced this is the right project and fully supports it?

• Do you foresee resistance at other levels of the org chart?

By Project Phase

Additionally, risks can be classified into 4 main project phases. Each phases has different risks to be addressed.

• Planning. problems in this phase tend to have major repercussions for the rest of the project’s lifecycle, from unrealistic deadline crunch to budge overspending, team churn, failure to TTM etc. Think things like What is vague and unclear in goals and main requirements?, Why could we find we cannot manage unanticipated delays? Are we incurring in risks acquired from our partners / vendors?

• Building, what can fail during execution? try to anticipate problems with workflow, organization, dependencies between teams, people operations, daily workloads, how to manage delays, project management etc.

• Results, ultimately the deliverable is all that matters, but is it the right thing? does it meet the needs of the stakeholders? Address hypothetical questions here such as why have we missed our main goal?, why is the client unhappy?, why haven’t we delivered with the expected quality levels?, What are the problems with our performance metrics?

• Communication. can there problems with communication in the team, or between the team and other stakeholders. This is important especially when there are additional third parties involved. Can there be risks with communications with stakeholders? Why did team communication fail?, Why were our meetings ineffective?

Conducting the exercise

Kickstart the exercise with the basic questions:

• What could go wrong with this project?

• What could go right with this project?

Then give everyone time to brainstorm for solutions and actions for each question. As mentioned earlier, decide whether in your company it makes more sense to give time to attendants to prepare for this, perhaps gather data.

After the exercise is done, ask everyone to vote on the risks and focus on the top ones, which will be the most likely ones to happen. This is a good guide to drive this exercise if a team is together to do this together. You could use the basic tool of a whiteboard and post-its to see which risks are perceived by more people.

An exercise like this is best conducted with everyone in the same room, using a whiteboard or a wall and some stacks of post-its. If working remotely, just do via Teams and collaborate on a document, Miro or many other tools available. It could be an excel file with a few columns that could match the questions above or a tailored version thereof. If you already use something like Miro, you can leverage the templates already available, such as this one. Something similar exists for Mural here.

Or a Word document just the same, which is ideal for me when it comes to sharing and conveying deeper thought but does not seem a popular choice in many organizations. Avoid the ubiquitous habit of producing a PowerPoint deck. Slides are notoriously bad in transmitting deeper thought and are rather useless without the speaker's context and knowledge. Project wikis, which you should always have, are also a good place to document these with the added benefit of version control.

A single document should be the output of the activity in any case, which acts for codified knowledge to document the collective thinking that went into this. Do not rely on tacit knowledge or assume everyone is on the same page.

Recommendations

• Establish a clear deadline to get this done, this does not have to be a long exercise that drags for too long.

• If doing it with everyone together in the same room, keeping the exercise to two or three hours should be enough. One person exclusively to take notes.

• If team members work in different time zones, send them the collaboration document with a deadline for them to do pre-mortem analysis asynchronously.

• Make sure that the outcome of the debate includes actions for all risks, with clear accountabilities and deadlines. This is where the exercise adds value.

• Try to stick to facts and data for support and avoid unchecked assumptions.

• Store pre-mortem discussion and the actions in the team’s preferred collaboration space (SharePoint site, Teams, Azure DevOps) so that team and stakeholders can easily find them. Everyone involved should have easy access.

• Revisit the pre-mortem periodically to keep track of risks, or if there are new risks, and similarly keep track of the actions addressing those risks as identified in the original exercise.

• The exercise has to be conducted in an atmosphere where everyone feels safe to speak safely, and it is vital that groupthink and hippo override are avoided. People must feel safe to speak something that could be deemed "impolitical" by some, especially those higher up the org chart.

• Recommended team size for the exercise is between 3 and 10, since probably 10 people already poses a challenge to have a meaningful discussion. There has to be different stakeholders involved so that risks of different nature are considered. It will be mostly business and IT, but depending on specific projects, it could be necessary to involve legal, DPOs, or marketing and communications. If you feel more people have to be involved in this exercise, consider getting input in advance and keep the workshop headcount lower than 7 or 8.