Financial Services

How We'd Solve It Today: Learning from 22+ Years of Transformation Pain

How We'd Solve It Today: Learning from 22+ Years of Transformation Pain

These transformation projects were completed using the best methodologies available at the time. But here's what 22+ years taught me: most transformation failures aren't technical – they're human.

The Painful Patterns I've Witnessed

Why 75% of Transformations Fail: The Budget Reality

Research shows 75% of transformation programs fail to achieve their goals, benefits, or ROI. Not by small margins – budget overruns of 50–200% are common.

The $500M payment separation I managed was already hemorrhaging money before I arrived. Planning phases that were supposed to take 3 months stretched to 12+ months while the business literally bled cash daily.

The Documentation Death Spiral

400-page functional specifications (yes, real number – I was so proud of the perfect formatting, spent weeks on it... zero bets on how many stakeholders actually read it).
Requirements obsolete before development even started. Months in approval committees tweaking flowcharts that had no relationship to how work actually happened.

The Alignment Disaster

IT thinks “transformation” means data integration.
Operations wants better processes.
Management wants cost reduction.
Finance wants ROI proof.

Everyone has different success definitions – which we discovered only after expensive development was complete.

I once sat in a room where we spent 2 hours arguing about whether something was “dark blue” or “navy” on a process diagram... while the actual business process was falling apart.

The Adoption Crisis

Perfect systems built exactly to specification – that nobody wanted to use.
Change resistance killed ROI even when technology worked flawlessly. Teams reverted to Excel spreadsheets and manual workarounds because they weren't involved in designing the “better” way.

The Expertise Extraction Impossibility

Paying consultants hundreds of thousands to learn your business (badly) when the real experts were sitting in your organization. Months trying to document knowledge that lived in people's heads, creating artifacts nobody could actually use.

My Breaking Point (And Probably Yours Too)

The moment I knew something was fundamentally broken:

I spent 8 months trying to get a group aligned on what a payment process solution should look like. Eight months.

Of meetings about meetings about what the meeting agenda should be – while customers were literally calling to complain about the broken payment process we were “strategically optimizing.”

I was drowning in never-ending meeting tunnels. We called it “stakeholder management” or “politics,” but the truth was simpler:

We had no clue how to collaborate effectively on complex problems.

That’s when I realized something had to change.
The methodologies we were using weren't working.
We were optimizing for planning perfection instead of actually solving anything.

The Fundamental Shift That Changed Everything

The Old Way:

  • Months documenting requirements, hoping we understood correctly

  • Building expensive solutions based on our best guesses

  • Discovering misalignments after massive investment

  • Fighting adoption battles after deployment

The New Way:

  • Cross-functional squads with real decision-making power

  • Co-create solutions using structured collaboration frameworks (e.g., Agility Sprints)

  • Working prototypes validated with real users weekly

  • Built-in adoption because people design their own solutions

The Critical Success Factor: Truly Autonomous Squads

Here’s what most transformations get wrong:
Even after adopting new methodologies, they keep the same approval structures.
You end up with “agile” teams creating prototypes that still need committee approval – right back to meeting hell.

For transformation to actually work, the squad must:

  • Be truly cross-functional – all expertise needed to make decisions in the room

  • Have actual decision-making power – not just recommendation authority

  • Be autonomous within defined boundaries – can commit to solutions without escalation

Without this, you're just creating fancy prototypes that die in approval committees.

What This Actually Changes

✅ Eliminate the Consultant Learning Tax

Instead of paying external teams to understand your business, we facilitate your experts to design solutions using knowledge they already have.

✅ Validation Before Investment

Working prototypes tested by real users before major technical investment.
Problems caught in days – not after months of expensive development.

✅ Built-In Adoption

When people co-create the solution, they champion its implementation.
Change resistance is solved during design, not after deployment.

✅ Compressed Timelines

3–6 months with continuously validated progress instead of 18–36 months (75% planning, 25% panic building).

The Bottom Line

Your transformation challenge may be unique, but the human dynamics and organizational friction are ones I’ve navigated for over two decades.

The difference:

We get started instead of getting perfect.