raci-matrix

What this skill does

# RACI Matrix

You create and validate RACI matrices (Responsibility Assignment Matrices). You research typical role structures and task breakdowns yourself — do not ask the user for data they would need to look up. Only ask the user for decisions and confirmations.

This skill complements `stakeholder-mapping` (which identifies stakeholders) and `influence-diagramming` (which maps relationships) by assigning **specific operational responsibilities** per task.

## Supported Variants

| Variant | Codes | Best for |
|---|---|---|
| **RACI** (default) | Responsible, Accountable, Consulted, Informed | General project management |
| **RASCI** | + Supportive | Complex projects with many support functions |
| **RACI-VS** | + Verifier, Signatory | Regulated industries, audit-heavy contexts |
| **RACIO** | + Omitted | When exclusion must be explicitly documented |
| **DACI** | Driver, Approver, Contributors, Informed | Decision-centric (not task-centric) |
| **RAPID** | Recommend, Agree, Perform, Input, Decide | Strategic/organizational decisions (Bain) |

## Phase 1 — Setup

### Input handling

Follow shared foundation §7 — interview mode. When input is missing or insufficient, interview to gather at minimum:

| Dimension | Required | Default |
|---|---|---|
| **Project/initiative context** | Yes | — |
| **Stakeholder mapping output** | No | Will identify roles itself |
| **Task list / WBS** | No | Will identify tasks itself |
| **Variant** | No | RACI (will recommend if another fits better) |

**Exit interview when**: Project context is clear enough to identify roles and tasks.

### 1. Collect input

Accept one of:
- A project or initiative description
- A file path to a stakeholder mapping report and/or task list
- Pasted content (business case, stakeholder register, WBS)
- No input or vague input → enter interview mode

### 2. Detect scope and recommend variant

From the input (or interview results), identify:
- **Project/initiative**: What is being planned or executed
- **Domain**: Industry, regulatory context
- **Stakeholder source**: Imported from mapping or to be identified
- **Task source**: Imported from WBS or to be identified

Recommend a variant based on context:
- Regulated industry (SOX, GDPR, FDA) → **RACI-VS** (audit trail)
- Complex support structures → **RASCI** (explicit support roles)
- Decision rights focus → **DACI** or **RAPID**
- Political sensitivity about exclusion → **RACIO**
- General → **RACI**

### 3. Confirm scope

```
**Project**: [name]
**Variant**: [recommended variant + rationale]
**Role source**: [imported from mapping / will identify]
**Task source**: [imported from WBS / will identify]
```

Ask the user to confirm or adjust. Ask diagram render mode and output path per the `diagram-rendering` and `autonomous-research` mixins.

## Phase 2 — Research

Use WebSearch and WebFetch per the `autonomous-research` mixin.

### 2a. Role structure research

Research typical role structures for this type of project/industry:
- Standard project roles and their authority levels
- Industry-specific roles (compliance, regulatory, audit)
- Governance patterns and decision-making structures

### 2b. Task breakdown research

Research common task breakdowns for similar initiatives:
- Standard project phases and deliverables
- Industry-specific tasks and milestones
- Governance checkpoints and approval gates

## Phase 3 — Role Identification (Columns)

### If stakeholder mapping is provided

Import roles with their attributes:
- Read the stakeholder mapping report
- Extract roles from the stakeholder register
- Map Power/Interest quadrant to likely RACI assignments:
  - Manage Closely (high power, high interest) → likely A or R
  - Keep Satisfied (high power, low interest) → likely A or I
  - Keep Informed (low power, high interest) → likely C or I
  - Monitor (low power, low interest) → likely I or blank

### If no stakeholder mapping

Identify 5-15 roles relevant to the project:

| Field | Description |
|---|---|
| **Role** | Title/function (not individual names) |
| **Description** | Brief role description |
| **Authority** | Decision-making level (executive, manager, contributor, external) |
| **Source** | Project team / management / functional / external |

Present role list for user confirmation.

## Phase 4 — Task/Deliverable Identification (Rows)

### If WBS/task list is provided

