Decision Latency: Why documented decisions still take effect too late.

Between “the decision is made and documented” and “the decision changes the work” lies a measurable latency. Most programmes steer the documenting — not the latency.

Observation

In steering meetings of large IT programmes, one pattern recurs: a decision is made, cleanly minuted, filed in the decision log — and three weeks later two workstreams are still working to the old state. Not out of resistance, but because the decision has simply not yet reached them: the release plan was not adjusted, the Jira board shows the old prioritisation, the supplier is waiting for the formal instruction.

What is striking is what gets measured in such programmes: the number of open and closed decisions. What is almost never measured: the time between the moment a need for a decision became apparent and the moment the decision made actually changed the work. This observation stems from my own project practice in programme and PMO mandates; it is not a research finding.

Context

Research on programme failure supports the relevance of the pattern indirectly. In the 2024 BCG study of more than 1,000 companies across 59 countries, around 60 per cent of respondents name the absence of an active PMO — one that monitors value delivery and identifies emerging risks — as a central cause of failure in large technology programmes.¹ A PMO that merely documents decisions is, in this sense, passive: it administers the state of the resolution, not its effectiveness. The connection between this finding and the notion of latency described here is my own interpretation, not a statement of the study.

The governance research likewise suggests that steering impact arises primarily through the quality and speed of decisions. Turner (2020), in analysing six case studies, concludes that governance above all creates an environment in which competent people can make effective decisions — the relationship between governance and project outcome thus runs substantially through the decision architecture.² Sirisomboonsuk and colleagues (2018) found, on the basis of 282 usable responses, that both IT and project governance are positively associated with project performance — and that it is precisely their mutual alignment that supports performance.³ And the meta-analysis by Tubre and Collins (2000) shows that role ambiguity correlates negatively with performance⁴ — particularly relevant for temporary programme structures with overlapping responsibilities, where it often remains unclear who is even permitted to decide an open question.

The concept: Decision Latency

Decision Latency denotes the span of time between recognising a need for a decision and the moment the decision made has changed the actual work. It breaks down into five measurable phases:

1. Recognition: A topic is identified and named as requiring a decision — not merely tracked as a risk or open point.
2. Decision readiness: Options, consequences and a recommendation are in place. Often the longest phase, because no one is explicitly responsible for it.
3. Committee meeting: The decision waits for the next meeting of the responsible committee — on a monthly cadence, two weeks of waiting on average, irrespective of urgency.
4. Communication: The decision reaches everyone whose work it changes — including suppliers and adjacent workstreams.
5. Implementation: Plans, boards, backlogs, contracts and processes reflect the new state.

The point of this breakdown: the total latency becomes steerable as soon as it is visible in which phase time is being lost. A programme with fast committees but no ownership of decision readiness has a different problem from one that passes resolutions but does not get them into the tools.

Four causes of Decision Latency

The five phases show when time is lost. Equally important is why. In practice, four types of cause can be distinguished — each calling for a different countermeasure:

1. Information latency. The decision cannot be made because data, costs, risks or impacts are missing. Remedy: minimum requirements for decision papers, a named responsibility for preparation, access to the leading source systems.
2. Authority latency. It is unclear who is permitted to decide. Remedy: a decision-rights model with thresholds by budget, scope, risk and architectural impact, together with unambiguous escalation levels.
3. Capacity latency. The role with decision authority has no time, or the committee meets too infrequently. Remedy: asynchronous approvals, delegated decision rights, extraordinary meetings for critical deadlines.
4. Conflict latency. The decision does not fall because stakeholders pursue different goals. Remedy: surface the goal conflict, define a decision principle, and let the sponsor or business owner decide against the prioritised project objectives.

Application in projects

Three practices have proven their worth in project work:

• Decision log with latency fields. Alongside title, owner and status, the decision register gains three date fields: need recognised, decision made, implementation confirmed. Even a simple analysis of these fields reveals where the programme structurally loses time.
• Decision readiness as an entry criterion. A point only reaches the committee agenda once options, consequences and a recommendation are in place — and there is a named role that establishes this readiness. That shortens phase 2 and prevents deferrals.
• Escalation levels with a time budget. Each escalation level is given an explicit time budget (for example: five working days at workstream level, then an automatic submission to the programme board). Decisions no longer wait silently for the next regular meeting.

Possible metrics

Once the latency is captured, it can be analysed like a lead time. Five metrics have proven meaningful:

• Median Decision Latency — the median time between decision readiness and resolution.
• Critical Decision Latency — the decision duration for topics with high deadline, budget or risk impact.
• Decision Reopen Rate — the share of decisions already made that are reopened without new facts.
• Decision Implementation Lag — the time between resolution and actual implementation.
• Cost of Waiting — estimated costs from blocked resources, parallel work, rework, missed deadlines and prolonged supplier engagements.

These metrics are not meant to accelerate decisions artificially — a fast wrong decision remains wrong. Their purpose is to make unnecessary waiting time visible.

An effective decision paper

A decision paper should not primarily document the entire background, but answer seven questions:

1. What is to be decided?
2. By when is the decision needed?
3. What realistic options are there?
4. What is the impact of each option?
5. What does the responsible team recommend?
6. Who holds the decision right?
7. What happens if no decision is made?

The last question is especially important. Non-decision is often treated as if the status quo simply persists. In fact it is itself a decision — frequently one for delay, higher costs or growing risks.

Limitations

Decision Latency is a practitioner concept, not an empirically validated construct; the phase breakdown is a working hypothesis drawn from project experience. Not every decision benefits from acceleration — for architecture- or contract-critical questions, a longer readiness phase is often the right investment. And the measurement itself creates effort: in small projects with short paths, an instrumented decision log is rarely worthwhile. The approach is aimed at programmes in which decisions must pass through several committees, suppliers and systems.