Change Management

    The change dependency map

    Transformation stalls on missing precursors. Map every dependency, with an owner and a date, before you announce the vision.

    A change dependency map charts everything that must exist before a customer-centric change can succeed: skills, staffing, budget, authority, systems, and metrics. It replaces the inspirational announcement with an accountable plan. That difference is what separates transformation from theater.

    Staff have heard the exciting-future speech before. What breeds change fatigue is not ambition; it is the missing path between the speech and Monday morning. A change dependency map fixes that. Start with the transformation goal, then branch backward into everything that must exist first: trained people, adequate staffing, budget, data access, decision authority, new metrics, adjusted release schedules. Each dependency gets an owner, a date, and a visible status. The result is a plan transparent enough that people can hold it, and leadership, to account.

    Why it matters to the business

    Most transformation money dies in the gap between announcement and execution. Gartner's 2021 survey found 83% of organizations struggle to turn journey maps into prioritized action, and Forrester finds fewer than one-third of firms create shared accountability for journey performance. Those are governance failures, not method failures: the vision existed, the precursors did not.

    The prize for change that actually lands is substantial. McKinsey reports that journey improvements lift revenue 10 to 15 percent and cut cost-to-serve 15 to 20 percent. A dependency map protects that return by exposing the bottleneck in month one, instead of letting it surface as a stalled program in month nine.

    How to use it

    • Start with the outcome and work backward, listing every precursor: skills, staffing, budget, data, authority, systems.
    • Assign each dependency an owner, a target date, and a status anyone can check.
    • Write cultural requirements, like frontline authority to act on insights, as testable dependencies rather than aspirations.
    • Plan operational changes to KPIs, incentives, and release schedules alongside the process changes, not as afterthoughts.
    • Sequence a lighthouse first: pick one journey where every dependency can be met inside a quarter, in line with McKinsey's 6-to-12-week redesign prototypes.
    • Review the map monthly at executive level; a blocked dependency is an escalation, not a footnote.

    Where teams get it wrong

    The map gets built once for the kickoff deck and never governed again. Or it lists only logistics and skips the hard dependencies: authority, incentives, and permission to miss a deadline for quality. The change then dies quietly when frontline teams discover they were told to behave differently without being allowed to.

    Ask your team

    • For our current CX initiative, can anyone show me the list of things that must be true before it works, and who owns each one?
    • Which dependency is blocked right now, and when did leadership last hear about it?
    • What authority have we actually granted teams to act differently, and how would we test that it is real?

    People are not tired of change. They are tired of being promised change without a path.

    Apply this

    Reading about the change dependency map is one thing. Seeing where it applies in your journey is the useful part.

    Related signals