The Benefits Dependency Map Fails When Nobody Owns the Arrows
A benefits dependency map earns its place only when a change to an arrow changes a decision.
The Diagram Was Correct on the Day It Was Drawn
Six months after approval, the benefits dependency map is still pinned to the programme room wall. It shows a clean progression: common customer records enable standard processes; standard processes reduce handling time; reduced handling time releases 140 posts; released capacity produces £4.8 million of annual benefit.
The drawing remains immaculate. The programme does not.
Two regions have deferred migration because their local interfaces are not ready. The operations director has decided to use any released time to absorb rising demand rather than remove posts. A supplier contract assumed to end in March now runs until September. None of these decisions appears on the map. The programme board continues to receive a benefits report based on dependencies that no longer exist.
This is the practitioner’s honest account of benefits dependency mapping: the technique is valuable, but the way organisations use it turns a living investment argument into launch documentation.
The map is usually built when the business case needs intellectual order. It is admired during mobilisation, photographed for the governance pack and then abandoned to the programme office. Benefits are subsequently managed in a register, delivery in a plan, risks in a log and operational decisions in meeting minutes. The relationships between them — the very reason for drawing the map — disappear between artefacts.
A dependency map nobody maintains is worse than no map at all because it lends obsolete assumptions the appearance of continuing authority.
Benefits Fail Between the Boxes
The strongest feature of a dependency map is not the boxes. It is the arrows. Each arrow makes a causal claim: if this capability is delivered, then this behaviour will change; if that behaviour changes, then this outcome will follow.
Those claims are where benefits are won or lost.
Consider a composite programme in 2007 introducing a common purchasing system across nine business units. The original map states:
- Common catalogue enables consolidated demand.
- Consolidated demand enables fewer suppliers and improved prices.
- Improved prices deliver £3.2 million of annual savings.
The technology is installed on time. Yet four units continue using local catalogues for specialist items. Purchase data arrives under inconsistent product codes. The procurement director cannot combine demand before the main contracts are renewed. The system has delivered its capability, but the first behavioural dependency has failed. Reporting the programme as “green” and the benefit as “forecast” conceals the only fact that matters.
The benefit did not fail at the end of the chain. It failed at an arrow near the beginning.
This distinction matters because late benefits reviews encourage the wrong remedy. When the saving does not appear, leaders challenge the benefit owner, revise the forecast or ask for more reporting. By then the contract window has passed. The actionable intervention — enforce common coding and catalogue use before tender preparation — was needed nine months earlier.
Why the Map Becomes an Orphan
Benefits dependency maps are rarely maintained for understandable reasons.
First, ownership is ambiguous. The programme team sees the map as part of the business case. Finance sees it as programme evidence. Operations sees it as a planning diagram produced before delivery. The sponsor owns the investment in principle but does not edit working artefacts. Everyone relies on the map; nobody has a duty to keep it true.
Second, the map does not fit the monthly reporting rhythm. Programme boards are organised around milestones, expenditure, risks and issues. A changed dependency may not be a delivery variance. The operations director’s decision to retain capacity, for example, may be entirely sensible, yet it changes a cash-saving benefit into service capacity. Unless governance asks explicitly whether the causal chain has changed, the decision passes without revising the case.
Third, maintenance is confused with redrawing. Teams imagine that every adjustment requires a facilitator, a workshop and a new wall-sized diagram. Faced with that burden, they preserve the original and maintain nothing.
The answer is not more elaborate modelling. It is to treat each material arrow as a governed assumption.
A benefits dependency map earns its place only when a change to an arrow changes a decision.
The Serious Objection: Reality Is Too Fluid to Map
Experienced leaders often resist dependency maps because programmes are not machines. Outcomes have many causes; behaviour is uncertain; markets, demand and policy change. A diagram can imply a level of causality that management cannot prove. Maintaining it may consume scarce effort while giving false confidence.
That objection is right about certainty and wrong about usefulness.
The map should not claim that one intervention guarantees one benefit. It should expose the organisation’s current theory of how value will emerge so that the theory can be challenged. A causal claim written down is easier to test than an assumption buried in a financial model. Uncertainty is not a reason to avoid the map; it is the reason to annotate it.
| Dependency state | Meaning | Governance response |
|---|---|---|
| Confirmed | Evidence supports the link | Continue and monitor |
| Unproven | The link remains plausible but lacks evidence | Set an early test |
| Weakened | A decision or event reduces likelihood | Intervene or revise value |
| Broken | The required condition will not occur | Rebuild the chain or stop claiming the benefit |
| Replaced | A different outcome is now intended | Approve the new benefit and owner |
This is enough structure for useful control. It avoids pretending that causality is exact while preventing assumptions from becoming invisible.
Maintain Decisions, Not Artwork
A workable discipline can be light.
At every portfolio or programme review, take the largest benefits and ask three questions:
- Which dependency has changed since the last review?
- What evidence now supports or weakens the causal link?
- What decision follows for scope, operations, timing or investment?
The answers should update four items together: the dependency state, its owner, the next evidence date and the decision required. The visual map may be redrawn quarterly; the underlying claims must be maintained whenever a material decision changes them.
For the purchasing programme, this would make the real position visible. Common coding is unproven in five units; catalogue compliance is weakened in four; contract timing is fixed. The board can then choose among actual options: mandate adoption before tender, narrow the benefit to compliant units, delay procurement, or fund additional data cleansing. Each option changes cost, timing and value. None is available if the map continues to show a straight line from installation to savings.
The owner of each arrow should be the person able to make the next decision, not necessarily the person delivering the preceding box. Technology may own system readiness. Procurement may own catalogue policy. Business-unit leaders may own adoption. Finance may validate cash release. The sponsor owns the choice when those interests conflict.
The Map Is the Investment Argument
Organisations often maintain the delivery plan because dates move, the risk register because exposure changes and the financial forecast because costs develop. They leave the dependency map untouched even though it contains the assumptions connecting all three to value.
That reveals a deeper habit. We govern programmes as delivery systems and treat benefits as a later test. Yet benefits do not wait at the finish. They are created or surrendered through decisions taken throughout the work: whether to standardise, whether to retire a local process, whether to reduce a budget, whether to use released capacity for growth, whether to accept a delay that misses a commercial window.
The dependency map should therefore sit at the centre of portfolio judgement, not at the back of the business case. It is the organisation’s current explanation of why continued investment is rational.
The honest practice is not to preserve the original map. It is to preserve the argument by changing the map when reality changes. A programme that revises a dependency has not lost control. It has noticed where control is actually required.