Start with a specific delay.
A workflow bottleneck is a point where work cannot move forward as quickly as it arrives. You may see a growing queue, repeated follow-ups, or deadlines slipping at the same stage. Bottleneck analysis asks where that constraint is and what is contributing to it.
“Our process is inefficient” is too broad to investigate well. “Complete requests wait three days for approval” gives you something to examine. Choose a starting event, an ending event, and a type of work. Keep urgent exceptions separate from routine requests so the comparison means something.
Map how the work actually moves.
Follow a few recent examples from start to finish. Include the steps people take in practice: the spreadsheet outside the official system, the informal approval, and the email asking for missing information. A procedure describes intended work. A current-state process map should show what happens.
- Who receives the work, and what tells them it is ready?
- What information or decision do they need before acting?
- Where does the work wait, return to an earlier step, or change hands?
- Who decides what takes priority when several requests arrive together?
Check the map with people who perform the work. If their accounts differ, keep that disagreement visible and look for records or observations that can clarify it.
Separate working time from waiting time.
A task might take twenty minutes to complete but spend two days waiting to begin. Those are different problems. Record when work arrives, when someone starts it, when it is completed, and whether it comes back for correction.
A useful first measurement plan can stay small:
- Turnaround time: elapsed time from the agreed start to finish.
- Queue age: how long unfinished items have been waiting.
- First-pass completion: how often an item advances without being returned.
- Handoff completeness: whether the next person receives what they need.
Look at variation as well as averages. A process that handles most requests quickly but leaves a smaller group waiting for weeks needs a different explanation from one that is consistently slow.
An approval queue that looks like a staffing problem.
Imagine a service team whose requests keep backing up before manager approval. The first explanation is that the manager needs help. But a closer look shows that some requests arrive without the information needed for a decision and move back and forth several times.
That finding does not prove staffing is adequate. It creates a more specific question: how much of the delay comes from incomplete requests, and how much remains when requests arrive ready for review?
The team could compare those groups, check the manager’s competing responsibilities, and test a short readiness checklist. Measuring the whole request cycle matters: a faster approval stage is not an improvement if the same delay moves to the person preparing the request.
Test one change and watch the whole process.
Choose a change that follows from the evidence. Agree on who will use it, where it applies, the review period, and what improvement would look like. A clearer handoff, a decision rule, or removing an unnecessary repeat step may be worth testing; new software is only useful if it addresses the actual constraint.
Compare the result with the baseline and record other changes that could explain it. Check for extra workload, reduced quality, or a queue growing elsewhere. If the result is unclear, gather more evidence before rolling the change out more widely.
This is the same logic behind our approach to process improvement: define the gap, examine the work, evaluate competing explanations, and connect each recommendation to a practical test.