Table of contents
- What is DACI?
- The 4 DACI roles
- DACI history
- When to use DACI
- DACI criticisms
- DACI examples and templates
- DACI alternatives and related concepts
What is DACI?
DACI (pronounced “day-see”) is a decision-making framework for agile, cross-functional groups designed to clarify expectations around roles and responsibilities.
Think of DACI as a map of how different people contribute to a project.
The acronym DACI stands for the critical roles in the project: driver, approver, contributors, informed. These roles are often visualized in a DACI matrix or quadrant-type chart.
That said, the format doesn’t necessarily matter; a document that puts names to the DACI functions and tracks decisions will work great. The best format is whatever format people around you will read and use.
The 4 DACI roles
The four roles of the DACI framework are:
The order of the roles in the acronym are sorted from fewest to broadest. It’s generally agreed that the driver should be one person.
The approver is ideally one person but, depending on the scope and complexity of the project or organization, it may be necessary to have multiple approvers. Keep approvers to as few as needed for decision-making efficiency and quality.
More people are welcome to participate as contributors, and the informed can be an even larger audience within the company.
Although the roles should be set for the entire project or group, roles can also be set for specific tasks or subtasks.
Let’s take a more detailed look at the four roles of the DACI framework.
Driver
The driver is the leader and facilitator. They are responsible for creating the plan, managing activities, setting timelines, and making sure tasks are completed. They are probably doing the most documentation and communication.
The driver is not the only one doing work, but they are the person ensuring progress doesn’t stall and that any next steps are understood and tracked. The driver is a cheerleader and project manager of sorts.
Approver
Like a referee, the approver makes the final call.
The approver’s official title will vary based on the context. For example, approvers can range from founders to product managers. There can be more than one approver, but it’s best to keep the number of approvers to a minimum.
Contributors
As helpers and consultants, contributors lend their opinions and expertise to help with project decisions. They might help with research or simply share insights from their experience.
Contributors are typically experts in their functional area or line of business. As such, they have influence, but the ultimate decision will lie with the approver.
Learn more →Informed
The informed are passengers on the journey. They need to know about the project’s progress but don’t have any authority over it.
It’s essential to keep these team members updated because the decisions will impact their day-to-day work. Communication with this group is mostly one-way to avoid having too many cooks in the kitchen.
DACI history
The roles that make up the DACI matrix aren’t new. DACI was first rolled out at Intuit some 40 years ago as an adaptation of the more rigid RACI another 30–40 years earlier.
New derivative decision-making frameworks emerge all the time as companies seek to adapt them for diverse orgs and applications.
When to use DACI
There’s no doubt about it — DACI and other models like it take work. These systems become even more laborious when tasks and subtasks have their own DACI roles defined.
In general, DACI should be leveraged only when absolutely necessary. Below are some examples of scenarios in which some extra definition of roles and responsibilities might be worth the effort:
- Large projects spanning multiple teams
- New, large teams or working groups
- High-profile/high-risk projects with lots of dependencies
DACI criticisms
Critics of the DACI model claim that DACI isn’t for teams at all. The idea is that, if you were truly a team, then you wouldn’t need DACI. You’d simply align on an outcome and talk it out.
Building on that idea, some believe DACI fails to address the real problem. Alternatively, product managers should create an environment of psychological safety where people can be open about their opinions and disagreements. Hold any necessary debates and establish a decision-maker as the tie-breaker.
This has been my own personal experience in larger, more passionate product teams. The tie-breaker might be a head of product, VP, or director-level product leader. From there, it’s up to team members to be able to disagree and commit in support of the team.
DACI examples and templates
There are some good resources out there. Here are some of the most practical DACI guides I’ve seen:
- I follow Thaisa Fernandes on Medium. From a 2019 article, Thaisa shares a Google Doc template you might find helpful
- Andrea Kimball has a document template published on Coda
- Process.st has a thorough walkthrough that you can use as a reference or add as a workflow in their tool.
DACI alternatives and related concepts
RACI vs. DACI: What’s the difference?
RACI is the framework most commonly paired with DACI. That’s because they’re related.
DACI evolved from RACI, but even though they sound similar, they are very different in real-world applications.
Subscribe to our product management newsletter
Get articles like this to your inbox
In the case of RACI, R stands for responsible (instead of driver), and A stands for accountable (instead of approver). The C and I are essentially the same between the two models.
RACI was popular after World War II as big business was booming in the US. Organizations were very hierarchical with centralized decision-making. RACI has one person accountable for the successful completion of the work and emphasizes task completion over achieving valuable outcomes.
Today, in agile environments, we want teams to share accountability and ownership rather than individuals. RACI focuses on who to fire or promote depending on output, while DACI looks to make the best decisions and help teams work effectively.
Complete list of frameworks similar to DACI and RACI
You should never feel pressure to adopt one particular framework, no matter how popular it is. As you’ll see below, teams have adapted DACI and RACI for their own situations in many different ways.
Below is the complete list of DACI-related models. A subset of these is listed on Wikipedia with a bit more explanation if you want to explore more.
- RACI: Responsible, Accountable, Consulted, Informed
- DACI: Driver, Approver, Contributors, Informed
- ARCI: Pronounced “Arky.” Same roles as RACI in a different order
- ARPA: Accountable, Responsible, Participant, Advisor
- CAIRO or RACIO: RACI with an O for Omit to designate people who will not be involved
- CAIROS: RACI with Support and Omitted
- CARS: Communicate, Approve, Responsible, Support
- DACIN: DACI with an N for the Next Steps
- DARCI: RACI with a dedicated Decision-maker role
- DCI: RACI without Accountable or Responsible
- DRASCI: RACI with Support and Driver (from DACI)
- DRI: Directly Responsible Individual. Apple used DRIs instead of Product Managers to build the iPhone
- LRC: Linear Responsibility Chart. Another name for a RACI chart, like RAM
- MOCHA: Manager, Owner, Consultant, Helper, Approver
- PACSI: Perform, Accountable, Control, Suggest, Informed
- PDQA: Primary, Decision, Quality, Assist
- RACI Alternate: Responsible takes on the meaning of Accountable, A becomes Assist
- RACI-VS: RACI with two additional roles – Verifier and Signatory
- RACI+F: RACI with an added Facilitator role
- RACIQ: RACI with a Quality review role
- RAM: Responsibility Assignment Matrix. Another name for a RACI chart
- RAPID: Recommend, Agree, Perform, Input, Decide
- RAS: CARS without Communicate. Responsible, Approve, Support
- RASCEIO: RACI with Support, Execution, and Overview
- RASCI or RASIC: RACI with an additional Support role
- RATSI: Authority, Support, Task, Support, Informed
- RSI: Responsible, Sponsor, Informed
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
