Decision Drift: The Quiet Risk That Derails Delivery

Most delivery issues don’t come from bad planning. They come from decisions that never fully land. Teams “agree in principle,” then reality shows up: an approval gap, a role gap, a priority conflict, or a dependency that wasn’t owned. Work keeps moving, but it moves on borrowed authority. Later, the decision gets reopened, people act surprised, and timelines absorb the cost.

• Decision drift has a distinct smell:

• Decisions are spoken, not recorded.

• The decider is implied, not named.

• The people who must execute weren’t in the room, or weren’t bought in.

• “We can revisit” becomes the default clause.

• Exceptions pile up and become the real operating model.

The fix is not more meetings. It’s decision mechanics. A decision is only real when three things are true: someone owns it, the required inputs are explicit, and the decision is legible after the meeting ends.

A practical pattern is to standardize decision roles and reuse them across recurring decision types. Name who recommends, who provides input, who must agree, who executes, and who decides. RAPID works well when stakeholders are many and authority is unclear because it forces clarity on who decides and who executes. If you use RACI, watch the common failure mode: it becomes a negotiation artifact (“make me Accountable”) instead of a decision system.

Two high-leverage moves prevent drift.

First, set a “decision threshold” up front: what requires a recorded decision, and what can be handled as a working assumption. Without a threshold, teams either over-formalise everything or formalise nothing. The drift lives in the middle.

Second, separate “discussion” from “closure.” Don’t end meetings with “sounds good.” End with a closure statement: what was decided, by whom, and what changes next. If there’s no closure statement, you didn’t decide—you socialized.

A lightweight decision log prevents re-litigation and gives future teams the context that’s usually missing. Keep it small and brutal:

• the choice that was made

• options considered (including “do nothing”)

• decision owner

• key assumptions and constraints

• a review date or trigger (so it can be revisited when conditions change)

Add one more field if you want this to work under pressure: “what this decision unlocks.” Decisions exist to unblock action. If nothing unlocks, it wasn’t a decision—it was commentary.

Small but high-leverage artifact: a one-page “decision charter” for the workstream. It lists the recurring decisions that matter (scope changes, go/no-go, design choices, vendor commitments), names the decider for each, defines required inputs, and sets the cadence for review. It turns decision-making from personality-driven to system-driven.

Failure mode to avoid: treating escalation as progress. Escalation is not a strategy; it’s a symptom. If decisions require escalation every time, the decision rights are broken, and the team is operating without authority.