Complete firstStakeholder Mapping
A current overview of relevant roles and stakeholders in the organization or team exists.
Without: Without a role list, decision types are assigned to unclear roles and the agreement remains vague.
RunsheetDecision Making
Decision Rights Mapping
ComplexityMedium
Time90-180 min
Participants4-12
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
02
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro board with a matrix (rows: decision types, columns: roles); RACI or RAPID notation shown as a banner; list of decisions to clarify; org chart as a reference; tool for documentation of agreements.
People / roles
A facilitator (coach, org designer, HR partner); all involved role owners or their representatives; a sponsor with authority for commitments; a scribe for agreements.
Pre-read
List of recurring decision types (typically 10-25); current friction points or escalations; existing implicit rules; org chart and formal responsibilities.
Time needed
90-180 min
Setup
Prepare matrix: vertically decision types (for example hiring, budget reallocation, tech stack choice, release approval). Horizontally roles. Define notation: D (Decide), R (Recommend), I (Input), F (Informed). Sponsor confirms authority.
03
Core question
The one question this method answers
Which role decides which type of decision, which roles are consulted before it, which are informed afterwards, and how do we make that binding?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Collect decision types | 20-30 min | Each participant names 3-5 recurring decisions with friction. Consolidate duplicates. Create a list of 10-25 types, sorted by frequency or friction. | Use concrete decisions, not abstract categories. "Who decides sprint scope changes mid-sprint" is more concrete than "scope decisions". |
2Phase 2: Clarify roles | 15 min | Consolidate role list (PO, Tech Lead, Engineering Manager, Architect, CTO, etc.). Resolve role overlaps and clarify intended role. | Person is not the same as role. A person can hold several roles, but mapping is done to roles. With person changes, the agreement remains valid. |
3Phase 3: Assign notation per decision | 30-60 min | Determine one Decide role per decision type, Recommend roles, Input roles, and Informed roles. Discuss duplicates or conflicts. | Exactly one decider per decision. Duplicate deciders are a common root of escalations. Negotiate conflicts rather than parking them. |
4Phase 4: Conflicts and exceptions | 20-30 min | Discuss disputed decisions individually. For irreconcilable conflicts, define an escalation rule (for example "on a tie: sponsor decides within 48h"). | Avoid pseudo-consensus. Prefer explicit escalation rules to ambiguous agreements. |
5Phase 5: Document and communicate agreement | 10-15 min | Matrix becomes the final artifact. All participants confirm (digital confirmation or email). Share with broader org and set review date in 3 months. | Without explicit sign-off per person, agreement dissipates. Signing is symbolically important. Review cadence prevents drift. |
05
Artifact
What comes out at the end
Form
Decision rights matrix with decision types, roles, notation (D/R/I/F), and escalation rules. Agreement includes date, participants, and sponsor confirmation. Stored in org wiki.
Versioning / ownership
Record agreement date in the header. Document updates with new date and rationale. Archive old versions. Reconfirm when org or sponsor changes.
Tool alternatives
- Miro or FigJam with Decision Rights template
- Confluence page with table
- Notion database with Decision-Type/Decider properties
- Google Sheet with filter views
- Lucidchart with matrix diagram
decision-rights-mapping-working-template.md
Compact working template for Decision Rights Mapping with context, input, output artifacts, and next step.
Decision Rights Mapping Working Matrix
| Element | Description | Rating | Evidence | Owner | Next step |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
Output artifacts
- Decision-Rights Matrix:
- Agreement:
Decision or recommendation
What consequence follows from the matrix?
06
Example output
Concrete filled scenario, fictional example
decision-rights-mapping-beispiel.md
Concrete filled scenario, fictional example
Decision Rights Mapping - Product Team Discovery, 2026-05-18
Sponsor: @julia (CTO). Participants: PO @lisa, EM @marcus, Tech Lead @ben, Designer @anna, Architect @michael.
Matrix excerpt
| Decision | PO | EM | Tech Lead | Designer | Architect | CTO |
|---|---|---|---|---|---|---|
| Sprint Scope (story selection) | D | I | R | R | F | F |
| Mid-Sprint Scope change | D | R | R | F | F | F |
| Technology stack choice (new service) | I | R | R | F | D | F |
| Major library version updates | F | F | D | F | R | F |
| Hiring engineer | R | D | R | F | F | F |
| Production release approval | R | D | R | F | F | F |
| Compliance-relevant architecture | F | F | R | F | R | D |
| Quarterly budget | I | R | F | F | F | D |
Escalation rules
- On tie between PO and Tech Lead for sprint scope: EM decides within 24h.
- For architecture conflicts with compliance implications: CTO decides within 48h after formal escalation.
- On hiring tie: HR partner facilitates, CTO decides final.
Consent: All 6 participants confirmed by email on 18.05.2026.
Review date: 18.08.2026 (3 months). If team or organization changes, update immediately.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Multiple deciders
Symptom
Some decisions have two roles with "D" in the matrix, leading to escalations.
What to do
Enforce one decider per decision. Negotiate who is decider in case of disputes. If no agreement, escalate the rule to the sponsor.
Trap
Pseudo-consensus
Symptom
Participants seemingly agree but later say they understood something different.
What to do
Formulate explicit consensus per decision and check understanding. Require explicit email or written confirmation. If someone does not explicitly agree, they are declining.
Trap
Agreement is forgotten
Symptom
After six weeks everyone decides as before, matrix stays in wiki without impact.
What to do
Use review cadence (3-6 months). Escalate immediately to matrix reference when friction appears. Onboard new members with matrix walkthrough.
Trap
Decision types are too abstract
Symptom
"Strategic decisions" as a type means nobody understands which concrete decision is meant.
What to do
Add one concrete example per type. Prefer 20 concrete types over 5 vague ones. Re-concretize the list when scope drift occurs.
Trap
People instead of roles
Symptom
Mapping is done by names, so any person change invalidates the agreement.
What to do
Keep mapping by role. Maintain person-role mapping separately. With person changes, update only person mapping, not the whole matrix.
08
Stop criteria
Done signals checkable in under a minute
Sponsor not present or without authority so commitments cannot become binding.
More than 30 decision types make the workshop oversized and superficial.
Role holders or delegates are missing, making agreement non-representative.
Conflicts are so deep the workshop turns into dispute and requires mediation first.
Team or organization is in transition, so agreement would become outdated within four weeks.
RACI/RAPID/DACI is already established and Decision Rights Mapping would add parallel structures.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.