Most project updates fail before anyone reads them. Not because the content is wrong — because the format forces the reader to reconstruct the picture from noise.
Buried decisions. Action items with no owner. Dates scattered in paragraphs. Status somewhere between “we discussed it” and “it’s done.”
The fix isn’t a new tool. It’s a formatting standard with three structural moves.
The structure
A project update has exactly two sections: Decisions and Actions. Not one combined list. Not a narrative paragraph. Two sections, each with a different job.
Decisions are commitments that change direction. They are recorded once, dated, and never revisited unless reversed. Actions are tasks — with a date, an owner, and a status. The moment you separate these two, accountability sharpens immediately.
The date is the anchor
Every entry starts with a bold date: Jan 22: — not buried mid-sentence, not appended at the end. Leading it. This makes every entry chronologically sortable and separates what from when at a glance.
Items are always listed in chronological order. Year is omitted by default. Technical terms are preserved exactly — Examples: a dimension 3mm stays 3mm, a part code PL-456 stays PL-456.
If a date slips, you don’t rewrite the entry. Strike the original, append the new:
Feb 10
Jan 14: Release updated harness drawing to supplier @Anita
One line. Full traceability. No explanation needed.
Status lives in a symbol
Three states. That’s it.
- ✅ Done. Dated prior to today. Retained for traceability — don’t delete closed items.
- ⚠️ At risk or blocked. Prefix the line with the warning symbol.
- TBD: Date is genuinely unknown. Used sparingly. Listed at the bottom of the section.
Pending actions carry no symbol — just a date of today or later. If the reader has to read a sentence to understand the status, the format has already failed.
What it looks like
Decisions
Jan 18: Proceed with PL-456 connector standardisation across product Gen 4
Jan 20: Limit re-validation only to IP testing
Actions
✅ Jan 19: Freeze product mechanical interface @ENG
⚠️ Jan 22: Validate PL-456 connector tolerance at 3mm @Testing
Jan 24: Confirm power availability at test rig (500 kVA cap) @OPS
Feb 10 Jan 14: Release updated harness drawing to supplier @ENG
TBD: Confirm vehicle allocation for on-road durability run @Program
No paragraphs. No bullets. No status prose. The format does the work.
How this relates to the CBU
If you’ve read the previous post on CBU (Caveman Board Update) — this is its sibling, not its replacement.
CBU compresses a situation to its minimum legible form: problem, impact, decision, action. It’s a verbal format. Built for leadership rooms, not async logs.
The Project Update Standard is the written record. It’s built for traceability — so three months later, you can reconstruct exactly what was decided, when it slipped, and who owned what. CBU gets you to alignment fast. This format keeps you honest after.
Use CBU to communicate up. Use this to run the work.
The principle
A project update should read like a ledger, not a memo. Dated. Owned. Traceable. One line per entry.
The standard isn’t the bureaucracy. The absence of one is.