What is the DACI framework?
DACI is a decision-making framework that names four roles for a single decision so that authority, input, and communication are unambiguous. It was developed at Intuit and is a variant of the older RACI responsibility matrix, adapted for decisions rather than tasks.
The distinction matters. RACI answers “who does the work?” DACI answers “who decides, who informs the decision, and who needs to hear about it?” A project can have a perfectly clear RACI chart and still stall for a month because nobody knows who holds the final vote.
DACI is deliberately narrow. Use it for decisions that are consequential, cross-functional, and contested enough that the default meeting culture will not resolve them. Do not use it for every small choice; a framework applied to everything becomes a form to fill in, which is how frameworks die.
> Important note: DACI assigns authority for one decision at a time. If you write “DACI” once at the top of a project charter and never again, you have created a label, not a decision process.
What do the four DACI roles actually do?
Each role has a distinct job, and the boundaries between them are the whole point. The table below is the version worth pinning to a wall.
| Role | Owns | Decision power | Typical holder | What breaks without it |
|---|---|---|---|---|
| Driver | The process, timeline, and information gathering | None by default | Project or program manager | Decision drifts, no owner, no deadline |
| Approver | The final decision | Final say — one person | Budget holder or accountable executive | Endless consultation, no resolution |
| Contributors | Expertise, analysis, options | Voice, no vote | Engineers, analysts, legal, finance, ops | Decision is uninformed or unimplementable |
| Informed | Awareness and downstream execution | Neither voice nor vote | Support, sales, affected teams | Surprise, rework, quiet non-compliance |
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
The Driver
The Driver is the person who makes the decision happen. They frame the question, set the timeline, collect the inputs, run the meeting or async thread, and confirm the outcome in writing. They are usually a project manager, but the role is about the process, not the job title.
The Driver does not need to be the most senior person in the room, and they do not need to be the Approver. In fact, separating the two is one of DACI’s strengths: the person with the budget can decide without also having to run the analysis and chase six stakeholders.
The Approver
There is exactly one Approver. Not a leadership team, not “the steering committee,” not two co-founders who will sort it out between themselves. One named person with the authority to commit the resources the decision requires.
This is the rule people break first, usually for good-sounding reasons: “We need consensus,” “the CTO and CFO both need to sign off.” If two people must agree, name one as Approver and make the other a Contributor with a documented veto — or accept that you have a two-approver process, which is slower and should be designed deliberately rather than discovered in week three.
The Contributors
Contributors have the knowledge the Approver needs. They build the options, cost the alternatives, flag the risks, and recommend. Their input should be structured: a written brief, a short meeting with a clear question, or a decision memo with options and a recommendation.
They do not vote. This is not disrespect; it is clarity. A contributor who believes their opinion is a vote will keep negotiating after the decision, and the decision will reopen.
The Informed
Informed parties are affected by the decision but do not shape it. Support needs to know about a tool change. Sales needs to know about a pricing change. The Informed list is often the longest and the most neglected, which is why the same decision gets re-litigated by people who simply were not told.
How do you run a DACI decision in six steps?
DACI works when it is applied before the debate, not after it. The sequence below takes a decision from a vague question to a recorded outcome.
Step 1: Write the decision as a single question
“Which CRM should we buy?” is a topic, not a decision. “Should we replace Salesforce with HubSpot in Q3, yes or no?” is a decision. Write the question, the decision date, and what happens if the decision is not made.
Step 2: Name the Driver
Choose one person to run the process. Give them the authority to set the timetable and to chase inputs. If the Driver cannot get time on an executive’s calendar, the process will stall regardless of how good the framework is.
Step 3: Name one Approver
Write the name, not the role title. “Approver: CFO (priya@company.com)” is actionable. “Approver: finance leadership” is an invitation to another six weeks.
Step 4: Recruit Contributors with a deadline
List the people whose expertise is required, and specify what you need from each and by when. “Legal: confirm data residency implications by Thursday” is a contribution request. “Legal: thoughts?” is not.
Step 5: Decide on the date
The Driver runs the discussion, the Approver makes the call on or before the agreed date, and the decision is recorded with the rationale. If the Approver needs more information, the date moves explicitly, not silently.
Step 6: Inform and log
Send a short decision note to the Informed list: what was decided, why, who decided, and what changes as a result. Store it somewhere permanent. Decisions that live only in a meeting recap are decisions that will be made again.
What does a DACI template look like?
The template is deliberately minimal. One row per person, one letter per role, plus a short decision record.
| Field | Entry |
|---|---|
| Decision | Replace the current support platform in Q3 |
| Decision question | Approve a 24-month contract with Vendor B at $84,000 a year? |
| Decision date | 14 March |
| Driver | A. Rahman (Program Manager) |
| Approver | J. Okafor (COO) |
| Contributors | IT security (residency review), Finance (total cost model), Support lead (migration risk) |
| Informed | Sales, Customer Success, all support agents |
| Options considered | Vendor A, Vendor B, extend current contract 12 months |
| Decision | Approve Vendor B, 24 months, with a 90-day exit clause |
| Rationale | Lowest 3-year total cost ($252,000 vs $291,000), acceptable residency posture, exit clause limits lock-in |
| Review date | 30 June (post-migration checkpoint) |
Two details make this template more useful than a responsibility matrix. The decision question is written as a yes/no or a choice, so the Approver knows exactly what they are approving. The rationale is recorded at the time, which prevents the decision from being re-argued on memory and impression six weeks later.
Filled example: a smaller decision
Not every DACI needs a steering committee. A team deciding whether to delay a release uses the same structure in four lines.
| Field | Entry |
|---|---|
| Decision question | Delay the 2.4 release by one week to include the payment fix? |
| Driver | M. Chen (Delivery Lead) |
| Approver | R. Silva (Product Director) |
| Contributors | QA lead (regression status), Payments engineer (fix confidence) |
| Informed | Support, Marketing, two enterprise customers |
| Decision date | Tuesday 10:00 |
| Decision | Delay one week; ship 2.4 on 21 May with the fix |
The meeting took 25 minutes because the roles were settled before it started. Without DACI, the same conversation typically involves support arguing for the original date, marketing raising a campaign conflict, and nobody sure whether the product director had already decided.
How does DACI compare with RACI and RAPID?
DACI is one of several decision-rights models. The differences are practical, not academic: each one solves a different failure mode.
| Framework | Letters | Focus | Best for | Main weakness |
|---|---|---|---|---|
| DACI | Driver, Approver, Contributors, Informed | One decision, one approver | Cross-functional decisions with research and a deadline | Can be too heavy for small, reversible choices |
| RACI | Responsible, Accountable, Consulted, Informed | Task execution and deliverables | Project roles, work packages, operational processes | Ambiguous for decisions; “Accountable” is often shared in practice |
| RAPID | Recommend, Agree, Perform, Input, Decide | Decision rights with explicit vetoes | Large organisations with formal governance | More roles, more negotiation, slower to set up |
| RACI-VS | RACI plus Verifier and Signatory | Regulated or quality-critical work | Compliance-heavy environments | Even more roles to maintain |
The cleanest way to choose: use RACI to clarify who does the work, DACI to clarify who decides, and RAPID when you need a formal veto or sign-off structure. Many teams use RACI for the project and DACI for the five or six decisions that determine the outcome.
When does DACI work best — and when does it fail?
DACI is a good fit when four conditions hold: the decision is consequential, it crosses team boundaries, the options require real analysis, and there is a date by which it must be made.
Typical fits include vendor selection, architecture choices, pricing and packaging changes, process redesign, hiring approvals for senior roles, and go/no-go decisions at a stage gate.
It is a poor fit for reversible, cheap choices. Deciding which analytics dashboard to trial does not need four roles and a decision log; it needs someone to pick one and move on. Using DACI everywhere creates bureaucracy and trains people to ignore the framework when it matters.
DACI also fails in three predictable ways:
- The Approver is a committee. A shared approval is an unowned approval. If the group cannot be reduced to one person, the decision will be slower than the framework promises.
- The Driver has no standing. If the Driver cannot get the Approver’s attention or the Contributors’ input on time, the process becomes theatre.
- Contributors are treated as voters. The moment the Approver says “let’s make sure everyone is comfortable,” the decision becomes a negotiation and the timeline dissolves.
What does DACI cost, and what does it save?
The framework’s value is easiest to see in meeting hours and delayed work. Two examples, using assumptions you can replace with your own.
Example: meeting load
Before DACI, a weekly vendor meeting has nine attendees for 90 minutes across five sessions. That is 9 × 1.5 × 5 = 67.5 person-hours.
With DACI, the same decision uses three sessions of 60 minutes with five people: Driver, Approver, and three Contributors. That is 5 × 1 × 3 = 15 person-hours. The saving is 52.5 person-hours, before counting the four people who no longer context-switch twice a week.
Example: the cost of delay
A decision slips by 11 working days. Three engineers cannot start integration until it is made. At a fully loaded cost of $85 per hour, the waiting cost is 3 engineers × 8 hours × $85 × 11 days = $22,440.
Some work continues in parallel, but even at 40% utilisation the cost is $8,976 for one delayed decision. Multiply that by the number of decisions a quarter and the case for naming an Approver early becomes obvious.
Example: decision throughput
A team makes 24 decisions a quarter with an average cycle time of nine days. After adopting DACI and a decision log, the average falls to four days.
The saving is 24 × 5 = 120 decision-days. If each decision blocks an average of four people, that is 480 person-days of waiting removed from the quarter — roughly two full-time people freed from waiting for other people to decide.
What are the most common DACI mistakes?
Treating the D as a project manager’s title rather than a role. The Driver is whoever runs this decision, which may vary by decision.
Naming the Approver too late. If the Approver is identified after the options are built, the options will be built for the wrong criteria.
Inviting everyone to the decision meeting. Contributors can submit written input; they do not all need to attend. The Informed list should almost never attend.
Letting the Approver abstain. “I’m comfortable with whatever the team recommends” is a delegation, not a decision. If the Approver wants to delegate, the delegated person becomes the Approver and that should be recorded.
Skipping the written record. A decision without a recorded rationale gets remade. The record is the memory of the organisation.
Using DACI to avoid accountability. The framework distributes roles, not responsibility. The Approver still owns the outcome.
How do remote and async teams use DACI?
DACI is arguably more valuable when the team is distributed, because the informal cues that signal “she’s the decision maker” in a room are missing on a video call.
A workable async pattern:
- The Driver posts a one-page decision brief with the question, options, recommendation, and deadline.
- Contributors add written input by a stated date, tagged to the option it affects.
- The Approver replies in writing with the decision and rationale.
- The Driver posts the decision note to the Informed channel and files it in the project workspace.
This removes the need for a meeting in most cases and creates a searchable trail. The one thing to protect is the deadline: async decisions drift unless the Driver enforces the date.
How do you adopt DACI without a change programme?
Start with one decision, not a rollout. Pick a decision that is currently stuck, apply the template, and run it end to end. Then review: did the Approver decide on time, did Contributors deliver input, did the Informed list hear before they were surprised?
If the first decision works, add a decision log to the project workspace and require a DACI row for decisions above a threshold — budget impact, customer impact, or irreversibility. Keep the threshold explicit so the framework does not expand to cover every choice.
Doitify is our project and team management platform, and it holds project documents, meeting notes, tasks, and progress reporting in one workspace. Teams use it to keep the decision log next to the work it affects, so the Approver, the rationale, and the follow-up tasks are in the same place rather than scattered across email and chat. It does not enforce decision rights; it makes the record easy to keep.
FAQ
Conclusion
DACI is a small framework with a narrow job: make it obvious who decides, who informs the decision, and who needs to hear about it. That clarity is worth more than another status meeting, because most project delays are not caused by bad analysis. They are caused by decisions waiting for an owner.
Use the template on one stuck decision this week. Name one Driver, one Approver, three Contributors, and an Informed list. Set a date, record the rationale, and send the note. If the decision moves faster and the room stops re-litigating it, you have found a repeatable pattern — and a much cheaper way to run the next six weeks.
If this post on DACI framework was helpful, you might also enjoy Project Management Software for Manufacturing Teams in 2026 and Best Project Management Software With Built-In Chat in 2026.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.