Stakeholder Register & RACI — Personal Training OS¶
Artifact: 0.2 (Phase 0 — Initiation) · Owner: Delivery Manager (Primary User) Version: v1.0 · Date: 2026-07-03
Stakeholder analysis identifies everyone affected by or affecting the project, how much power/interest each has, and how you'll engage them. The RACI then pins who does what on each key activity so nothing is ownerless or double-owned.
1. Stakeholder register¶
| ID | Stakeholder | Role / interest | Power | Interest | Engagement strategy |
|---|---|---|---|---|---|
| S1 | Primary User | Sponsor + Delivery Manager + Product Owner + primary user | High | High | Drives everything; the project's single decision-maker |
| S2 | Secondary User | Co-user; her training/goals/metrics are tracked | Low–Med | High | Keep satisfied & engaged; confirm her needs; low-friction capture for her too |
| S3 | Future users (family / friends / kids) | Potential later users | Low | Low | Monitor; out of scope for v1 — design stays multi-person-capable |
| S4 | Notion (platform/vendor) | Hosts the system; pricing & API constrain us | High (external) | Low | Track plan/pricing & API limits; data kept API-portable as an exit path (risk R5) |
| S5 | Integration sources (Garmin, MyFitnessPal, Apple, Strava, Drive) | Future data providers | Med (external) | Low | Assess access/cost per source in Planning; no hard dependency (risk R3) |
| S6 | Delivery team (Claude Code / Notion AI) | Builds the system | Med | — | Resource, not a stakeholder in outcomes; directed by DM/PO |
2. Power / Interest grid (Mendelow)¶
high │ S4 Notion │ S1 Primary User
P │ (keep satisfied) │ (manage closely)
O │──────────────────────┼──────────────────────
W │ S3 future, S5 sources│ S2 Secondary User
E low │ (monitor) │ (keep informed/engaged)
└──────────────────────┴──────────────────────
low high
INTEREST
3. RACI matrix¶
R = Responsible (does it) · A = Accountable (owns it, one per row) · C = Consulted · I = Informed. Columns are roles; Primary User wears Sponsor + Delivery Manager + Product Owner.
| Activity | Sponsor | Deliv. Mgr | Prod. Owner | Team (Claude) | Users (Primary User+Secondary User) |
|---|---|---|---|---|---|
| Approve charter & phase gates | A/R | C | C | I | I |
| Prioritize scope (MoSCoW) | I | C | A/R | C | C (Secondary User) |
| Elicit & write requirements | I | A | C | R | C |
| Design the solution | I | A | C | R | I |
| Build in Notion | I | A | C | R | I |
| Verification & testing | I | A | I | R | I |
| UAT / acceptance | I | A | A | C | R |
| Go-live decision (G6) | A | R | C | C | I (Secondary User) |
| Ongoing use & data entry | — | I | I | — | R/A |
| Maintenance & change requests | A | R | C | R | C |
4. Governance note — role stacking is a risk¶
Primary User holds Sponsor, Delivery Manager, and Product Owner simultaneously. In a real org these are separated on purpose so there's independent challenge (a sponsor can veto a PM; a PO can push back on scope). Here there's no separation of duties — a single point of failure and no built-in devil's advocate. Mitigation: the delivery team (Claude) is explicitly asked to challenge scope/decisions and surface risks, partially substituting for the missing independent voices. (Logged against risk R4.)