The Delivery Plan That Exists Only on Paper
A workable policy delivery plan turns aims and action lists into clear roles, ordered tasks and reliable handoffs, so responsibility does not disappear.
Why does a policy delivery plan look complete in a document and still leave staff unsure what to do on Monday? Usually, it names an aim and lists actions but does not say who must do what, in what order, or what happens when one task is finished. A plan is not operational merely because its verbs sound busy.
What makes a delivery plan more than an action list?
A delivery plan connects a public commitment to the work that makes it real. It identifies the responsible people or units, the sequence of tasks, the information each task needs, and the point at which responsibility moves to someone else.
“Improve access to support” is an aim. “Publish guidance, train staff, open referrals” is an action list. A delivery plan clarifies which team drafts the guidance, who approves it, what staff need before training, when referral routes can accept cases, and who checks that the route is operating.
The distinction resembles a shopping list beside a recipe. The list may contain the right ingredients, but it does not say which ones must be prepared first or when they belong in the pan. In public services, the missing order is often the difference between an announced service and one a resident can actually use.
Who needs to own each action?
Every action needs a named owner at the level where the work can be directed. “The department” is rarely specific enough: departments contain teams with different authority, workloads and information. Naming a lead team, role or accountable office makes it possible to ask a useful question when progress stalls.
Ownership does not mean that one person performs every part. It means someone is responsible for coordinating the action, securing decisions and raising a blockage. The plan can identify contributors separately, so consultation does not blur accountability.
It should also show who can approve a change. If a local office encounters a rule that conflicts with a central instruction, staff need to know whether they can adapt the process or must seek a decision. Without that route, discretion may quietly become inconsistency—or a queue of unanswered emails.
How should actions be put in sequence?
Sequence should follow dependencies, not the order in which actions appeared in a meeting note. A team cannot train staff on final procedures before those procedures are agreed, and a referral service cannot accept cases before its intake route is ready.
For each action, ask what must already be true for it to begin and what must be true before the next team can use its output. These conditions expose dependencies: approval, usable guidance, access to records, staffing arrangements, or an agreed way to handle exceptions.
Then distinguish tasks that can happen in parallel from those that cannot. Communications work may proceed while a service is being configured, but public instructions should not promise a route that has not been confirmed. A plan that makes dependencies visible gives managers a chance to resolve them before they become operational surprises.
Where do handoffs commonly fail?
A handoff fails when work passes between teams without a clear package, recipient or acceptance point. One office may believe it has sent a completed referral; another may regard it as incomplete because essential information is missing. Both can be acting reasonably under different assumptions.
For each transfer, specify what is handed over, who receives it, how receipt is acknowledged, and what happens if the material is incomplete. Include the route for urgent or unusual cases if the programme needs one. A handoff is not complete just because an email has left the sender’s outbox.
Consider a fictional council planning a household support service. The policy team drafts eligibility rules, but local advisers must collect documents and a payment unit must process approved cases. If the plan says only “launch referrals,” advisers may send records in incompatible formats and the payment unit may have no agreed way to return a missing item. A defined referral package, receiving role and return route would let the teams identify the same gap and resolve it before residents are sent between offices.
What should a delivery plan say about capacity?
It should connect the work to the people, systems and authority available to do it. A plan can assign an owner and still be unrealistic if that team lacks time, access to necessary records, training or permission to make routine decisions.
Capacity is more than headcount. It includes the ability to interpret guidance, manage exceptions, maintain records and answer questions from partner organizations. Where work is shared with a contractor, nonprofit or local agency, the plan should state what each party is expected to provide and how unresolved issues reach the public authority responsible for the programme.
When capacity is uncertain, mark the assumption and identify who will resolve it. That is more useful than leaving a confident-sounding task in the schedule and hoping the necessary staff appear by force of typography.
What should managers check as delivery begins?
Managers should check whether the connections in the plan are working, not merely whether individual actions have been marked complete. A draft guidance document may be finished while approval is pending; training may be delivered while staff still lack access to the system they need.
A useful review asks whether owners are clear, prerequisites are met, handoffs are accepted, and exceptions have a route to resolution. It also checks whether the service is reaching the intended point of use: can the relevant staff explain the process, and can a person entering the service move through it without an unassigned step?
Keep a short record of decisions, blockers and changes to responsibility. When a task slips, record what depends on it and who needs to know. This helps distinguish a local delay from a problem that affects the whole delivery chain.
What questions help diagnose a paper-only plan?
Can a new staff member tell who owns the next action?
If the answer depends on personal knowledge or an old email chain, the plan has not made responsibility visible. Add the accountable team or role and a route for asking about unresolved ownership.
Does each action have a usable output?
“Engage partners” is difficult to hand over because it does not say what engagement must produce. State the output, such as an agreed referral route or a recorded decision, and name the person who accepts it.
Are prerequisites written beside dependent tasks?
A task that relies on approval, system access or completed guidance should say so. This lets managers see why a later action cannot start instead of treating the delay as an isolated failure.
Is there a route for exceptions and disputes?
Some cases will not fit the ordinary process, and partners may disagree about who should act. State who can decide, how an issue reaches them, and what staff should do while a decision is pending.
How can a plan be made usable without becoming bulky?
Use a compact delivery table rather than adding explanatory prose to every page. For each significant action, record:
- Action and output: what work is done and what it produces.
- Owner and contributors: who coordinates it and who supplies input.
- Prerequisite: what must be ready before work begins.
- Recipient: who uses the output next and how acceptance is confirmed.
- Blocker route: who resolves a delay, exception or disagreement.
Keep the table focused on work that affects delivery. Routine internal details can stay in team-level schedules, while dependencies between teams belong in the shared plan. If the document grows, make the links between tasks easier to follow rather than repeating the same description in several places.
Roles, sequence and handoffs are the working structure beneath a policy aim. A delivery plan earns its place when a person can use it to identify the next action, its owner, the material needed and the colleague who must receive the result. That is the practical test for a delivery plan: it should still make sense when the meeting ends and the work begins.
