Delivery Process Definition — Personal Training OS¶
Document type: Project Management Plan / Ways of Working (the "how we run this project") Owner: Delivery Manager (Primary User) Date: 2026-07-03 Status: Draft v0.1 — defines the process we will then step through
This is a PM-owned governing document. It defines the lifecycle, the phase gates, the artifacts each phase produces, who owns them, and how we control risk, change, and quality. In industry this is the artifact a Project/Programme/Delivery Manager writes first and is assessed on. We are writing it now — deliberately — to recover the initiation/planning steps we skipped by opening with requirements.
1. Purpose & the learning frame¶
This project builds a Personal Training OS in Notion. It is also a deliberate exercise in running a delivery the way industry does. For that reason we assign roles explicitly:
| Role | Who plays it | Responsible for |
|---|---|---|
| Sponsor | Primary User | Funds/authorizes, owns the business case, approves gates |
| Delivery / Project Manager | Primary User (learning focus) | Initiation, planning, RAID, schedule, stakeholders, governance, reporting, gate approvals |
| Product Owner | Primary User | Prioritizes scope, accepts requirements |
| Delivery team (BA / Architect / Engineer / QA) | Claude | Elicits & writes requirements, designs, builds, tests |
| End users | Primary User, Secondary User | Use the system; provide validation |
The learning target is the Delivery Manager column. Each artifact ships with a study-guide
note (learning/study-guide.md) explaining the PM competency it exercises.
2. Methodology & tailoring¶
We use a hybrid stage-gate + agile lifecycle — the most common real-world pattern and the most defensible in interviews:
- Stage-gate governance (PRINCE2 / PMBOK flavour): the project moves through phases separated by gates; a gate is a go/no-go decision with explicit entry/exit criteria. This gives auditable control.
- Agile delivery inside the Build phase (Scrum/Kanban flavour): implementation is done in short iterations with a backlog, a Definition of Done, and demos.
Tailoring (itself a PRINCE2/PMBOK principle) — because this is a one-person project, we scale down ceremony but keep the artifacts: a "Change Control Board" is a pull request; a "stakeholder meeting" is a self-review; a "sprint" is a work session. We keep the discipline, drop the overhead.
Framework vocabulary this maps to (for interviews/resume): PMBOK 7 performance domains, PRINCE2 stages & tailoring, Scrum (PO/backlog/DoD), Kanban (flow/WIP), stage-gate.
3. Lifecycle phases & gates¶
Each phase lists its exit gate — the go/no-go the Delivery Manager runs before proceeding.
| # | Phase | Purpose | Key artifacts | Exit gate (go/no-go) |
|---|---|---|---|---|
| 0 | Initiation | Decide the project is worth doing & authorize it | Project Charter, Stakeholder Register + RACI, Business Case, high-level Scope | G0: Charter approved by Sponsor |
| 1 | Planning | Define how it will be run & controlled | RAID log, MoSCoW prioritization, Roadmap/milestones, Backlog/WBS, Comms plan, DoR/DoD, Quality & Change-management plan | G1: Baseline plan approved |
| 2 | Requirements | Define what (✅ mostly done) | EARS reqs (spec/), + backfill: NFRs, personas/user stories |
G2: Requirements baselined (tagged) |
| 3 | Design | Define the solution (✅ mostly done) | Design elements (spec/design), + backfill: ADRs, privacy/threat notes |
G3: Design reviewed & coverage 100% |
| 4 | Build | Implement in Notion (agile iterations) | Working Notion workspace, iteration demos | G4: All must-have reqs built |
| 5 | Verification & Validation | Prove it meets requirements | Test plan, req→test traceability, executable specs, UAT sign-off | G5: Tests pass; UAT accepted |
| 6 | Release | Go live safely | Release notes/CHANGELOG, runbook, backup/recovery plan, go-live checklist | G6: Released & backed up |
| 7 | Closure | Capture value & learning | Retrospective / lessons learned, benefits realization, post-implementation review | G7: Project closed |
4. Cross-cutting governance & controls (run in every phase)¶
- RAID log — Risks, Assumptions, Issues, Dependencies; reviewed each work session.
- Change control — any change to a baselined artifact goes through a PR (our Change Control Board); impact analysis required (see the Mach 5→6 change as the worked example).
- Decision log — significant decisions recorded (ADRs for technical, decision-log for PM).
- Status reporting — a lightweight RAG (Red/Amber/Green) status per work session.
- Configuration management — everything in git; baselines marked with git tags.
- Quality gates —
build.ps1(StrictDoc export + requirement→design coverage) must pass; later, CI runs it on every push, and the verification suite gates releases. - Metrics/KPIs — requirements coverage %, requirements volatility (churn), open risks, scope status (must-haves done / total).
5. Definition of Ready / Definition of Done (project-level)¶
Ready (a work item may start when): it traces to a requirement UID, has acceptance criteria, has a priority (MoSCoW), and no blocking dependency is open in the RAID log.
Done (a work item is complete when): built as specified, its requirement's verification
passes, artifacts updated & consistent (no duplication drift), committed, and build.ps1 green.
6. Tooling map¶
| Need | Tool |
|---|---|
| Requirements & design (source of truth) | StrictDoc (spec/) |
| PM artifacts, narrative | Markdown in git (pm/, docs/) |
| Version control / change control / audit | git + pull requests |
| Build & quality gate | build.ps1 → (later) GitHub Actions CI |
| Implementation target | Notion |
| Verification | (later) executable specs vs Notion API |
7. Current status — process recovery¶
We entered at Phase 2 (Requirements) and have completed Phases 2–3. We are now backfilling Phases 0–1 (Initiation, Planning) out of order — a real situation PMs face ("the project started before it was properly chartered; recover the governance"). After backfill we resume forward at Phase 4 (Build).
Sequence from here: Phase 0 → Phase 1 → (retro-fit 2 & 3 gaps: NFRs, personas, ADRs) → Phase 4 Build → Phase 5 V&V → Phase 6 Release → Phase 7 Closure.
See pm/backlog.md for the concrete artifact-by-artifact plan and status.