Import tasks, validate granularity, organize by phase.

### If no task list

Identify 15-40 tasks/deliverables/decisions:

| Field | Description |
|---|---|
| **ID** | T01, T02, etc. |
| **Phase** | Project phase or logical grouping |
| **Task** | Specific deliverable, activity, or decision |
| **Type** | Task / Deliverable / Decision / Milestone |

**Granularity rules:**
- Specific enough for clear responsibility assignment
- Not micro-tasks (avoid "write line 42 of config")
- Not too high-level ("do the project")
- Each task should have a clear "done" state

Present task list for user confirmation.

## Phase 5 — RACI Assignment

### RACI code definitions

| Code | Role | Rule | Communication |
|---|---|---|---|
| **R** | Responsible | Does the work. ≥1 per task. Prefer 1-2. | Active participant |
| **A** | Accountable | Owns the outcome. Exactly 1 per task. Approves/rejects. | Decision authority |
| **C** | Consulted | Input sought before work/decisions. Two-way. | Two-way, pre-decision |
| **I** | Informed | Updated on progress/completion. One-way. | One-way, post-decision |

For variants, additional codes:
- **S** (Supportive/RASCI): Assists R but doesn't own the task
- **V** (Verifier/RACI-VS): Checks deliverable meets acceptance criteria
- **Si** (Signatory/RACI-VS): Provides formal sign-off
- **O** (Omitted/RACIO): Explicitly excluded from involvement
- **D** (Driver/DACI): Leads the decision process (equivalent to R)
- **Ap** (Approver/DACI): Has final say (equivalent to A)

### Hard rules (must enforce)

1. Every row must have **exactly 1 A** — no exceptions
2. Every row must have **at least 1 R** — someone must do the work
3. One code per cell (or blank)

### Soft rules (best practices, report violations as Warning)

4. Prefer 1-2 R per row (avoid "too many cooks")
5. Max 2-3 C per row (avoid consultation bottleneck)
6. Separate R and A where possible (four-eyes principle)
7. No person A for > 40% of tasks (bottleneck risk)

### Assignment table

| Task | Role A | Role B | Role C | Role D | ... |
|---|---|---|---|---|---|
| T01: [task] | R | A | C | I | ... |
| T02: [task] | A | R | | I | ... |

## Phase 6 — Horizontal Validation (per task)

Check every row:

| Task | A count | R count | C count | I count | Issues | Severity |
|---|---|---|---|---|---|---|
| T01 | 1 | 1 | 2 | 3 | None | — |
| T02 | 0 | 2 | 4 | 1 | No A; >3 C's | Critical; Warning |

### Validation rules

| Check | Rule | Severity |
|---|---|---|
| A count = 1 | Hard rule | **Critical** if violated |
| R count ≥ 1 | Hard rule | **Critical** if violated |
| R count ≤ 2 | Soft rule | **Warning** if > 2 |
| C count ≤ 3 | Soft rule | **Warning** if > 3 |
| R ≠ A (same person) | Soft rule | **Info** if same person |

## Phase 7 — Vertical Validation (per role)

Check every column:

| Role | R count | A count | C count | I count | % involved | Assessment |
|---|---|---|---|---|---|---|
| Role A | 12 | 3 | 2 | 5 | 73% | R overload |
| Role B | 2 | 18 | 0 | 0 | 67% | A bottleneck |

### Validation rules

| Check | Threshold | Severity |
|---|---|---|
| A for > 40% of tasks | Bottleneck risk | **Warning** |
| R for > 50% of tasks | Overload risk | **Warning** |
| C for > 60% of tasks | Consultation bottleneck | **Warning** |
| Involved in > 80% of tasks | Over-involvement | **Info** |
| Zero assignments | Unnecessary inclusion | **Info** |

## Phase 8 — Anti-Pattern Detection

Scan for all 15 anti-patterns:

| # | Anti-Pattern | Detection | Severity | Fix |
|---|---|---|---|---|
| 1 | No A assigned | Row has 0 A's | **Critical** | Assign exactly one A |
| 2 | Multiple A's | Row has > 1 A |