The One-Page Record That Stops UK Projects Going Sideways

Most UK projects do not fail with a bang. They drift. A choice made on a Tuesday call becomes three slightly different truths by Friday, and by the end of the month someone is rebuilding something that was already signed off. The cause is rarely laziness. It is memory, inboxes and the very human habit of assuming everyone heard the same thing.

The fix is not a 40-tab governance workbook. It is a decision log: one page, plain English, recording who decided what, when and why. Clients should ask for one. Suppliers should offer one before anyone asks. It is one of the cheapest forms of project insurance going.

Why decisions go missing in UK projects

Small and mid-sized UK businesses tend to move quickly. Decisions get made in a Teams call, over a coffee, in a reply-all email chain or in a WhatsApp group that was meant to be temporary. That speed is often a strength. The problem starts when those decisions need to be recalled weeks later by someone who was not in the room.

A supplier remembers agreeing to one extra report. The client remembers asking for a small tweak. The project manager remembers a number being mentioned but not what it covered. Nobody is lying. They are working from different records, and the most unreliable record is memory.

A decision log does not assign blame. It gives everyone a shared reference point. It also helps when someone new joins the project, when a client contact changes role, or when an invoice needs to be checked against what was actually agreed.

What belongs in the log — and what does not

The log should capture decisions that change scope, cost, timing, risk or acceptance criteria. It should not become a task list, a status report or a diary of every minor conversation. If a decision would be expensive or awkward to reconstruct later, it belongs in the log. If it is just a progress update, leave it out.

The test is simple: would a reasonable person need to know this decision in three months to understand why the project looks the way it does? If yes, log it.

A one-page template you can copy

Keep the structure deliberately boring. Boring is easy to maintain.

• Decision ID: D-001, D-002 and so on.
• Date: the date the decision was actually made.
• Decision: one or two sentences in plain English.
• Decided by: a named person, not a department.
• Why: the reason, constraint or trade-off behind the choice.
• Impact: what changes in scope, cost, timing or risk.
• Next step: who needs to do what, and by when.

Here is an example entry:

• Decision ID: D-004
• Date: 14 October 2026
• Decision: Use the standard booking form rather than a bespoke one for phase one.
• Decided by: Priya Shah, operations director at the client.
• Why: The bespoke form adds two weeks and a four-figure build cost; phase one can launch with the standard version.
• Impact: Saves an estimated £3,500 and keeps the November launch on track.
• Next step: Supplier to confirm standard form by 18 October; client to review at phase one sign-off.

That is it. One page. No colour coding. No RAG status. No hidden formulas. If a decision changes later, add a new row. Do not rewrite history. The value of the log is that it shows the sequence of choices, including the ones that were later reversed.

Three moments to update it

A decision log only works if it is updated at the points where decisions actually happen. These are the three moments that matter most.

1. At the end of any call where a choice is made

This takes five minutes. If no choice was made, no entry is needed. If a choice was made, write it down before the call ends or immediately afterwards. Do not wait until the end of the week. By then the nuance will have gone.

2. When a change request, approval or sign-off lands

Link the log entry to the email, document or ticket. The email can stay in the inbox; the log becomes the index. This is especially useful on UK projects where a change is agreed verbally and then confirmed by email three days later. The log records the decision, not just the paperwork.

3. Before a milestone, invoice or handover

Do a ten-minute sweep. Has any decision been made since the last review? Add it. Has any decision changed? Add a new row. Has anything been assumed but not confirmed? Flag it. This small habit prevents the classic end-of-project conversation that starts with ‘I thought we agreed’ and ends with a difficult commercial discussion.

How to introduce it without adding bureaucracy

Suppliers should mention it at kickoff. One sentence is enough: ‘We will keep a one-page decision log so we all have the same record. It does not replace the contract; it is just our shared memory.’ Clients should ask a simple question at the start of any project: ‘Where do we record decisions?’ If the answer is ‘in email’, suggest a log.

Keep the log visible and give it one owner. Review it at the start of the weekly call. Do not make it a collaborative free-for-all where everyone edits the same cells. A single owner can keep it clean, and anyone can challenge an entry.

The commercial upside

Fewer disputes. Less rework. Faster onboarding. Cleaner handovers. On UK projects where margins are tight, rework is the silent killer. A decision log also protects suppliers from being asked to absorb changes that were never agreed, and it protects clients from paying for work they did not authorise.

It is not a legal document and it does not replace a contract. It is a memory aid with commercial teeth. The best time to start one is at kickoff. The second-best time is now, before the next ‘quick catch-up’ turns into another unwritten decision.