Here’s What To Do When DACI Decision-Making Falls Short

More and more companies are using frameworks like DACI, RACI and RAPID in an attempt to improve decision-making by assigning clearer decision-making responsibilities. Unfortunately, DACI sounds good in theory but rarely meets expectations in practice. Here’s why that is, and what to do about it.

Those who do not learn history are doomed to repeat it.

Internet legend has it that the DACI (Driver, Approver, Contributor, Informed) framework was developed at Intuit in the 1980s. More recently, consultants at Bain & Company created the RAPID (Recommend, Agree, Perform, Input, Decide) framework, derived from their work on strategic decisions at large companies.

Both of these frameworks give homage to an earlier project management framework called RACI (Responsible, Accountable, Consulted, Informed), with apparent origins in the acronym-happy management consulting theories of the 1950s.

RACI came about in the post-war days of clean org charts and waterfall projects, when matrixed organizations were rare and agile projects were far in the future. Back then operational efficiency was more important than innovation. As a result, rigid frameworks made sense and worked well.

Today, innovation is the sine qua non of business success. Authoritarian hierarchies and detailed Gantt charts are not going to rise again and replace collaborative project teams and iterative sprints. The rigid old world was simpler, but it was also slower.

So when companies borrow DACI framework lessons from the past, it shouldn’t be surprising that results fall short of expectations so often.

A particular type of decision causes most decision-making problems.

Most decision-making problems are caused by decisions that affect people who aren’t in the room (or on the thread) when the decisions get made. That includes not only people who will have to go along with the decision but also people with enough power to override the decision.

That’s why frameworks like DACI are so appealing. They seem to get to the heart of the problem — who is playing what role? It seems logical that if we figure out who is in what role up front, then our decisions will go a lot more smoothly.

That’s partly right but mostly wrong. To be precise, for DACI it’s about one-quarter right and three-quarters wrong.

The D in DACI works great...

D stands for Driver, and it really works.

A Driver has clear responsibility for getting a decision done, and this role is even more critical in today’s speedy world than it was in the rigid past. Someone has to grab hold of each decision and drive it to the end, or else decisions risk getting stuck in the matrix or lost in the dust of the next sprint.

Some DACI disciples say there can be more than one Driver at a time, but that causes predictable problems. There’s a reason kids learn to “call the ball.” If it could be any one of us, then all too often it’s none of us, and the ball gets dropped. Decisions can be passed from one Driver to another as they unfold, but multiple decision Drivers at the same time is a bad idea. Keep decisions to one Driver, and you’ll have fewer dropped balls. 

Note that the RAPID framework does not have a clear Driver role. Because of this, it is not a pragmatic solution for most decisions in most organizations. It is suited to strategic decisions that are supported by major process oversight, but it does not work well for the far more common and smaller-scale decisions that cause the most problems within organizations.

...the ACI in DACI, not so much.

Unfortunately, there are three more letters in the DACI acronym, and that’s where the problems lie.

Let’s start with Approvers. Most decisions have multiple Approvers, since decisions that affect people who aren’t in the room usually span functional or organizational lines.

That is not a problem by itself. Having multiple Approvers is appropriate, it’s like having multiple referees on a field, each with a different view. Referees enforce the rules and certify the results but don’t preemptively act to influence the outcome.

The problem is that Approvers often have a hard time staying in their role.

Rather than reviewing and approving final decisions, most have learned to lead by controlling or influencing the decision-making process itself. They often act like parents “coaching” from the sidelines, usually with good intentions but almost always with dis-empowering results.

Even more debilitating, multiple Approvers often want their lines of responsibility to be in the driver’s seat. It is normal in these situations for each Approver to assign their own Driver and tell them all to get together and figure it out “collaboratively,” with predictable ball-dropping results.

But this Approver problem just teases the real problem with the ACI (Approver, Contributor, Informed) roles, and responsibility frameworks in general.

The Big Problem: Roles can’t be assigned correctly until AFTER decisions are made.

