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

A decision has been taken and documented. Yet measurable time passes before it actually changes the work. Many programmes steer the documentation of the decision, but not this period of time.

Observation

A pattern repeats itself in the steering rounds of large IT programmes. A decision is taken, properly minuted and filed in the decision log. Three weeks later, two workstreams are still working to the old state. This is rarely due to resistance. The decision has simply not reached the teams yet. The release plan has not been adjusted, the Jira board shows the old prioritisation, and the supplier is still waiting for the formal order.

What such programmes usually measure is the number of open and closed decisions. Hardly any programme measures how much time passes between the recognisable need for a decision and the work actually changing. This observation comes from our own practice in programme and PMO engagements. First studies on it begin in November 2026.

Context

Research on the failure of large programmes indirectly supports the relevance of this pattern. In the 2024 BCG study of around 1,000 companies in 59 countries, around 60 percent of respondents name the absence of an active PMO as a central cause of large technology programmes failing. This refers to a PMO that monitors value delivery and identifies emerging risks.

A PMO that only documents decisions is passive in this sense. It administers what has been decided, but does not track whether the decision takes effect. The link between the BCG finding and the concept of decision latency is our own interpretation and not a statement of the study.

Two studies on project governance show that steering works through decisions. Turner (2020) examined in six case studies how governance influences decisions in projects. He concludes that governance should above all create a framework in which competent people can make good decisions. Sirisomboonsuk and colleagues (2018) analysed 282 responses from a survey. According to their results, both IT governance and project governance are positively related to project performance, and their alignment with each other supports performance further. Neither study measures how long a decision takes until it takes effect. The conclusion that this period of time is also a lever of governance is our own derivation.

The term: Decision Latency

Decision latency describes the period between recognising the need for a decision and the moment at which the decision taken changes the actual work. It can be divided into five measurable phases.

1. Recognition: A topic is recognised and named as requiring a decision. It is therefore not merely tracked as a risk or open item.
2. Decision readiness: Options, consequences and a recommendation are available. This phase often takes longest, because nobody is explicitly responsible for it.
3. Committee date: The decision waits for the next meeting of the responsible committee. If the committee meets monthly, a topic waits two weeks on average, regardless of how urgent it is.
4. Communication: The decision reaches everyone whose work it affects, including suppliers and adjacent workstreams.
5. Implementation: Plans, boards, backlogs, contracts and processes reflect the new state.

This breakdown shows in which phase time is lost, and only then can the overall duration be steered. A programme with fast committees in which nobody is responsible for decision readiness has a different problem from a programme that decides quickly but does not transfer the decisions into its tools.

Four causes of decision latency

The five phases show when time is lost. Equally important is the question of why this happens. In practice, four causes can be distinguished, and each calls for its own countermeasure.

1. Information latency: The decision cannot be taken because data, costs, risks or impacts are missing. Remedies are minimum requirements for decision papers, a named responsibility for preparation and access to the leading source systems.
2. Authority latency: It is unclear who may decide. The remedy is a model of decision rights with thresholds for budget, scope, risk and architectural impact and with clear escalation levels.
3. Capacity latency: The person authorised to decide has no time, or the committee meets too rarely. Remedies are asynchronous approvals, delegated decision rights and extraordinary meetings before critical dates.
4. Conflict latency: The decision is not taken because those involved pursue different goals. It helps to make the conflict of goals transparent, to define a decision principle and to let the sponsor or business owner decide on the basis of the prioritised project goals.

Application in projects

The following three practices come from project work. Their effect has not yet been tested systematically.

• Decision log with latency fields: Besides title, owner and status, the decision register receives three date fields. They record when the need was recognised, when the decision was taken and when implementation was confirmed. Even a simple analysis of these fields shows where the programme regularly loses time.
• Decision readiness as an entry criterion: A topic only goes on the committee agenda once options, consequences and a recommendation are available. A named role is responsible for establishing this readiness. This shortens the second phase and avoids postponements.
• Escalation levels with a time budget: Each escalation level receives a fixed time budget, for example five working days at workstream level. After that, the topic is automatically submitted to the programme board. This way, no decision waits silently for the next regular date.

Possible metrics

Once latency is recorded, it can be analysed like a lead time. Five metrics lend themselves to this.

• The median decision latency is the average time between decision readiness and resolution.
• The critical decision latency is the decision time for topics with a major impact on dates, budget or risks.
• The decision reopen rate is the share of decisions already taken that are reopened without new facts.
• The decision implementation lag is the time between resolution and actual implementation.
• Cost of waiting describes the estimated costs caused by blocked resources, parallel work, rework, missed dates and extended supplier assignments.

The metrics are not meant to accelerate decisions artificially, because a fast wrong decision remains wrong. They are meant to make unnecessary waiting time visible.

An effective decision paper

A decision paper does not have to document the entire background. It should answer seven questions.

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

The last question is particularly important. It is often assumed that without a decision the status quo simply remains. In fact, not deciding is also a decision, often one for delay, higher costs or growing risks.

Limits

Decision latency is a term from practice and not an empirically validated construct. The division into phases is a working hypothesis from project experience. Not every decision should be accelerated. For questions that concern architecture or contracts, longer preparation is often time well invested. The measurement itself also causes effort. In small projects with short communication paths, a decision log with latency fields is therefore rarely worthwhile. The approach is aimed at programmes in which decisions pass through several committees, suppliers and systems. From November 2026, the model will be tested in two online experiments and a survey.