Bottleneck Analysis
Finding the single slowest step that caps the throughput of a whole process, because that is the only place adding capacity actually helps.
What it is
Bottleneck analysis rests on a stubborn fact about any multi-step process: its total output is limited by its slowest step, no matter how fast every other step runs. That slowest step is the bottleneck. If a factory line has stations that can each handle 100, 60, and 90 units an hour, the line produces 60 an hour - period - and speeding up the 90-unit station changes nothing. The method is the disciplined search for that binding constraint, because it is the only place where investment, staffing, or process change actually raises output. Everywhere else, improvement just builds up idle capacity or inventory in front of the true constraint.
When to use it
Use it whenever a case involves a process with stages and a question about throughput, capacity, wait times, or 'why can't we produce/serve more?' - manufacturing lines, hospital patient flow, call centers, order fulfilment, kitchens. It is the right lens the moment you hear that output is capped and someone proposes spending to fix it. It is less relevant for pure market, pricing, or strategy questions with no process flow. Do not assume the bottleneck is the busiest-looking or most expensive station; the analysis exists precisely because intuition often points at the wrong step.
How to apply it
Map the process as a sequence of steps and find the capacity (units per unit time) of each. The step with the lowest capacity is the bottleneck, and it sets the throughput of the entire process. Confirm it by looking for the symptoms: inventory or a queue piling up just before it, and idle time just after it. To raise output, act only on the bottleneck - add capacity there, offload work from it, or reduce its cycle time - and recheck, because relieving one bottleneck usually shifts the constraint to the next-slowest step. Keep the units clean throughout (units per hour, patients per day) so you are comparing like with like, and reason about the whole chain rather than optimizing a step in isolation.
Common mistakes
The classic error is improving a non-bottleneck step and expecting more output - it produces none, just idle capacity or a bigger pile of work-in-progress. Another is assuming the bottleneck is fixed forever; fix it and the constraint jumps elsewhere, so you must re-analyze. People also confuse the busiest or most stressed-looking station with the true constraint, and they forget that variability and downtime effectively lower a step's real capacity below its nameplate number. And they optimize local efficiency (keep every station 100% busy) which, upstream of a bottleneck, just creates waste.
Example
An urgent-care clinic complains that patients wait hours and wants to hire more doctors. Mapping the flow - check-in, triage nurse, doctor exam, lab, discharge - you measure capacity per hour at each step and find the doctors can actually see more patients than the single triage nurse can process. The nurse, not the doctors, is the bottleneck: a queue builds at triage while exam rooms sit partly idle. Hiring more doctors would add cost and change throughput not at all. Adding a second triage nurse (or offloading routine triage to a protocol) is the move that raises patient flow. The analysis redirects the spend from the intuitive fix to the one that works.
Practice it
Practice on operations and capacity cases by mapping the full process, computing each step's throughput, and resisting the urge to fix the step that merely looks busiest. The skill to build is identifying the true binding constraint, acting only there, and re-checking where the bottleneck moves to next.