feat: add raci_patterns reference
This commit is contained in:
@@ -0,0 +1,130 @@
|
||||
# Responsibility Matrix (RACI) Patterns
|
||||
|
||||
Standard responsibility splits for MPM projects. Use this as the source-of-truth when building the RACI table in the generated SOW.
|
||||
|
||||
## RACI Legend
|
||||
|
||||
- **R** = Responsible (does the work)
|
||||
- **A** = Accountable (owns the outcome / signs off)
|
||||
- **C** = Consulted (provides input)
|
||||
- **I** = Informed (kept in the loop)
|
||||
|
||||
## Standard RACI Matrix
|
||||
|
||||
Use this full table as the default. Remove rows that don't apply to the project (e.g., drop "Bus staging coordination" for wayside-only projects).
|
||||
|
||||
| Activity | MPM | Reseller | End-Client |
|
||||
|---|---|---|---|
|
||||
| **Project Initiation** | | | |
|
||||
| Contract execution | I | R/A | C |
|
||||
| Kickoff scheduling and facilitation | R/A | C | C |
|
||||
| Stakeholder identification and communications plan | R | A | C |
|
||||
| **Discovery and Design** | | | |
|
||||
| Client questionnaire completion | I | C | R/A |
|
||||
| Pre-sales / discovery information handoff | C | R/A | C |
|
||||
| Site survey execution (wayside) | R/A | I | C |
|
||||
| Site survey findings and installation design | R/A | I | C |
|
||||
| Fleet survey / retrofit plan (mobile) | R/A | I | C |
|
||||
| Content design and visual mockups | R/A | C | C |
|
||||
| Content approval | C | C | R/A |
|
||||
| **Hardware Procurement and Production** | | | |
|
||||
| Hardware ordering and manufacturing | R/A | I | I |
|
||||
| Pre-ship factory provisioning and configuration | R/A | I | I |
|
||||
| Shipping coordination to staging or site | R/A | I | C |
|
||||
| Receipt, inspection, and storage of equipment | C | C | R/A |
|
||||
| **Infrastructure Readiness (Pre-Install)** | | | |
|
||||
| Infrastructure Readiness Form review and sign-off | C | I | R/A |
|
||||
| Power provisioning to display locations | C | I | R/A |
|
||||
| Network connectivity provisioning | C | I | R/A |
|
||||
| Cellular data plans and SIM provisioning (if applicable) | {per Phase 3 answer} | {per Phase 3 answer} | {per Phase 3 answer} |
|
||||
| Mounting surface structural verification | C | I | R/A |
|
||||
| Permitting and inspections | C (info/liaison only) | I | R/A |
|
||||
| **Installation** | | | |
|
||||
| Installation scheduling and coordination | R/A | I | C |
|
||||
| Site/vehicle access coordination | C | I | R/A |
|
||||
| Physical installation (DBE-managed) | R/A | I | C |
|
||||
| Installation quality check and sign-off | R | I | A |
|
||||
| **Software and Licensing** | | | |
|
||||
| MPTV license provisioning and assignment | R/A | I | C |
|
||||
| TransitPoint / middleware configuration (if applicable) | R/A | C | C |
|
||||
| Native API integration configuration | R/A | C | C |
|
||||
| Custom development deliverables (if applicable) | R/A | C | C |
|
||||
| **Testing and Acceptance** | | | |
|
||||
| Burn-in testing | R/A | I | C |
|
||||
| System Acceptance Testing (SAT) | C | I | R/A |
|
||||
| Defect resolution during burn-in | R/A | I | C |
|
||||
| Formal System Acceptance sign-off | C | C | R/A |
|
||||
| **Training** | | | |
|
||||
| Training plan development | R/A | C | C |
|
||||
| Training session delivery | R/A | I | C |
|
||||
| Trainee designation and scheduling | C | C | R/A |
|
||||
| Training participation and completion | I | I | R/A |
|
||||
| **Go-Live and Handoff** | | | |
|
||||
| Final system activation | R/A | I | C |
|
||||
| Handoff to Support & Maintenance | R/A | I | A |
|
||||
| As-built documentation delivery | R/A | I | C |
|
||||
| **Change Management** | | | |
|
||||
| Change Order initiation | any party may initiate | any party may initiate | any party may initiate |
|
||||
| Change Order impact assessment | R (technical) | R (commercial) | C |
|
||||
| Change Order approval | C | A | C |
|
||||
| **Financial** | | | |
|
||||
| Invoicing | R/A | I | I |
|
||||
| Payment (to Reseller) | I | I | R/A |
|
||||
| Payment (to MPM) | I | R/A | C |
|
||||
|
||||
## Critical splits — common points of confusion
|
||||
|
||||
These are the items that most often go wrong. Call them out explicitly in the narrative sections around the RACI table, not just in the table.
|
||||
|
||||
### Permitting
|
||||
|
||||
MPM is never Responsible or Accountable for permitting. Even when MPM is "leading" the installation, permitting is the End-Client's problem. If the Reseller has a local presence and wants to manage permitting on the End-Client's behalf, that's their arrangement with the End-Client — MPM stays in the Consulted role.
|
||||
|
||||
### Cellular Data Plans
|
||||
|
||||
This is almost always the #1 source of disputes. Before the SOW is signed, confirm in writing (via the Phase 3 clarifying question answer) who pays for cellular data each month, for how long, and what happens at renewal. Put the specific party in the RACI row.
|
||||
|
||||
### Content Creation
|
||||
|
||||
"Content" means different things to different people. In an MPM project, the split is usually:
|
||||
|
||||
- **Content framework / visual design** (layouts, templates, design system): MPM (R/A)
|
||||
- **Initial content assets** (first set of messages, branded graphics, schedule imports): MPM (R) with End-Client (A — approves)
|
||||
- **Ongoing content production** (day-to-day messages, seasonal campaigns, service alerts): End-Client (R/A) — explicitly out of SOW scope
|
||||
|
||||
Call this out in the narrative so the End-Client doesn't expect MPM to write their service alerts after Go-Live.
|
||||
|
||||
### Network / Firewall Configuration
|
||||
|
||||
MPM will tell the End-Client's IT team what URLs, ports, and protocols need to be open. MPM does not configure the End-Client's firewalls or network equipment. If the End-Client lacks the internal capability, they need to engage their own network vendor — MPM can consult but will not take Responsibility.
|
||||
|
||||
### Who Signs What
|
||||
|
||||
- **The SOW itself** is typically signed by the Reseller (as the commercial customer of MPM) and MPM. The End-Client may be asked to acknowledge receipt but is typically not a signatory to this SOW, since their contractual relationship is with the Reseller. If a tri-party signature is desired, confirm with the user and adjust the signature block accordingly.
|
||||
- **The Infrastructure Readiness Form** is signed by the End-Client.
|
||||
- **System Acceptance** is signed by the End-Client with the Reseller acknowledging.
|
||||
|
||||
Be careful about this — in the Executive Summary and Introduction, it's easy to imply that the End-Client is a party to this SOW when they aren't. Use "the Agency will…" for operational language and "the Parties" for contractual language, with the Parties defined up front.
|
||||
|
||||
## Mobile Retrofit — additional RACI rows
|
||||
|
||||
Add these rows for mobile projects:
|
||||
|
||||
| Activity | MPM | Reseller | End-Client |
|
||||
|---|---|---|---|
|
||||
| Bus fleet list and specification confirmation | C | C | R/A |
|
||||
| Bus staging and availability scheduling | C | I | R/A |
|
||||
| Bus yard access and shop facilities | C | I | R/A |
|
||||
| Vehicle electrical system verification | C | I | R/A |
|
||||
| Post-install bus return to service | I | I | R/A |
|
||||
|
||||
## Solar Wayside — additional RACI rows
|
||||
|
||||
(Less mature — ask user to verify these):
|
||||
|
||||
| Activity | MPM | Reseller | End-Client |
|
||||
|---|---|---|---|
|
||||
| Solar site suitability assessment (sun hours, shading) | C | I | R/A |
|
||||
| Electrical engineering for off-grid power system | depends on scope | I | R/A |
|
||||
| Foundation / pole engineering and installation | C | I | R/A |
|
||||
| Seasonal/winterization planning | C | C | R/A |
|
||||
Reference in New Issue
Block a user