PROJECT MANAGEMENT WORKSHEET
Companion: https://www.spaceoffice.ai/blog/project-management
Version: 2026-10-20

COPYABLE PROJECT BRIEF
Project / owner:
Purpose and expected business outcome:
Deliverable:
Approved facts, files, systems, and access:
Included scope:
Explicit exclusions:
Acceptance criteria and evidence required:
Work package | responsible owner | prerequisite | review date:
Resource limits, owner review time, and assumptions:
Risk | possible effect | response owner | next check:
Issue | current effect | decision needed | decision owner:
Change request | effect on scope/time/resources | owner decision:
Delivered artifact and test record:
Unresolved limits and deferred changes:
Human acceptance and release authorization:
Operating owner, fallback contact, and restore/repair route:
Business outcome review date and measurement definitions:

FICTIONAL WORKED EXAMPLE — NOT A BENCHMARK OR CUSTOMER RESULT
Project: bicycle repair shop service-request page.
Owner: shop owner; accepts business facts, access, changes, and release.
Hydrogen: coordinates work and reviews the returned packet.
Chromium: approved frontend implementation.
Carbon: QA checks and verification of revised candidate.
Input: approved copy and an existing, authorized form endpoint.
Fields: name, email, bicycle category, repair request.
Next step: owner reviews the enquiry and responds; no confirmed booking.
Excluded: payments, live availability, automatic quotes, customer accounts.

ILLUSTRATIVE TEN-WORKING-DAY PLAN (INCLUDES WAITING AND REVIEW)
Day 1: owner supplies brief and inputs.
Day 2: Chromium drafts layout; Carbon prepares checks.
Day 3: owner reviews layout.
Days 4-5: Chromium builds and integrates the approved endpoint.
Day 6: Carbon checks the candidate.
Day 7: Chromium fixes frontend failures; owner resolves endpoint configuration.
Day 8: Carbon reruns all ten checks.
Day 9: owner reviews evidence and accepts or requests revision.
Day 10: owner authorizes release and operating handoff.

TEN ACCEPTANCE CHECKS
1. Approved service copy is present.
2. Enquiry is distinguished from confirmed booking.
3. Phone layout works.
4. Keyboard operation works.
5. Fields have useful labels.
6. Required-field validation works.
7. Errors help the visitor correct the request.
8. Submission reaches the intended inbox through the existing endpoint.
9. Confirmation truthfully describes what happened.
10. A fallback contact route is available.

FICTIONAL REVIEW RECORD
First pass: seven pass, three fail (keyboard, validation, inbox delivery).
Chromium fixes keyboard and validation; owner fixes existing endpoint settings.
Carbon reruns all ten; all pass in this invented example.
New payment request: defer and scope separately; do not silently add it.
Assumed owner time: 2h brief + 1h layout + 2h acceptance + 1h release = 6h planned.
Assumed extra endpoint work: 1h; total illustrative owner time = 7h.
These are teaching assumptions, not measured delivery time or savings.
Final acceptance and release still require the owner's recorded decision.