RAPID Decision-Making: How It Works and When to Use It

What is RAPID decision making?

RAPID is a decision-rights tool created by Bain & Company. It gives every participant in a significant decision one of five roles — Recommend, Agree, Perform, Input, Decide — and requires a single decider. Bain describes it as part of a disciplined approach that defines the “what, who, how, and when” of a decision.

In a McKinsey global survey, only 20% of respondents said their organisations excel at decision making. Fewer than half (48%) agreed their organisations decide quickly, 57% agreed on quality, and only 37% said they achieve both. Executives reported spending almost 40% of their time making decisions and believed much of that time was poorly used.

That gap is usually structural, not intellectual. The analysis is often fine; the ownership is not. RAPID makes ownership visible on paper, before the meeting where it would otherwise be negotiated informally.

> Important note: RAPID is a Bain trademark and is presented by Bain as a proprietary tool. You can use the role model without hiring Bain, but the label is not generic in the way RACI is.

What do the five RAPID roles actually own?

Each letter describes a different kind of work. The distinction that matters most is between Agree and Input: one can stop the recommendation, the other can only shape it.

Recommend: one owner, not a committee

The recommender drives the process, gathers input, and writes the proposal. Bain is explicit that only one recommender should be assigned. This person needs the decider’s trust and credibility with the other roles, because their job is to turn a messy set of opinions into a decision-ready option set.

In practice, the R is the person who would otherwise run the meeting, and giving them the pen changes it: instead of collecting opinions, they build a case against a deadline.

Agree: a veto, not a vote

The Agree role confirms that the recommendation is feasible to bring forward. Bain frames it around mandatory requirements such as legal or regulatory constraints, and says these roles should be assigned sparingly. If the recommender and the agreer cannot reconcile, the decider makes the call.

This is the most misunderstood letter. An agreer who says “I don’t love it” is out of scope. An agreer who says “this violates the data residency clause in our contract” is exactly in scope.

Perform: the people who have to live with it

Performers are accountable for implementation. Bain recommends assigning them early, and where possible giving them an Input role as well, because they spot delivery problems that a pure proposal review misses. They also execute faster when they understand the intent rather than just the instruction.

Input: expertise and exposure, without a veto

Input roles supply data, experience, and the perspective of people affected by the outcome. They must feel heard even when their advice is not adopted. That is a communication obligation for the recommender, not a formal power.

Decide: one name, one accountability

The decider commits the organisation, owns the trade-off, and should sit as close to implementation as possible. Bain’s guidance is one decider per decision. If a group must hold the D — a board, an investment committee — then the fallback rule has to be agreed in advance: majority vote, chair decides, or another tie-breaker.

A group D without a tie-breaker is not a decision right. It is a scheduling problem.

How do you map a decision in RAPID?

Mapping takes about 30 minutes for a single decision and pays back over the following weeks. The sequence matters, because naming people before agreeing on criteria invites politics.

1. Write the decision as a question with a date. “Should we renew the Salesforce contract at the proposed 12% increase, decided by 30 November?” is mapable. “CRM strategy” is not.
2. Agree the criteria first. Cost, risk, reversibility, customer impact, and timing. Write them down before names are attached.
3. Name one D. If two names appear, escalate the ambiguity now rather than in the final meeting.
4. Name one R. This is the person who will write the recommendation and run the process.
5. Add A only where a genuine veto exists. Legal, compliance, security, or a contractual approval right. If the answer is “they’d be upset,” that is an I.
6. List I, then P. Include the people whose work changes and the people who hold data the R needs.
7. Publish the map and the decision date. Put it where the team already works, not in a slide that disappears after the kickoff.

A quick test: ask each person to state their letter and what they are expected to produce. If two people give different answers for the same letter, the map is not finished.

Worked example: a $240,000 vendor decision

A 60-person software company is choosing a new analytics vendor. The annual contract is $240,000, and the incumbent offers an 8% discount for signing within five weeks. The old process has 11 people in the room, three meetings, and no named decider.

The old way cost more than the meetings. Three 90-minute sessions with 11 people is 49.5 person-hours; at a loaded rate of $65 per hour, that is $3,218 before anyone writes a document. The five-week slip also forfeits the 8% discount, which is $19,200 on a $240,000 contract. The total cost of not deciding is roughly $22,400 — for one vendor choice.

Under RAPID, the same decision runs in two sessions: one input round with Finance and the two users, and one decision meeting with the D, R, and the two A roles. The legal and security questions are resolved before the decision meeting, not during it. The saving is not mainly the meeting hours. It is the discount and the two weeks of engineering time that were waiting on a signed contract.

How is RAPID different from RACI and DACI?

RAPID, RACI, and DACI all assign roles, but they operate at different levels. RACI describes who does what for a task or deliverable. RAPID and DACI describe who does what for a decision.

