The 2001 Key Organization archive framed project and event planning around missed handoffs and deadlines. The modern lesson is still useful: make promises only after the work and the people available to do it are visible.
Start with the outcome and the hard constraints
Write the smallest useful outcome in one sentence. Then list the deadline, quality or safety requirements and the resources that cannot be increased quickly. Separate hard constraints from preferences. 'Launch by Friday to meet a contractual date' is different from 'Friday would be nice'.
Break the outcome into a handful of deliverables rather than a hundred tiny tasks. For each deliverable, name an owner, an input and a review point. A plan is not complete if it assigns work to a role that has no time, access or authority to do it.
- Name the smallest outcome that still delivers value.
- Mark hard constraints and optional scope separately.
- Check the owner's actual availability before assigning work.
Expose dependencies before they block the finish
Draw the order of work: a draft may depend on customer evidence; translation on an approved draft; publication on accessibility review. Mark where a delay in one step blocks several others. Give the owner of each dependency a clear request and a date when the project lead must know if it will arrive.
Do not treat a risk register as a place to list every imaginable disaster. Track the few conditions that would change the plan and the decision that follows. If evidence is missing by Tuesday, will you narrow the claim, delay publication or obtain another source? A named choice is more useful than a red status light with no action.
- Show each critical input and its provider.
- Set an early decision point before the final deadline.
- Write the scope change triggered by a missing input.
Make the trade-off before the final week
Compare the work requested with the available time, including ordinary support and recovery from errors. If the gap is real, choose openly: reduce scope, move the date, add capacity with a real handoff or stop lower-priority work. Asking the same people to work invisibly harder is not a plan.
Review the project at a fixed, short cadence. Ask what changed, which dependency is at risk and who can decide a trade-off. Keep one current page with the outcome, owners and choices. When the project ends, record one assumption that proved wrong and change the next plan accordingly.
- Choose the trade-off while options still exist.
- Publish one current plan instead of parallel versions.
- Learn from one mistaken assumption after delivery.
The capacity-first project card
This one-page card helps a small team decide what is possible before accepting every request.
- Outcome
State the minimum useful result and the hard date or standard.
- Owners
Name the people, their available time and their authority.
- Dependencies
List the inputs that can block the critical path.
- Trade-off
Agree what will shrink, move or stop if an input is late.
Fictional example: a museum wants a multilingual event page in two weeks. The team can complete the programme, booking information and accessibility details, but not a full illustrated guide in four languages. They launch the essential page in two languages, book translation of the remaining languages for a dated update and keep the guide out of the first release. The decision is visible before design work begins.
Do not use the card to justify unsafe workloads. If capacity remains insufficient for the minimum safe outcome, renegotiate the commitment.
Sources and context.
Archive captures show the older question, not a current endorsement or an article to reproduce. The other links provide research or platform context; check dates and local requirements before applying them.
A reserve that changes what you promise
An empty space in a calendar is easily sold twice. Make support work a visible part of the capacity agreement. The fictional week below uses hours, not a recommended staffing ratio; replace them with your team’s records.
- Start with agreed working hours and subtract leave, meetings and other commitments before estimating delivery capacity. Do not count the same hour in two categories.
- Review recent support interruptions by week, including who handled them. Choose a provisional reserve and record why it fits this period; an average alone can hide a difficult week.
- Agree what happens when the reserve is exhausted. Name the person who can defer a planned task, arrange cover or renegotiate a date. Do not make overtime the automatic balancing item.
- Review actual support time and displaced work at the end of the week. Change the next agreement using that record, while keeping the original promise visible.
| Field | Example or check |
|---|---|
| Agreed week | 40 h; meetings and administration 8 h; available for support and delivery 32 h. |
| Protected support reserve | 6 h, a provisional choice in this example. Delivery promise = 32 − 6 = 26 h. |
| Busy-week scenario | Actual support 9 h. The extra 3 h displaces 3 h of the 26 h delivery promise: revised delivery 23 h. |
| Decision record | Tuesday review: coordinator defers the draft handover by 3 h and tells its recipient. No unrecorded extra hours. |
| Blank agreement | Period __; agreed hours __; other commitments __; reserve __; trigger __; decision owner __; revised promise __; review __. |
A reserve is useful only if its trigger changes a commitment. Six hours is an illustrative planning choice, not evidence that it will cover your next week.
Accept the request only after making room for it
The reserve above protects a week; this intake card decides whether a particular request can enter it. Do not turn an estimate into a promise merely because somebody marked the request urgent.
- Record a deliverable, its recipient, a genuine deadline and the consequence of waiting. Ask for a missing input before reserving delivery time.
- Name the person who can accept the result and the owner who has time to do the work. Compare the estimate with usable blocks, not just a weekly total.
- Choose accept, clarify or defer. If accepting displaces something, name the displaced commitment and inform its recipient before confirming the new date.
- Record the decision, its reason and the next review. A deferred request still needs a route back into consideration.
Fictional intake: Thursday has one three-hour delivery block. Request A needs two uninterrupted hours to correct a published contact sheet; the source file and an approving recipient are available. Request B needs two hours for an optional poster, but its wording is unapproved. Accept A, leaving one hour. Return B for clarification; it cannot fit the remaining block even after approval. No overtime is silently added.
Reply: “I can deliver the corrected sheet on Thursday. The poster needs approved wording and a separate two-hour block. Please confirm the wording; we will review its place on Friday.” Record: request __; input __; estimate and block __; decision __; displaced work __; owner __; review __. This is an planning exercise, not a staffing standard.
Source: www.hse.gov.uk.