Decisions are about making or responding to changes. That means your business will be different after you make a decision, and this causes a consistent problem when assigning roles. If you don’t really know what will be affected until after the decision is made, then you don’t really know who needs to be in which roles upfront.

When roles get assigned upfront based on guesses about the final decision, our research indicates that one of these problems happens about 90% of the time:

• Slow, frustrating escalations when challenges emerge and choices change. This is the most common problem since decisions are fundamentally about making changes. Imagine a business team deciding on the price for a new offering with a nice tight DACI. They decide that a low subscription price is best and move forward. Then things start going sideways. IT finds out and says they can’t support it, and the field can’t figure out how to comp salespeople. Soon the team realizes they had DACI blinders on. They weren’t making a new pricing decision, they were really making a new business model decision, and now they need a super-DACI with more senior people involved. If these slow, frustrating escalations happen enough times, then the company will create a pricing committee to act as a DACI escalation clearinghouse, often leading to the next problem.
• Low-quality, low-innovation decisions when frameworks dominate. This is a serious problem in innovation/competition-driven markets. As an example, it is often the case that pricing for new offerings must be approved by executives whose businesses may be affected by the new price. From a role-based perspective, that makes sense, of course. But from an innovation/competition-based perspective, that injects a massive bias to maintain the status quo by valuing the current internal company view over innovative/competitive external views. It’s a sure sign of low-quality, low-innovation decision-making if the final choice is predictable because of the people involved rather than the problem being solved.
• Expensive, complex change-management efforts to categorize all decisions. Experienced managers and consultants know that “it can be hard to get the DACI right,” i.e. it doesn’t work that well as a standard practice. So sometimes they invest a lot in categorizing decisions and creating standardized frameworks for how to use the framework. Using the pricing example, they might have different documented DACIs for pricing changes for large product lines, small product lines, fixed prices, subscription prices, large discounts, small discounts, regional pricing, and so on. This can work for very large companies with enough scale to afford and leverage the investment, but this bureaucratic approach often hamstrings innovation-oriented decisions that don’t fit well with standard practices.

The net result of these problems is that role-based responsibility frameworks like DACI tend to be promising in the abstract but confusing and counterproductive in practice. 

The Solution: Assign a Driver, expect inclusion and keep track.

These frameworks are appealing because today’s much faster world demands decision-making clarity more than ever before. So to get clarity, drop the ACI from DACI and embrace simplicity:

• Assign a Driver. This is the only role that really matters for decision-making success. If there is one clear Driver, then they can soldier through all the challenges above and land the decision. The Driver is on the hook to get the decision done (i.e. made well with the right input) and executed (i.e. approved by and communicated to the right people). If the current Driver isn’t the right person to do it, then it’s their responsibility to get it handed off to the right person. If you don’t have enough Drivers, go hire some.
• Expect inclusion. Don’t get confused by the constraints of ACI role definitions. Instead, make sure the Driver knows that it is their job to get input from everyone who could contribute to the decision and give everyone who could block it the opportunity to object. The Driver may not be able to rely on old practices of meetings and emails to do this, especially if there are lot of people are involved. They may need to use interactive polls or other ways of gathering group input. Drivers will need to be more transparent about decisions than is the case today, and more open to iterating when new perspectives come in. And everyone else should expect to be held accountable for their decision participation, or lack thereof.
• Keep track. Decisions are far too important and too slippery to rely on typical ad hoc communication and tracking. The Driver and everyone involved in a decision should be expected to keep track of their inputs to the decision, what was decided and why, and how the actual results of decisions compare to upfront expectations. Doing so as you go makes it easier to include other informed perspectives along the way, and increases accountability for everyone involved without having to assign roles upfront.

In the steady days when DACI was first created, the most important decision question was “Who is responsible for what?” But in the heady days of our innovation economy, the most important question is “What are we going to do next?”

The best answer to that question is the same every time: assign a Driver, expect inclusion and keep track.