Modern CRM Transformation - Part 4: How to Keep CRM Delivery Flowing Across Teams

Signal Boost: "Lippy Kids" by Elbow
A reflection on complexity, growth, and the beauty of messy collaboration.

In a large CRM transformation, dependencies are inevitable. I’ve seen projects grind to a halt not because the teams lacked skill, but because an unseen dependency exploded three weeks before go-live.

Trying to eliminate all dependencies is a fantasy. Pretending they don't exist is a disaster. The real art is to make dependencies visible early, manage them collaboratively, and keep delivery flowing despite them.

Here’s how we tackled it.

Why Dependencies Become Dangerous

Dependencies only become dangerous when they are:

• Invisible: Nobody knows they exist until it's too late.
• Misunderstood: Teams don't agree on ownership, priority, or sequencing.
• Unmanaged: No one feels responsible for unblocking them.

When that happens, even the best-planned work can stall. Teams sit idle. Tension rises. Blame games start. Projects drift into chaos.

We knew dependency risk would rise unless we built a better way of handling it from the start.

Building a Dependency Management System That Actually Worked

Before we built our system, we looked honestly at why dependency management often fails:

• Teams hide or downplay dependencies out of fear.
• Dependency tracking becomes a bureaucratic reporting exercise.
• Leadership gets involved too late, when options have narrowed.

We needed a different approach. We designed around three simple principles.

1. Make Dependencies Visible, Early and Often

Every product team owned their delivery plans, and part of that ownership was to surface dependencies proactively.

We used a shared "Dependency Wall", a simple board where all known dependencies were:

• Posted by the team who needed something.
• Assigned to the team who owned the dependency.
• Tracked with clear status: identified, agreed, committed, delivered.

Every dependency had a name, an owner, and a date.

Example: "Customer Onboarding team needs Partner Management API available by June 15th."

Because it was posted early, the Platform Team had plenty of time to plan and deliver it without drama. If it wasn’t on the Dependency Wall, it didn’t exist. Visibility first.

2. Encourage Direct Team-to-Team Communication

We actively discouraged dependency escalation unless absolutely necessary.

Teams were expected to:

• Talk directly.
• Negotiate sequencing.
• Adjust backlogs if needed.

Only if they couldn’t resolve a conflict themselves would it escalate to leadership.

Why:

• Keeps teams accountable and collaborative.
• Builds trust across streams.
• Avoids clogging leadership with micro-decisions.

Dependencies became an everyday conversation, not a crisis management exercise.

3. Focus Leadership Attention on "At Risk" Dependencies

Every week, teams reviewed the Dependency Wall together.

• If a dependency was on track, no drama.
• If a dependency looked "at risk" (date slipping, unclear ownership), it was highlighted for leadership intervention.

This kept leadership focused where it mattered: not micro-managing, but unblocking real risks.

Example:
A critical dependency on a third-party data migration slipped by two weeks. Because the risk surfaced early, leadership stepped in, re-prioritised scope, and protected the overall go-live timeline.

Challenges We Faced (and How We Adapted)

Reluctance to Surface Dependencies:
Early on, some teams were hesitant to admit dependencies, worrying it made them look weak. We flipped the story: surfacing dependencies early was framed as a sign of mature, responsible delivery.

Conflicting Priorities:
Sometimes two teams needed the same resources at the same time. In those moments, we focused on the outcomes, not the politics, to drive prioritisation.

Late-Discovered Dependencies:
Not every dependency surfaced early. I remember one where a seemingly minor finance integration turned out to have downstream impacts on five value streams.
We missed it initially. But because the culture was blame-free, teams flagged it quickly, triaged together, and adjusted roadmaps openly.

It was a scramble, but a visible, collaborative one.

What It All Comes Down To

By making dependencies visible, team-owned, and leadership-supported, we created:

• A much faster, healthier flow of work.
• Fewer last-minute surprises.
• Stronger collaboration between teams.
• Earlier risk surfacing and mitigation.

Most importantly, we avoided the silent build-up of hidden risk that cripples so many CRM programmes.

Dependencies weren’t the enemy. Hidden dependencies were.

When you make visibility a daily team habit, delivery flows faster, smoother, and with a lot less drama.

Next Up: Part 5: How to Track CRM Transformation Health.
Measure what matters. Track CRM health with meaningful, actionable metrics.