The practical difference is the A. RACI has no formal veto, so a compliance objection can arrive as a surprise late in the process. DACI has an approver, but it does not separate “must be feasible” from “has expertise.” RAPID makes that separation explicit, which is why it fits regulated and contractual decisions better than a task matrix does. It also explains why RAPID is a poor replacement for RACI: they answer different questions, and a team can use RACI for delivery and RAPID for the six decisions that shape the project.

Does RAPID actually make decisions faster?

There is no randomised trial of RAPID that isolates its effect, so any claim of a precise speed gain would be invented. The available evidence is correlational and mechanical.

Bain’s ten-year research programme, covering more than 1,000 companies, found that decision effectiveness correlates with financial performance at a 95% confidence level or higher, and that top-quintile companies on decision effectiveness generated total shareholder returns nearly 6 percentage points higher than other companies. That correlates with performance; it does not prove that adopting RAPID causes the outperformance. Well-run companies may simply be more likely to use explicit decision roles.

The mechanism RAPID relies on is narrower and easier to defend: it removes the coordination cost of ambiguity. When the decider is known, the recommendation has a deadline, and the veto holders are visible, the number of meetings required to close a decision usually falls. That is an operational claim you can test inside your own organisation over a quarter, by counting days from proposal to decision before and after.

> Common mistake: Treating RAPID as a quality-control tool. It assigns accountability; it does not test assumptions. A weak business case with a perfect RAPID map is still a weak business case.

When should you not use RAPID?

RAPID is deliberately heavy. Bain itself notes that not every decision needs this level of effort and recommends starting with high-value or high-frequency decisions. Skip it when:

• The decision is cheap and reversible. Choosing a meeting time does not need five roles.
• The decision is a genuine emergency. In incident response, the incident commander decides and informs afterwards; the roles can be reconstructed in the post-mortem.
• The team is very small. Under five people, a short written note naming the decider often does the same job with less ceremony.
• The organisation cannot name a single decider. If leadership insists on consensus, a RAPID map will be treated as paperwork. Fix the governance first.
• The decision is already made. Retro-fitting roles to justify a predetermined outcome destroys trust in the framework faster than any process error.

A useful filter is a two-by-two: high impact and high frequency get a standing RAPID map; high impact and low frequency get a one-off map; low impact gets a default owner and a log entry.

Why do RAPID maps fail in practice?

Most failures come from a small number of predictable mistakes, and most of them are visible on the map before the first meeting.

Multiple deciders. Two D’s is the most common and most damaging error. It converts a decision into a negotiation between two offices, and the team learns to wait for both.

Agree inflation. Every additional agreer raises the chance that someone blocks the proposal. If each of four agreers has a 20% chance of objecting in a given round, the chance that at least one objects is 1 − 0.8⁴ = 59%. With two agreers, the same assumptions give 36%. That is why Bain says to assign Agree sparingly.

Input as decoration. If the input round happens after the recommendation is written, contributors correctly conclude that their time was for show. The next decision gets worse input.

Perform told last. Implementation resistance is often a communication failure, not a capability failure. Performers who hear the rationale early plan around it; those who hear the outcome late plan around it too, in a different way.

The map is created and then forgotten. Decision rights decay when new people join, when a reorganisation changes reporting lines, or when a decision is reopened under a new name. A map without a review date becomes folklore.

No record of the decision itself. The roles are assigned, the meeting happens, and nothing is written down. Six months later the same decision is reopened because nobody can remember what was agreed or why.

> Practical tip: Add three fields to your decision log: the decision date, the name of the D, and the review date. Those three fields prevent more re-litigation than a 20-page governance document.

How do you keep decision rights alive after the meeting?

The framework only works if the decision survives contact with the following month. That requires a small amount of persistent structure: a decision log, a named owner, a rationale, the date, and the tasks that follow.

This is the gap where most teams fall back to documents and chat threads. A decision gets made in a meeting, summarised in a slide, and then buried. The people in Perform roles rebuild the context from memory, and the next decision starts from zero.

Doitify is built for the execution side of that problem: projects, tasks and sub-tasks, owners, due dates, dependencies, and reports in one workspace, with a decision and its follow-up tasks living next to the work they affect. Doitify is our product, so we know its strengths and its limits. For a team that only needs a shared list of decisions, a simple document is enough; the value appears when decisions generate multi-step execution that has to be tracked.

Conclusion

RAPID is not a method for analysing options. It is an accountability map. Its value is that it makes the invisible parts of a decision visible: who decides, who can say no, who executes, and who only advises.

Use it where the cost of ambiguity is real — vendor contracts, pricing changes, hiring, and anything that crosses legal or compliance. Keep the map small, keep one decider, and keep the Agree role rare. Then write the decision down. A decision that cannot be found three months later was not really made; it was only discussed.

If this post on rapid decision making was helpful, you might also enjoy All-in-One Project Management and CRM Software and Capacity vs Availability in Project Management: Key Differences and How to Use Both.