Dependency maps as decision artefacts: turning interdependencies into conditional approval gates for public‑sector transformation

What senior leaders must decide and why a different artefact is required

Boards are no longer asking whether a programme looks clever; they are asking whether the programme is fundable, controllable and reversible. The ‘funding decision’ should be conditional — it must state which dependencies must be satisfied, which may be tolerated conditionally, who owns each dependency, and what the next payment or authority will trigger. Traditional dependency diagrams fail because they are aesthetic, unowned and lack defined acceptance criteria. Leaders need a ledger‑grade artefact that ties dependencies to owners, evidence states and conditional decisions.

Why interdependencies break delivery: the mechanics

Failure to manage dependencies happens for four reasons: (1) mixed horizons — work with different timelines and control boundaries are treated as one aggregate plan; (2) invisible owners — no accountable owner or commercial lever for the enabling item; (3) weak evidence — visual diagrams without traceable source records or interface contracts; and (4) governance gap — approvals that ignore conditionality and do not translate to operational gates. These mechanics combine across people, process, data, technology, suppliers and controls: e.g., a benefits realisation metric assumes data availability (data dependency), which requires a supplier’s API contract (commercial dependency), which in turn requires a security baseline (cyber dependency) and an operational runbook (people/process dependency). If any link is ambiguous, the funded outcome is at risk.

What a decision‑grade dependency artefact looks like

The decision artefact is a dependency ledger (machine readable) plus a directional map (visual). The ledger records each dependency as a discrete entry with: unique identifier; type (mandatory/conditional/shared/optional); owner (role and escalation contact); required evidence and its current state (e.g., contract signed / API spec exchange / test environment available); failure effect (impact on service, cost, schedule, benefits); allowable exposure (tolerance or limit); commercial levers (penalty, acceptance gate, transition services); and an explicit next decision (advance/reshape/hold/stop). The visual map is a network view that colours nodes by acceptance state and highlights chains that must be funded together.

How this artefact must change the approval lifecycle

Decision makers must see dependency state at each appraisal and approval point. Practical consequence: approvals become conditional with named obligations. A typical conditional approval outcome should read: “Approve Scope X to design and build subject to supplier A delivering interface API v2 and Department B confirming statutory authorisation within 60 days; if both conditions move to satisfied, release tranche 2 payment and allow integration testing.” The ledger must be included in the executive evidence pack and be a live item in the programme’s decision‑gate checklist.

Tracing the dependency through the transformation lifecycle

Not every lifecycle stage uses the ledger the same way. In discovery the ledger captures hypothesis and external constraints (policy sign‑off, statutory steps, third‑party readiness). In design, it matures into contractual and technical interfaces. In build, it drives environment availability, data migration windows and supplier cutover readiness. Before cutover the ledger must be at ‘satisfied’ or ‘contractually gated’ state for every mandatory dependency; conditional dependencies must have mitigation runbooks and quantified exposure. After go‑live the ledger becomes an input to benefits realisation and runbook handover.

Artefacts, evidence and decision gates senior leaders should expect

Require the following artefacts in the executive evidence pack: 1) a dependency ledger (CSV/SME system export) with each field populated and source links; 2) the dependency‑owner attestations (signed statements from owner role and supplier representative where relevant); 3) interface acceptance evidence (contract clauses, API conformance test results, data reconciliation scripts and sample reconciliation outputs); 4) commercial levers recorded in contract or interim variation (reversibility clauses, transition services, release conditions); 5) an integrated failure‑mode register mapping how each dependency failure propagates to service and benefits metrics; 6) a capability and capacity heatmap showing shared resource constraints; and 7) a conditional approval statement with explicit next funding authority and re‑evaluation date.

Failure modes and what they look like in the ledger

Common failure modes appear as ledger states: 'owner unknown' (no accountable role), 'evidence missing' (no contractual or test artefact), 'external authority pending' (legal or regulatory permission), and 'supplier sequence conflict' (two suppliers requiring the same cutover window). Each state must have a prescribed handling rule — e.g., 'owner unknown' escalates to SRO within 48 hours; 'evidence missing' pauses tranche release unless an alternative mitigation is accepted. The ledger must record the expected time to fix and residual risk if unresolved.

How to embed the ledger: governance, tooling and commercial levers

Embed the ledger into three controls: (1) the appraisal and funding committee must refuse unconditional approvals; (2) the delivery control room must update the ledger as a single source of truth and link it to test management and defect systems; and (3) the commercial function must ensure contract terms map to ledger entries (acceptance criteria, reversibility, TSAs). Use tooling that supports traceability (requirements/issue trackers integrated with the ledger) and require supplier evidence artefacts to be machine readable where possible. Where tooling is not available, the minimum is a controlled spreadsheet with change history and sign‑off workflow.

Antares recommended actions

These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.

1. 1. Require a dependency ledger in every executive evidence pack. Do not accept a visual-only dependency diagram. The ledger must include owner, evidence status, failure effect and commercial lever for every mandatory dependency. Condition: refuse tranche release without ledger entries for all mandatory dependencies.
2. 2. Define three mandatory dependency outcomes for approvals: SATISFIED (all evidence and contractual levers in place), CONDITIONAL (named mitigations, quantified exposure, and binding date for evidence), or BLOCKED (do not approve). Each approval must include the decision authority for moving a dependency from CONDITIONAL to SATISFIED.
3. 3. Assign explicit owners and escalation routes. Each ledger entry must name a role within an internal function or a named supplier representative; if the owner is external (e.g., a regulator), require a named liaison and a documented timetable for the regulatory step. Escalate ownerless dependencies to the SRO within 48 hours.
4. 4. Link the ledger to acceptance artefacts. For data or interface dependencies, require test certificates, sample reconciliation outputs, signed API conformance reports and a runbook that describes recovery steps and return‑to‑service criteria. Without these artefacts, mark the dependency as BLOCKED.
5. 5. Translate dependencies into contract levers. Ensure supplier contracts contain acceptance criteria, reversibility options, transition services and explicit remedies aligned to ledger entries. Where suppliers cannot commit, condition funding and plan for alternative paths (in‑house, replacement supplier, or deferred scope).
6. 6. Make the ledger a live input to NISTA/DCA or equivalent assurance reviews. Where a project sits on the Government Major Projects Portfolio, require independent assurance to validate that ledger states match source evidence before Treasury approval or tranche release.
7. 7. Test a subset of dependencies under realistic failure scenarios. Use tabletop or live integration tests for chains of critical dependencies and record outcomes. If a chain fails, require a revised mitigation plan and do not permit unrestricted funding until tests demonstrate recovery capability.