Practical guide
How to manage benefit dependencies and enabling projects across a portfolio
Make the conditions behind shared value visible, so enabling work, operational adoption and the timing of benefits can be reviewed together.
Wovex
Summary
Manage benefit dependencies by defining the shared improvement, identifying the changes required for it to occur and assigning responsibility for each material condition. Connect enabling work to the benefit without giving every project the whole benefit claim. Review timing, readiness and evidence across initiative boundaries. Distinguish a planned contribution from evidence of causal attribution, and agree separately how shared benefits enter portfolio reporting. A map makes the dependency discussable; it does not prove that the benefit will occur.
Define the improvement before assigning projects
A portfolio may contain several initiatives that are each necessary for one business improvement. A data platform may enable a redesigned service; training and operational adoption may determine whether that service changes performance. None of those relationships means every initiative independently delivers the whole benefit.
Define the intended improvement, affected population, observation period and measure. Then ask what must be true for it to occur. Include operational conditions as well as project deliverables: access, adoption, staffing, process changes and continuing service support can matter as much as technical readiness.
The Teal Book addresses dependencies and the timing of contributing work in benefits management. This guide offers a practical way to discuss those conditions across project boundaries, rather than a prescribed modelling notation.
Work through a shared service dependency example
Consider a fictional portfolio aiming to reduce repeat customer contacts about an unresolved service request. The benefit is defined for a particular service population and reporting period. Four conditions need coordinated attention.
Required condition | Contribution and evidence to review |
|---|---|
Consistent request data | A data-cleanup initiative provides usable request identifiers; sample checks test whether the relevant cases can be matched. |
Visible request status | A service-tool project makes status available; operational checks establish that staff can access current information. |
Changed handling practice | The service team adopts a new response process; observation tests whether people use it for the relevant requests. |
Sustainable operational cover | The operations manager provides staffing and support; review checks whether the service can maintain the new practice. |
The data work may produce no direct reduction in contacts on its own. Its value lies partly in enabling the service change. Assess that role against the outcome it supports, the alternatives and the cost of maintaining the capability, rather than inventing a standalone cash saving.
Delivery of all four conditions would still not prove the reduction occurred. Later observations must establish the movement, and reviewers should investigate other influences such as changing demand or a separate communications campaign.
Manage timing as a benefit dependency
Identify the latest date each condition must be ready for the benefit expectation to remain credible. Distinguish a technical completion date from the point at which a capability is usable in operations.
For the example, installing the service tool in June would not support a June benefit forecast if clean data arrives in August and changed handling practice begins in September. Check the lag between readiness, adoption and an observable result rather than shifting dates by an arbitrary common interval.
An enabling delay can affect several benefits at once. Bring the affected owners together to assess scope and timing. Avoid reviewing each dependent project in isolation and then discovering the common constraint only when portfolio expectations fail.
Record alternative paths too. A temporary operating arrangement may preserve part of the improvement while the permanent enabler is delayed. Explain its cost, limitations and duration; a workaround is a decision to assess, not evidence that the original dependency disappeared.
Keep contribution distinct from attribution and allocation
Contribution describes the part an initiative is expected to play in the change pathway. Attribution asks whether, and to what extent, the intervention caused the observed change. A diagrammed connection or a completed milestone is insufficient to answer that causal question.
The Magenta Book describes contribution analysis as building an evidenced explanation rather than definitive proof. A practical review should test the proposed pathway and consider other explanations. It should not infer exclusive attribution from a plausible map.
Allocation is different again. An agreed percentage split may serve management reporting, but does not establish the causal share of each project. For the counting and reporting treatment, use the double counting guide. Keep one shared claim recognisable wherever it is displayed.
Run a cross-project dependency review
Use the following sequence for material dependencies, adapting the detail to the decision.
Identify the shared benefit and the conditions needed for its expected scale and timing.
Name who maintains each condition and who coordinates the benefit review.
Check readiness evidence, dates and operational adoption across the contributing work.
Assess the effect of gaps on dependent forecasts and compare realistic responses.
Record the agreed actions, reporting treatment and next check with the affected owners.
One person may coordinate the shared benefit without owning every project or operational action. Make that distinction explicit so responsibility does not vanish between teams. Escalate an unresolved dependency to a forum able to change priorities or resource commitments.
Use connected views with clear interpretation
Choose a representation that helps people follow the relationships. The benefits map, register and tracking guide explains the different jobs those tools perform.
Wovex supports connecting initiatives, benefits and measures for review. Its Impact Explorer can show defined benefit alignment, contributing initiatives and associated measurement progress. Confirm the relevant plan, permissions, configuration and review scope; Impact Explorer reporting is an Enterprise capability.
Use those views to investigate the agreed model. A visible connection does not confirm operational readiness, prove causation or establish automatic allocation or deduplication. No aggregation formula is specified here. Demonstrate the actual shared-benefit reporting treatment before relying on a portfolio total.
Sources and context
UK Government Project Delivery: Teal Book, Chapter 19 — Benefits management.
HM Treasury: Magenta Book — Central Government guidance on evaluation.
The dependency example and review sequence are Wovex guidance; the service example is fictional. The sources provide benefits and evaluation context. A relationship, reporting allocation or observed movement alone does not establish causal attribution. Confirm current product entitlement and the actual scope of any demonstrated report.