Using the DACI Framework

· 1300 words · 7 minute read

I’ll never forget the first time I was introduced to decision-making frameworks.

A peer from another department called a meeting, began to draw a grid on the whiteboard, and casually said over his shoulder, “this isn’t a land grab, but we need to get clear on ownership.”

Then he filled out the grid with who was in charge of what, who was responsible to do what, and who didn’t really need to participate in the work but needed to know what was going on.

It felt like a land grab. I’d been at that startup for a bit over a year, and had acclimated to the shift from a larger business where people “just knew what to do” and generally stuck to their remits, to a much smaller, more entrepreneurial business where people just grabbed stuff if it aroused their curiosity. In that more relaxed, less functionally siloed environment, it seemed a little rude for someone to come put us all in boxes in a grid.

I’ve come to believe it was necessary, even if it was jarring.

In the early stages of an organization, certain roles and responsibilities can live in one function or team, then migrate to new ownership as the company grows. As these changes occur, roles and responsibilities can become muddled or unclear, and it’s not uncommon for a group of people embarking on a new project to become confused about “who owns what.”

Setting aside the challenges of young organizations, as companies shift to hybrid-remote models it will become more and more important to develop practices that work well for people who work somewhat asynchronously. That includes writing things down and creating written records of decisions. 

Decision-making frameworks, like the one my peer was using, can help clarify roles and responsibilities and chip away at the need for synchronous meetings by encouraging you to ask a few questions when you’re designing a project, planning work, or making a decision:

  • Who is responsible for making sure this work is happening?
  • Who authorized this work and is responsible for approving it?
  • Who is expected to weigh in or contribute to the project?
  • Who needs to know about this work?

RACI, DACI? 🔗

There’s a large number of decision-making frameworks out there. Many people are familiar with the RACI model. Personally, I prefer the DACI model to record roles and responsibilities for any work that requires more than one team or department.

I also find DACI’s roles (driver, approver, contributor, informed) to be a little more intuitive to people new to these sorts of frameworks than RACI’s (responsible, accountable, consulted, informed). “Responsible” and “accountable” are hard concepts for people to tease apart, whereas “driver” and “approver” are easier to understand and distinguish from each other.

It’s important to note that this is not worth some sort of weird project governance nerd fight. The mere act of sitting down with a project plan and applying either of these frameworks will do some good, so if you’re at the point where it would be helpful to have a tool that helps you think about roles and responsibilities, you should just pick one and muddle through. It can be awkward at first, and there’ll be a lot of different preferences and understandings, but the immediate benefit is that you’re talking openly and transparently about something that often makes people uncomfortable.

What is DACI? 🔗

DACI stands for “Driver, Approver, Contributor/Consulted, Informed” and is used to describe the roles of people involved in a project, decision, or task. Here’s each role in a little more detail:

  • Driver: A single driver of the overall project: the person steering the car. The Driver develops the DACI for the project, identifies the high-level work that needs to be done, and leads the project throughout its lifecycle.
  • Approver(s): One or more people who make most project decisions, and are responsible if it fails.
  • Contributors: The people responsible for deliverables; and with whom there is two-way communication. Some people also refer to this part of the DACI matrix as “consulted” to account for people who should probably be asked to weigh in even if they aren’t delivering anything besides advice or context.
  • Informed: The people who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.

How do you make a DACI? 🔗

At its very simplest, a DACI can be a list. Just write down the four roles and fill it in with the people who should occupy them. That’s it. Some people like to make tables or forms, but it’s not necessary and can add extra work if you’re not proficient with using tables to organize information. Rather than wrestling with formatting, you should be spending your time thinking through roles and responsibilities.

Some DACI practices 🔗

It’s a good practice to put a DACI at the top of your project documents and talk it through with people when you hold a kickoff meeting.

If a group you’re working with hasn’t used DACI themselves, sharing something like this guide or one of the articles I list below as a pre-read can go a long way to making it seem a little less strange. In organizations where there’s a lack of trust or a lot of contentiousness, it can be strange and awkward to openly discuss this kind of thing.

For complex projects with a number of work streams, you may need to create a high-level DACI for the entire project, then DACIs for each work stream.

It’s not out of line for the “Approver” in a DACI to be a group (e.g. a senior leadership team), in which case the “Driver” is accountable for wrangling consent and finalization from the team in the “Approver” role. This isn’t an invitation to descend into consensus culture or require unanimity to make a decision: Sometimes people have to make the choice to “disagree and commit.” The Driver has the privilege of determining when productive conversation is exhausted and the work is ready for review by the Approver.

It’s a best practice for the person in the Driver role to make the DACI available for review and comment.

While the Driver is the ultimate decider of roles and responsibilities, asking for comment and feedback can help settle the sometimes tricky question of who’s consulted and who’s informed by giving stakeholders a chance to think about and comment on how they’re impacted by a project. That sort of review will often unearth somebody who might have gone missing otherwise. That can help ensure, when you get to the point you’re pushing ahead with an RFC or project document, that you’re not missing something.

If you’re doing something with broad implications for an entire organization or multiple departments/teams, asking the Approver for a quick review of the DACI before sharing widely is a good idea. They may have context about other departments or stakeholders that can help you craft a better, more inclusive DACI. In contentious environments, they can do some diplomacy with their peers.

Finally, remember that a little goes a long way, especially at first. DACIs and RACIs provide a level of structure that can feel awkward and stilted. If one team is used to talking in terms of roles and responsibilities but another isn’t there yet, a DACI can feel unusually assertive. So if you’re bringing DACIs to people who are new to them, be patient and be as kind as you are clear about the boundaries these frameworks represent.

More reading on DACI and decision-making frameworks 🔗

work process inclusion management