Decision Protocols Quick Reference
A concise, one-page reference that compares consent, DACI, RACI variants, delegation, and voting. Includes quick-use guidance based on decision complexity and urgency, short sample scripts you can use in meetings, and a checklist to pick the right protocol for a team decision.
Decision Protocols Quick Reference
Use this page to choose a decision protocol that matches your team's need for speed, clarity, and stakeholder involvement. The short comparison and scripts help teams avoid ambiguous decision rights that cause delay and finger-pointing.
At-a-glance comparison
| Protocol | When to use | Who decides / role | Speed & typical overhead | Good for | Sample script |
|---|---|---|---|---|---|
| Consent (Consent Decision) | When a proposal is clear, low-risk, and improvements can be returned quickly; team alignment matters more than unanimous agreement. | Proposer invites consent; objections must be reasoned and addressed. | Fast for routine/operational items; low overhead. | Operational changes, meeting agreements, implementation details. | "We propose to adopt X. Any objections? If none, we'll proceed and monitor." |
| DACI | When a clear decision owner is needed and multiple contributors/stakeholders are involved. | D = Driver (owns process), A = Approver (final yes/no), C = Contributors, I = Informed. | Moderate — clarifies accountability; needs role assignment. | Product direction, hiring decisions, vendor selection. | "Driver proposes option A; Approver will decide after hearing Contributors' inputs by Friday." |
| RACI (and variants) | When work needs to be coordinated across roles and responsibilities must be explicit. | R = Responsible (doer), A = Accountable (final sign-off), C = Consulted, I = Informed. Variants may swap wording. | Moderate to high — useful in project planning and handoffs. | Project tasks, cross-functional deliverables, process ownership. | "For launch task X: Product = A, Engineering = R, Legal = C, Marketing = I." |
| Delegation | When authority should be passed down with clear boundaries and expectations. | Manager delegates defined decision rights and constraints to a person or team. | Fast after delegation is set up; requires upfront clarity. | Routine operational decisions, local adaptions, tactical execution. | "I delegate authority to you to approve orders up to $5k; escalate exceptions to me." |
| Voting | When equal input is required and the group accepts majority rules; less useful if technical expertise varies widely. | Group votes; rules set beforehand (majority, supermajority, weighted vote). | Variable — can be fast, but may require quorum and rules. | Governance decisions, elections, when fairness is the priority. | "We will vote. A majority carries. All in favor?" |
Decision complexity & urgency guidance
Match protocol to the combination of two factors: decision complexity (how many unknowns or trade-offs) and urgency (how quickly decision is needed).
- Low complexity + High urgency: Consent or Delegation (clear guardrails).
- Low complexity + Low urgency: Consent or Delegation with short review period.
- High complexity + High urgency: DACI with short, focused inputs or timeboxed decision sprint.
- High complexity + Low urgency: DACI or RACI for structured analysis, plus stakeholder consultations.
- Governance/fairness concerns: Voting when the group agrees to abide by results.
Quick checklist to choose a protocol
- Define the decision and desired outcome in one sentence.
- Assess complexity: Is there a clear technical/subject-matter owner? (Yes → DACI/RACI; No → consult broadly)
- Assess urgency: Do we need an answer now or can we gather input? (Now → Consent/Delegation if low risk; time → DACI)
- Decide required level of accountability vs. fairness: Need a single final sign-off? (Yes → DACI/RACI; No → Consent or Voting)
- Choose protocol, name roles (Approver, Driver, Responsible, etc.), document timeline and escalation path, and record the decision location (e.g., decision registry or shared doc).
Short scripts you can use
Use these templates in meetings, chat, or decision docs. They keep the process visible and reduce confusion.
- Consent (proposal): "Proposal: [one-line proposal]. Any objections to proceeding? If you have an objection, state the reason and suggested amendment. If none, we'll proceed on [date]."
- DACI (assign roles): "For this decision: Driver = [name], Approver = [name], Contributors = [names]. Driver will collect input by [date]; Approver will decide by [date]."
- RACI (task): "Assigning RACI for [task]: R=[team], A=[owner], C=[stakeholders], I=[informed list]."
- Delegation (authority): "I delegate decision rights for [area] to [name/team] with constraints: [limits]; review on [date]."
- Voting (group): "We will vote on options A/B. Voting closes at [time]. Majority decides unless stated otherwise."
Common pitfalls and fixes
- Pitfall: No named owner → Fix: Assign a Driver or Approver before discussion ends.
- Pitfall: Too many people have veto power → Fix: Use Consent with a clear definition of a valid objection, or switch to DACI and limit the Approver role.
- Pitfall: Protocol chosen by default (e.g., voting for everything) → Fix: Make protocol choice explicit and document why it fits.
Next steps
After deciding, record: the chosen protocol, named roles, timeline, and where the decision lives (document or registry). Regularly review delegated decisions to ensure boundaries remain appropriate.
Discussion
Comments and conversation will live here.