Getty Images/iStockphoto
How a premortem reveals data modernization project pitfalls
By questioning assumptions early, leaders can spot workflow dependencies, adoption barriers and ownership gaps that a technology-first plan could miss.
Enterprises pursue data modernization projects to improve analytics that support decision-making and to create a foundation for AI.
However, those modernization efforts can focus on platforms and architecture at the expense of data governance, change management and user workflows. As a result, unanticipated risks can surface as distorted metrics, disrupted processes and declining trust from frustrated users.
Data leaders can use a premortem exercise to reveal those risks before major decisions become too difficult to undo. Described by psychologist Gary Klein in his 2003 book "The Power of Intuition," this risk-assessment technique asks participants to imagine a project has failed and then work backward to identify risks that might otherwise go unnoticed. Applied to data initiatives, the exercise broadens discussions beyond technology.
"I think data projects are great candidates because people often fall into tunnel vision about tools, semantics, mechanisms … and avoid the human factor," said Dan French, CEO at Consider Solutions, a risk management consultancy.
Sarah Broyd, a partner at Clarkston Consulting, said premortems are particularly useful for data modernization. That's because such projects often look successful technically while failing to deliver business value.
"Premortems force the team to identify those failure modes before architecture and implementation decisions become difficult to unwind," she said. "They help ensure data modernization projects don't become a technology project looking for a business outcome."
How to conduct a premortem
A premortem does not replace a risk assessment. Rather, by assuming the worst has already happened, it can make participants more willing to challenge assumptions and raise concerns.
"The Power of Intuition" describes a premortem as typically involving eight to 12 project team members. In it, participants give reasons why they think the failure happened, create a consolidated list of their concerns, devise ways to avoid the anticipated problems and periodically review the list.
Before diving into a premortem, explain its purpose because some participants might resist an exercise centered on failure.
"It is under-used and requires some pre-conditioning to ensure that participants don't feel it is overly negative," French said. "I think many people are wary of talking about potential failure. So there needs to be an upfront conversation."
Broyd recommended framing the exercise around a specific failure scenario and a timeline. Based on this example, she said a discussion question could be: "It is 18 months from now. We completed our data modernization program, but it has not delivered the expected value. What happened?"
The premortem participants should represent all the people who work with data in some capacity, including business leaders and leaders from the data, technology, change management and program team, Broyd said.
"The differences between what each group identifies as potential causes of failure can be as valuable as the risks themselves," she said.
Broyd recommended giving participants 5 to 10 minutes to independently write down what caused the fictional failure before discussing the risks as a group. She said this can help avoid groupthink and prevent the most senior or vocal participant from shaping everyone's initial response.
When describing the reasons for failure, participants should look for root causes, not just symptoms, Broyd said. Citing a lack of user adoption as a source of failure isn't enough. Additional details on what caused the poor uptake -- such as a lack of trust in the data or a process that made jobs harder -- give the organization something to act on, she said.
The team should then turn priority risks into actions and revisit them throughout the project.
"A premortem shouldn't end with a list of things that could go wrong," Broyd said. "For the most significant risks, identify mitigations, owners, early warning indicators and any changes that should be made to the project plan."
Once risks have been translated into actions, a project team should also revisit the premortem throughout the initiative.
"The exercise is most valuable when the risks become part of ongoing project governance," Broyd said. "At key milestones, teams should ask which risks are emerging, which have changed and whether new failure scenarios need to be considered."
When technical success isn't enough
Data managers can use premortems to test new data strategies, architecture decisions and AI readiness plans against how users actually use data -- as opposed to how project leaders believe users interact with data.
"Data is there for a reason and it has beneficiaries," French said. "Messing with data before you understand why and how it is used can be dangerous. Assumptions, as always, are a big risk."
Broyd said a premortem in a data modernization project can shift the focus beyond technology. An organization can deploy a modern data platform that meets the technological goals but still fails to deliver business value if users remain reliant on legacy practices and tools or don't make better decisions.
"That wording intentionally takes technology implementation off the table as the definition of success," Broyd said. "It forces the conversation toward value realization: Did we solve the right business problems? Do people trust and use the data? Are ownership and governance clear?"
A premortem also reinforces that data modernization is a business transformation, not simply a platform migration, she said.
"Especially with advanced analytics and AI, it's critical that businesses have the right data culture and business ownership to ensure the data is accurate and trusted," Broyd said.
Comparing related planning exercises
Some businesses embed premortem-like approaches within broader project approaches under a different name.
"We are seeing organizations place significantly more emphasis on identifying risk earlier in major transformation programs, although they may not always formally call the exercise a premortem," Broyd said.
Balazs Fejes, CEO and president at IT consultancy EPAM Systems, said his company's change management process involves business users to uncover requirements that centralized IT departments might overlook.
"We need to work backwards from the client -- from the business users -- and really understand the requirements," Fejes said.
Data modernization or platform changes usually start with IT or data teams, Fejes said. But IT or data managers might not understand how business users actually work with the data sets and platforms they provide, including dependencies on any vibe-coded tools or other shadow IT systems, used to connect to corporate data.
EPAM uses tabletop exercises to explore how planned changes to data sets, platforms or architectures would affect users. For example, what would happen if users no longer had access to a particular data set?
The exercises identify connected systems, processes and dependencies between data sets and data products, Fejes said. Unlike a premortem, their main purpose is data usage discovery and requirements gathering.
Broyd said the premortem goal is to spur corrective action, not assign blame.
"The value of a premortem isn't predicting exactly how a project might fail," she said. "It's creating an environment where teams can challenge assumptions early, while there is still time to do something about them."
John Moore is a freelance writer who has covered business and technology topics for 40 years. He focuses on enterprise IT strategy, AI adoption, data management and partner ecosystems.
