Where Decisions Get Stuck
Most organisations don’t have a shortage of decisions to make:
- Priorities need to be agreed
- Projects need approval
- Suppliers need selecting
- Budgets need allocating
- Problems need resolving
The difficulty is often not making the decision itself; it’s getting the decision to the point where it can be made.
A relatively simple decision can pass through multiple people, meetings and approval stages before anything happens. Information is requested, recommendations are challenged, additional stakeholders become involved and decisions sometimes travel backwards because something was missing earlier in the process.
Individually, each step can appear perfectly reasonable but collectively, they can turn a decision that should take hours into one that takes days or weeks and because much of that time is spent waiting rather than actively doing anything, the problem can be surprisingly difficult to see.
Start with a real decision
The easiest way to understand how decisions actually move through an organisation is not to map “decision-making” as an abstract process.
Simply pick one - it could be approving a campaign, selecting a supplier, prioritising a development request or agreeing a change to an existing process.
Choose something that happens regularly enough to be representative, then identify a recent example and trace what actually happened.
Start with a few simple questions:
- Who initiated the decision?
- What information was needed?
- Who provided that information?
- Who made a recommendation?
- Who needed to approve it?
- How long did each stage take?
- Did the decision ever move backwards?
Don’t worry initially about how the process is supposed to work, just map how the decision actually happened.
That difference is often where the complexity starts to become visible.
Find the points of friction
Once you’ve mapped the decision, the next step is to look at where time and effort are actually being spent.
The obvious place to start is time; how long did the decision spend at each stage and, more importantly, how much of that time was spent waiting?
A decision might only require a few hours of actual work but still take three weeks to complete because it spends most of its life sitting in inboxes, waiting for meetings or moving between people.
So look for the points where this is happening:
- Where does the decision wait?
- How many people are involved?
- How many approvals are required?
- Where is additional information requested?
- Where does responsibility become unclear?
- Where does the decision move backwards?
- Which stages regularly require meetings or escalation?
The aim here is not simply to find the slowest person or department; delays are often symptoms of something deeper in the way the organisation works.
An approval might exist because nobody is confident about who has authority to make the decision, a meeting might be necessary because information is spread across several systems or teams.
Additional stakeholders might become involved because responsibilities overlap, or because previous decisions have created a culture where people are reluctant to take ownership.
This is also where those backwards loops become particularly useful.
If a decision repeatedly returns to an earlier stage because information is missing, the problem may not be the approval process at all; it may be that the right information isn’t available when the decision begins.
In addition, if almost every decision eventually reaches the same senior person, the organisation may have created a bottleneck by concentrating authority rather than distributing it.
The important question therefore isn’t simply where is the decision getting stuck? It’s why does it need to stop there in the first place?
Make the decision easier to make
Once you understand where a decision is getting stuck and why, the temptation is to redesign the entire process but most of the time, you don’t actually need to.
Instead, start with the points of friction you’ve already identified and ask what would need to change for the decision to move through them more easily.
That could mean:
- Removing an approval that no longer serves a useful purpose
- Giving someone clearer authority to make the decision
- Making information available earlier in the process
- Reducing the number of people who need to be involved
- Clarifying where responsibility sits
- Replacing a recurring meeting with a simpler way of sharing information
- Defining when a decision genuinely needs to be escalated
The objective isn’t to remove governance or encourage people to make decisions without the information they need; it’s to make sure that every stage exists for a reason.
This is particularly important when looking at approvals - organisations often add controls in response to individual problems, but rarely go back later and ask whether those controls are still necessary. Over time, a decision can accumulate layers of approval that made sense when they were introduced but add little value today.
Once you’ve made a change, follow the same decision again…
- Has the overall time reduced?
- Are there fewer hand-offs?
- Does it still move backwards?
- Are fewer people involved?
- Can more decisions now be made without escalation?
You don’t need a complicated set of metrics; you’re simply trying to establish whether the decision has become easier to make without reducing the quality of the outcome.
And if it hasn’t, go back to the map because the purpose of mapping decisions isn’t to create another process diagram that sits forgotten somewhere; it’s to make visible the complexity that has accumulated around them.
Sometimes the most useful question an organisation can ask isn’t who needs to make this decision? It’s what is stopping them from making it?
