From Ask to Ink: Putting Approval Waiting Time on the Delivery Plan

Most delivery plans are competent at recording that an approval is required. They are far less competent at recording how long the approval actually takes. A milestone may be entered for a business case, a design decision, a purchase order or a change request, but the elapsed time between the request being raised and the signature being given is rarely treated as a delivery constraint. It sits in the plan as an administrative interlude, during which the programme is technically waiting but no one is accountable for the wait.

That omission matters. In UK delivery programmes, approval is often a queue disguised as a step. The work is ready; the decision is not. The plan shows a gate at the end of a phase, but not the days or weeks spent assembling papers, chasing comments, waiting for a forum to meet, correcting a submission that was incomplete, or locating the person with delegated authority. The result is a familiar pattern: delivery teams report that they are waiting on governance, while governance reports that it has not yet received a complete request. Both statements can be true. Neither is measured.

The plan records a gate, not a duration

A milestone is a date, not a duration. That distinction is easy to overlook when a plan is built around deliverables and decision points. The approval milestone tells the reader when a decision is expected; it does not tell them how long the approval route will take, how many requests are already ahead of it, or how often the route returns work for correction. Without that information, the plan presents approval as an event rather than a process.

The practical consequence is that delivery teams estimate the work and then add a vague allowance for sign-off. The allowance is usually based on memory, precedent or optimism. It is rarely based on observed queue data. When the approval takes longer than expected, the delay is attributed to governance generally rather than to a specific stage that can be redesigned. Approval latency remains a background condition rather than a managed constraint.

Why waiting time belongs on the critical path

Approval latency is not just an administrative inconvenience. It consumes float, distorts forecasts and encourages teams to submit early or incompletely just to start the clock. When waiting time is invisible, capacity planning becomes fictional: the team appears to have slack because the plan only shows work, not the queue in front of it. It also hides the true cost of governance design. A monthly board cycle may be appropriate for major investment decisions, but it is a poor fit for routine change approvals. Without queue data, organisations cannot tell the difference.

There is a behavioural effect as well. If approvers are measured only on the quality of their decisions, and never on the time taken to reach them, the system rewards thoroughness without regard to flow. If requesters are measured only on delivery dates, they may submit incomplete papers to shift the perceived delay elsewhere. Neither behaviour is unreasonable in the absence of a shared measure. The measure itself changes the conversation from individual diligence to end-to-end elapsed time.

Instrumenting the request-to-signature cycle

The measurement does not require a large system. It requires a small number of consistent timestamps and a clear definition of the request. Start with a pilot covering one or two approval types, such as change requests or purchase orders. Record the date and time a complete request is submitted; the date and time it is assigned to an approver; the date and time of first response; the date and time of signature; and any return for rework. The clock should start at the point the request is genuinely complete, not when someone first mentions it. That distinction prevents the queue from being hidden inside preparation.

A complete request needs a checklist, not a judgement call. For a change request, that might mean a defined scope, an impact assessment, a cost estimate and confirmation of funding. For a purchase order, it might mean an approved specification, a supplier reference and budget confirmation. If a request is incomplete, record that as a separate preparation delay rather than allowing it to pollute the approval measure. The aim is to distinguish between time spent making the request fit for decision and time spent waiting for the decision itself.

Use existing tools where possible: a shared register, a workflow tool already in use, or a simple form that writes to a spreadsheet. The aim is a reliable elapsed-time dataset, not a perfect system. Weekly review of the register is enough to expose patterns. The data should be visible to both requesters and approvers, because the purpose is to improve the route, not to create a private scorecard.

Service-level expectations for approvers

Measurement without expectation can become observation without consequence. Agree a service-level expectation for each approval type: for example, a first response within two working days and a decision within five, subject to completeness and delegated authority. The expectation should specify what counts as a valid request, who can sign in the approver's absence, and how escalation works when the expectation is missed. It should also distinguish between a decision and a request for more information; otherwise, a polite holding response can stop the clock without advancing the work.

These expectations are not a performance-management device for individuals. They are a design parameter for the delivery system. If a five-day expectation is routinely missed because the approval forum meets monthly, the forum design is the issue, not the diligence of the approver. If requests routinely arrive incomplete, the issue may be the template or the pre-submission conversation. Service-level expectations make those design questions visible and testable.

Using queue data without turning it into a blame exercise

Queue data is most useful when it is aggregated and used to improve flow. Compare median and 90th-percentile waiting times by approval type, team and route. Look for batching, where approvals wait for a weekly meeting; for orphaned requests, where ownership is unclear; for rework loops, where incomplete submissions return more than once; and for cover gaps, where leave or turnover creates a silent backlog. Present the findings as a map of where momentum disappears, not as a league table of slow signatories.

In UK organisations, this matters because approval authority is often distributed across finance, legal, commercial and technical functions. No single team owns the end-to-end queue. A delivery lead may see only the final wait, while each function sees only its own inbox. The queue data provides the shared view that is otherwise missing. It also gives the PMO a more useful role: not simply collecting status, but exposing the elapsed time between a request and a decision and helping the organisation redesign the route.

A modest start

Begin with a 30-day pilot. Select two approval types that materially affect delivery. Define completeness, start and stop points, and the service-level expectation. Capture timestamps in a single register. Review the data weekly with approvers and delivery leads. At the end of the pilot, answer three questions: where does waiting time accumulate, which rework loops are avoidable, and which approval routes need redesign? Then decide whether to extend the measure to other approval types.

The signature is not the step. The queue before it is. Treating approval latency as a measurable delivery constraint gives UK programmes a clearer view of where time goes, a fairer basis for setting expectations, and a practical route to recovering momentum that is currently lost in the wait.