Seventy percent of transformation programmes fail. The redesigned process was usually fine. The technology worked. The people who were supposed to follow the new process quietly went back to the old one.
Before you redesign anything, there is one question worth sitting with: do you actually understand why the current process was built this way?
"The Staff Are Doing It Their Way Because They Think It's Better"
Most change management programmes skip a basic check. The team running your legacy process is not being difficult. They are being rational.
Long-tenured operations staff built those workarounds in response to real constraints. The approval step that looks redundant? It was added after a fraud event. The manual reconciliation that kills two hours every morning? It was instituted after a regulatory incident that cost the bank far more than two hours. The parallel documentation trail that no one can explain? Someone's job once depended on it.
When new leadership arrives with a mandate to improve efficiency and immediately begins redesigning workflows, they often strip out controls that exist for reasons no one thought to write down. The result is a process that looks cleaner on paper and is genuinely more dangerous in practice.
The most honest framing of this problem comes from a manager who successfully transformed an organisation that had resisted change for years: "Resist the urge to make large operational changes until you have really taken the time to understand the current process and why it was implemented in the first place."
That is not a soft suggestion. It is the prerequisite for every step that follows.
Why Resistance Is Often Legitimate—And What to Do About It
Change management literature pathologises resistance. Staff who push back are labelled change-averse, defenders of the status quo, obstacles to progress.
That framing is inaccurate and counterproductive.
The operations manager who has run loan origination for fourteen years is not resistant to improvement. She is resistant to changes made by people who have not done the job. That distinction matters when you are trying to build adoption.
Before any change programme begins, the team running the current process is your primary source of institutional knowledge—not a constituency to be managed. Their objections are data. Their workarounds are signals. The question is not "how do we get them to accept the new process?" The question is "what do they know that we do not?"
The current process may not be optimal. But the people closest to it understand its constraints in ways that process maps and frameworks do not capture.
Discovery does three things. It surfaces legitimate constraints that must survive into the redesigned process. It finds the unofficial rules the team uses to handle exceptions—rules that are often more important than the documented procedure. And it starts building the trust that adoption depends on.
A change programme that skips this will produce a technically superior process that nobody follows. There are entire industries built on recovering from exactly that outcome.
The Shared Urgency Problem: Nobody Changes a Process They Think Is Fine
There is a subtler issue underneath resistance: the absence of shared urgency.
Most process improvement projects are initiated by leadership, not by the teams doing the work. The gap between "leadership knows this process needs to change" and "the team running the process agrees it needs to change" is where most programmes die quietly.
The clearest articulation of this problem: "Without having a general understanding that there is a need to improve, it's tough to get people to see value." If the team running the process does not share the belief that change is necessary, every adoption effort becomes a battle of wills. You can mandate compliance. You cannot mandate genuine adoption.
Establishing shared urgency is not a communications exercise. Sending a memo from the CEO or running a transformation roadshow does not do it. Showing the people doing the work what their work actually costs—in time, in error rate, in customer impact—does.
Data depersonalises the problem. When you show a loan operations team that their current origination process takes 139 days end-to-end, and then show them a comparable institution that completed the same transformation in four months to reach 57 days—a 59% reduction—the conversation changes. It is no longer about defending the current process. It becomes about whether this team wants to be on the right side of that gap.
The Kuwait bank result is instructive not because 139 to 57 days is an exceptional outcome, but because the methodology that produced it started with process discovery, not process redesign. The urgency data came after the listening.
That sequencing is the entire point.
The 5-Step Change Management Sequence That Actually Works
Most process improvement frameworks treat change management as a parallel track. Stakeholder engagement is a workstream. Communications is a deliverable. Adoption is a post-go-live activity.
That architecture virtually guarantees the outcome it is trying to prevent.
Change management is not parallel to process improvement. It is the process. The sequence matters more than the methodology.
Step 1: Understand the current process with the people who run it
Not by reviewing the documented procedure. Not by shadowing one person for an afternoon. By running structured discovery sessions with the full team—mapping what actually happens, not what the SOP says should happen, and specifically surfacing why each step exists. The goal is a complete picture of institutional logic, including the logic that lives entirely in people's heads.
Step 2: Establish shared urgency with data
Before presenting any proposed changes, present the cost of the current state. Time-to-completion benchmarks. Error rates. Customer satisfaction scores. Regulatory exposure. The goal is not to embarrass anyone. The goal is to create a shared baseline: here is what this process costs us, and here is what comparable institutions have achieved.
Step 3: Co-design the future state
The team that runs the current process should be in the room when the new process is designed. Not as reviewers of a draft. As designers. This serves two purposes: it produces a better process—because the team knows the constraints—and it creates psychological ownership that adoption depends on.
Co-design is not a focus group. It is not a workshop where leadership presents options and the team votes. It means the people doing the work propose the future-state steps, name the exceptions they need to handle, and draw the boundary between what can be streamlined and what cannot. A process designed this way will have advocates on the floor who can explain it to colleagues who are struggling—because they helped build it. No training programme produces that effect. Co-design does.
Step 4: Deploy with adoption infrastructure
Deploying a new process and deploying a new SOP document are not the same thing. Adoption infrastructure means the team has the reference materials they need in the workflow contexts where they actually make decisions. It means managers can track whether the new process is being followed, in real time, without building a compliance programme around it. It means the training is not a one-day event that people forget.
Step 5: Measure retention at 30, 90, and 365 days
Process improvement that cannot prove retention is not process improvement. It is process replacement—and process replacement has a well-documented tendency to revert. Measuring at 30 days tells you whether initial adoption held. Measuring at 90 days tells you whether the process survived its first wave of exceptions and edge cases. Measuring at 365 days tells you whether the change actually became how the organisation works.
The Project That Technically Succeeded
This scenario repeats across banking operations with uncomfortable regularity.
A process improvement engagement runs for six months. Consultants map the current state, identify inefficiencies, design a future state. The new process is documented, training is delivered, and the project is closed as a success. The engagement sponsor signs off. The team leads confirm readiness.
Six months later, 40% of staff are still running the old process. Not explicitly. Not defiantly. They simply never fully transitioned. They kept the workarounds that felt safer. They reverted to the familiar steps when the edge cases hit. The new process exists on paper. The old process exists in practice.
The failure did not happen at go-live. It happened before the project started—when discovery was treated as a formality, when shared urgency was assumed rather than established, when co-design was replaced by a change review, and when adoption infrastructure meant a PDF in a shared drive.
Every tool involved may have worked exactly as intended. This is a sequence problem. The technical work was executed in the right order. The change management work was not executed at all.
What makes this pattern hard to interrupt is that each skipped step feels defensible in the moment. Discovery takes time the project plan does not allow for. Shared urgency sessions are hard to schedule with operations teams. Co-design workshops require leadership to give up control of the future-state design. Adoption infrastructure requires investment after the go-live budget is spent. Retention measurement requires a commitment to accountability that most projects close before making.
Every shortcut has a plausible reason. The accumulation of those shortcuts is why 40% of staff are still on the old process six months later.
The organisations that avoid this outcome do not have better change management methodologies. They ask a different starting question: do the people doing this work understand why it needs to change, and do they believe the new design is better than what they built? That question cannot be answered by reading the current SOP.
Where ESSAM Sits in This Sequence
ESSAM is built around this sequence, not around any single step in it.
At Step 1, ESSAM's process mapping tools run with the team—not ahead of them. The structured discovery format guides conversations that surface institutional logic alongside the documented procedure. The output is not a consultant's process map. It is the team's own account of how the work actually happens.
At Step 4, ESSAM's WhatsApp SOP deployment addresses the most consistent failure point in process rollout: procedures that live somewhere other than where decisions get made. When the new process is accessible in the messaging environment where operations staff already work, adoption friction drops. The alternative—a document in a folder, a slide deck from training day, an intranet page—requires a navigation step that most staff skip under time pressure. That is not laziness. That is how humans work.
At Step 5, ESSAM's acknowledgment tracking closes the measurement gap. Most organisations cannot tell, at Day 45, whether the new process is being followed. Acknowledgment tracking produces a real-time compliance signal at the individual and team level—without requiring a separate audit programme to generate it.
More detail on the WhatsApp deployment model is at /blog/whatsapp-sop-deployment. For the structural reasons why process improvement results do not hold past the six-month mark, /blog/why-process-improvement-projects-fail-six-months-after-the-consultant-leaves covers the reversion dynamic in detail. ESSAM's full feature set is at /features.
The E-S-S-A-M framework does not replace the change management sequence. It makes the sequence executable—in banking environments where operations teams are distributed, training time is limited, and compliance cannot be left to self-reporting.
The Harder Question Behind Every Process Improvement Project
The 70% failure statistic is not a warning about methodology. It is a warning about starting conditions.
Every process improvement project carries a question that usually goes unasked: did we earn the right to make this change? Earning that right means understanding the current process deeply enough to know what must be preserved. It means establishing urgency with data before requesting adoption. It means treating the people running the current process as co-designers, not as recipients of training.
The manager who successfully changed a resistant organisation listened first. The team that successfully adopts a new process understood why it was necessary before they were asked to follow it.
The better process usually exists. The problem is the sequence of steps required to make it permanent—and the discipline to resist skipping any of them.
Frequently Asked Questions
What is the biggest reason change management fails in banking operations?
The most consistent cause is the absence of shared urgency before the change programme begins. When the team running the current process does not understand why change is necessary—in concrete, data-supported terms—every adoption effort becomes a compliance exercise rather than genuine improvement. Staff follow new processes when they understand the cost of the old ones. Establishing that understanding is the work that precedes every other step.
How long should the discovery phase take before redesigning a process?
This depends on process complexity and team size, but the discovery phase should not be compressed to meet project timelines. A three-week discovery phase for a complex banking operation is not excessive. The cost of inadequate discovery is not a slower project—it is a failed adoption six months later. Structured discovery sessions run with the full team, not just team leads, typically reveal institutional logic that process maps and SOPs do not capture.
What does "adoption infrastructure" mean in practice for a banking team?
Adoption infrastructure means the team has access to the new procedure in the workflow contexts where they actually make decisions—not in a training document they reviewed once. For distributed banking operations teams, this typically means reference materials accessible through the communication channels staff already use, combined with a mechanism for tracking whether the process is being followed in real time. The goal is to reduce the friction between "knowing the new process" and "using the new process" to near zero.
How do you measure whether process improvement results are holding?
Measurement should happen at three intervals: 30 days, 90 days, and 365 days post-go-live. At 30 days, you are measuring initial adoption—whether the training translated to consistent behaviour. At 90 days, you are measuring resilience—whether the new process survived the first wave of edge cases and exceptions. At 365 days, you are measuring whether the change became permanent. Programmes that measure only at go-live are measuring compliance theatre, not adoption.
What is the most common mistake banks make in the co-design phase?
Treating it as a sign-off rather than a design session. The most common pattern is that leadership presents a future-state process design—produced by a consultant or internal team—and then runs workshops to "validate" it with the operations team. Staff raise objections. Some are incorporated as minor adjustments. The core design is unchanged. Then leadership is surprised when adoption is weak. The operations team, meanwhile, is not surprised at all—they flagged the issues in the workshop, saw them dismissed, and drew the rational conclusion that the new process was designed for someone else's job. Co-design requires bringing the blank sheet into the room, not the near-final draft.
If you are at the beginning of a process improvement programme—or six months past a go-live and watching adoption slip—the starting point is the same: understand what is actually happening, and why, before redesigning anything.
Talk to the ESSAM team about your discovery and deployment sequence.