[RBM+E] - what lovely chaos

In this partially free post, I'll walk you through a real-world case study that illustrates perfectly how organizational transformations can spiral into expensive chaos—and more importantly, how to prevent it from happening to your company.

Through my consulting work, I've witnessed countless transformation disasters that could have been avoided with proper governance. Today's story involves a small bank (let's call it ABank) that managed to turn what should have been a straightforward IT modernization into a multi-layered catastrophe involving overlapping initiatives, poor communication, and ultimately, a complete waste of resources.

This case study reveals the critical warning signs every leader should watch for:

• How well-intentioned teams can unknowingly work against each other

• Why market shifts during transformations create dangerous blind spots

• 🔐The exact moment when coordination breaks down (and how to catch it)

• 🔐What happens when acquisitions collide with ongoing transformation efforts

• 🔐The hidden costs of running parallel, competing initiatives

• 🔐Real strategies for maintaining control when everything seems to be falling apart

Here's what I've learned from looking at dozens of similar situations: the difference between success and failure isn't about having the perfect plan—it's about having the right setup to adapt when things go wrong.

For my subscribers, I'll break down the specific systems I've developed to prevent these disasters. This includes the decision-making setups that work, communication rules that keep everyone on the same page, and the early warning signs that help you spot trouble before it gets expensive.

Let's dive into ABank's story and see how a simple modernization project became a masterclass in what not to do.

How well-intentioned teams can unknowingly work against each other

At ABank, the IT modernization started with the best of intentions. The core team had a clear vision: migrate legacy systems to a cloud-based platform within 18 months. But here's where things got messy—and this is the pattern I see everywhere.

Three months into the project, the compliance team launched their own "data governance initiative" to meet new regulatory requirements. Makes sense, right? Except they never coordinated with the IT team. While IT was planning to restructure the entire data architecture, compliance was implementing their own data classification system using completely different standards.

Photo by Kenny Eliason on Unsplash

Then the customer experience team jumped in. They'd heard about the modernization and figured this was the perfect time to overhaul the customer portal. So they started their own project, assuming they could just plug into whatever the IT team built.

Here's the kicker: each team thought they were being helpful. The compliance team believed they were getting ahead of regulatory deadlines. The CX team thought they were maximizing the value of the IT investment. Nobody was deliberately trying to sabotage anything.

But without a central coordination point, these well-meaning efforts started creating chaos. IT would make architectural decisions, only to discover compliance had already committed to incompatible data formats. The CX team would request features that required completely different infrastructure than what IT had planned.

The real damage wasn't just the wasted work—it was the misinformation flowing between teams. Each group was making decisions based on incomplete or outdated information about what the others were doing. By month six, they were essentially building three different systems that were supposed to work together but never could.

Why market shifts during transformations create dangerous blind spots

The bank had created a detailed 18-month roadmap at the project's start, complete with specific milestones, technology choices, and integration points mapped out quarter by quarter. It looked impressive in PowerPoint. The executives loved the certainty it seemed to provide.

But markets aren't concerned about your roadmap. Six months in, new fintech competitors started offering services that made the bank's planned customer portal features look outdated. A regulatory change shifted compliance priorities. The vendor they'd locked into for the data architecture got acquired, and the new parent company announced they were discontinuing that product line.

Photo by David Birozy on Unsplash

Each of these shifts should have triggered a roadmap revision. Instead, teams kept marching toward the original plan because changing course felt like admitting failure. The IT team continued building infrastructure for features that were no longer competitive. Compliance kept implementing standards that were about to be superseded. The CX team designed interfaces for customer needs that had already evolved.

The irony? The more detailed and rigid the roadmap, the more it became a liability. Teams used it as gospel instead of guidance, making decisions based on assumptions that were months out of date. When reality diverged from the plan—which it always does—nobody wanted to be the one to call for a reset.

This is why transformation efforts fail more often during periods of rapid market change. It's not that the change itself is the problem—it's that organizations create roadmaps that can't adapt to change, then follow them religiously even when they're leading everyone off a cliff.