Decision Rights (Who Has the D?)

The idea

In "Who Has the D?", published in Harvard Business Review in January 2006, Paul Rogers and Marcia Blenko of Bain & Company argued that an organisation's performance depends on making good decisions quickly and carrying them out, and that decisions stall when the roles around them are unclear.

Their tool is RAPID, five roles for any important decision:

• Recommend: drives the process, gathers input and proposes a course of action.
• Agree: must sign off on the recommendation, used sparingly, for example for legal or regulatory constraints.
• Perform: carries out the decision once it is made.
• Input: provides facts and expertise that shape the recommendation, without a veto.
• Decide: makes the final call and commits the organisation to action.

The letters spell an acronym, not a sequence. Bain's guidance is that there should ideally be one decider for each decision. Similar tools exist: RACI (Responsible, Accountable, Consulted, Informed) assigns roles to tasks and activities, and DACI (Driver, Approver, Contributors, Informed) is a variant often used for project decisions. RAPID's focus is the decision itself.

Why it works

Unclear rights cause stalls and relitigation. When several people believe they can veto, or nobody believes they can decide, decisions drift or get reopened every time a new stakeholder appears.

Separating input from agreement speeds things up. Most people need to be heard, not to approve. Saying so turns a dozen vetoes into a dozen useful inputs.

One decider means one accountable owner. It is clear who must weigh the trade-offs, and who to go to when circumstances change.

Where it applies

• Architecture boards and review forums, which often blur advice and approval, so teams are unsure whether a review is a gate or a consultation.
• Cross-team and platform decisions, such as shared standards or interface changes, where several teams each feel they own the outcome.
• Enterprise and business trade-offs, such as build versus buy, where finance, security, delivery and product all have a stake.
• Operating model design, deciding which decisions sit with teams and which with a central function.

How to apply

1. List the decisions that matter. Focus on recurring or contentious ones, such as technology standards, exceptions and major investments.
2. Assign the roles by name or role. For each decision, name the D, the R, the few who must A, the I and the P.
3. Keep Agree rare. Reserve it for constraints that really require sign-off, such as security or regulatory compliance.
4. Publish and use it. Put the decision rights next to the architecture decision records, and open each contentious meeting by confirming who decides.
5. Review when decisions stall. A decision reopened repeatedly is a sign that rights are unclear or not respected.

Example scenario

A company's architecture board had spent four meetings on whether teams could adopt a new event-streaming platform. Security, the platform team and two product groups each believed they had a veto, and every meeting reopened the previous one's conclusions.

The lead architect proposed decision rights for technology adoption: the platform team recommends, security must agree on data controls, product teams give input, delivery teams perform, and the chief architect decides. The next meeting heard the recommendation, recorded security's conditions, and the decision was made and written up the same day. Later questions went to the decision record rather than back to the board.

Questions to ask

When not to use it

• Small, reversible team decisions, where formal roles add more ceremony than value.
• Genuine emergencies, where an incident commander already holds clear authority.

How it misleads you