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.