How to Diagnose a Process Bottleneck

A process begins and ends somewhere. Unless those boundaries are explicit, two people can collect accurate numbers and still describe different systems. One person counts enquiries. Another counts complete requests. A third counts envelopes prepared. None of these numbers is automatically wrong, but they cannot be substituted for one another.

Write a plain sentence: “We are observing the preparation of one complete activity pack, from receipt of a usable request to a checked pack ready for collection.” That sentence names an entry condition, a unit and an exit condition. It also tells you what lies outside this particular observation, such as how people first heard about the activity or whether they later collect the pack.

Choose an end condition that means something useful to the receiver. “The printer finished” may be a valid completion for a printing step, while still being an incomplete result for someone who needs collated pages in a labelled envelope. A local stage can report excellent output while the person waiting receives nothing usable.

Next, identify the question the observation should answer. “Why does the prepared-pack queue keep growing?” is narrower than “Why are we inefficient?” The first directs attention toward arrivals, checks, readiness and exits. The second can expand indefinitely and invite unsupported judgements about people.

Record exclusions as well. If unusual requests follow another route, say whether they are counted separately. If a completed pack later returns because its requirements changed, identify that event instead of silently treating it as an ordinary new request. A boundary should reveal exceptions, not erase them.

Keep the observation within work you are authorised to examine, using ordinary process information rather than unnecessary personal details. The aim is to understand the movement of work. A temporary label such as Pack 17 usually teaches more about a delay than a person’s name.

Finally, agree the time window. Four hours, one session and one week are not interchangeable. Record the actual start and finish, the opening unfinished work and any work left at the end. This prevents a productive-looking period from borrowing unacknowledged work prepared earlier.

A sound boundary does not solve the problem. It makes the eventual answer interpretable. When the larger recovery purpose remains unclear, Strategy: Choose the Next Useful Move helps connect a local investigation to a worthwhile outcome.

Contents · Next chapter

Begin with an ordinary walkthrough. Take several real or simulated work items and ask what happened next at each step. Include the moments when nothing happened: awaiting a missing detail, waiting for a shared tool, sitting in a tray until a scheduled handoff, or returning to an earlier step.

ASQ’s flowchart guidance recommends mapping current work with its participants and checking the map for delays, bottlenecks, errors and handoffs.

For your own map, a short table is often sufficient. The following is an original example, not a required industry template.

The repair holding area matters even when no repair occurs during the observation. Without it, failed checks may disappear from the account. The same is true of incomplete requests: if they are outside the usable-request boundary, maintain a separate count so that a clean process record does not conceal a growing problem at the entrance.

Ask someone familiar with the work to challenge the map. “We always check before filing” may describe the intended sequence. “On busy sessions, unfinished packs are filed temporarily in another tray” describes an exception that could explain missing records. Understanding that exception is more useful than decorating an inaccurate diagram.

Do not make the first map excessively detailed. Separate steps when they have meaningfully different inputs, resources, waiting conditions or completion rules. Joining everything into “processing” hides the location of delays. Splitting every hand movement into a separate box can hide the overall journey beneath detail.

Look particularly at handoffs. A task may be finished at one station but invisible to the next because a status label was not updated. The receiving station then appears underused while completed work waits elsewhere. That is a different explanation from insufficient processing time.

Keep a distinction between the map and the evidence supporting it. The map tells you where work may travel. The counts and observations tell you where it travelled in the period you examined. Diagnosis needs both.

Contents · Previous chapter · Next chapter

A useful unit remains identifiable from entry to exit. In the activity-pack case, one unit is one requested pack. It is not one sheet, one printing run, one envelope movement or one check attempt. Those other measures can help explain resource use, but they answer different questions.

Suppose assembly prepares ten envelopes, each containing six sheets. Reporting “60 completed” beside a checking count of ten would create a false sixfold difference. The assembly number measures sheets; the checking number measures packs. Before dividing or comparing, write the unit beside every count.

Time requires the same care. Minutes of active work, minutes of resource availability and elapsed minutes in the workflow are different quantities. A pack may require ten minutes of work while taking an hour to finish because it waits between steps. Two simultaneous resources may provide two resource-minutes during one calendar minute, but only if both can genuinely work at the same time.

Define a successful exit explicitly. A checked and accepted pack can count as one completion. A pack that fails checking remains unfinished work even though the checking activity itself has been completed. Otherwise, the process appears to improve merely because more defective work has been pushed to its endpoint.

Keep attempts separate from unique work items. A pack checked twice is one pack and two attempts. Its two visits consume time, but accepting it eventually should create only one accepted completion. If attempts and packs share the same column, rework can inflate throughput on paper.

Mixed work may need separate categories. A two-page pack and a forty-page pack should not be assumed to require equal effort simply because both fit the definition of a pack. Begin with a sufficiently similar group, or record the mix and explain its effect. Avoid inventing weighted units unless you can explain and support the weights.

Names also help. Use “accepted packs per observed hour” instead of a bare “productivity rate.” Use “minutes per first check” instead of an ambiguous “cycle time.” Clear labels make an error easier to notice before it shapes a decision.

An important test is whether another person can reconstruct your calculation without asking what the numbers mean. If they cannot, improve the labels before collecting more data. Precision in language is part of precision in measurement.

Contents · Previous chapter · Next chapter

Before the observation starts, count the work already inside the boundary. This opening work-in-progress, often shortened to WIP, may be waiting or actively being handled. Record which stage holds each item so that the same pack does not appear in two opening totals.

During the window, record new arrivals and accepted exits. At the end, count unfinished work again. If no item was cancelled, discarded or transferred outside the stated boundary, the account should reconcile:

Closing unfinished work = opening unfinished work + arrivals − accepted completions.

This is a count of movements, not a promise about speed. If other exits occurred, add separate columns for them. A cancelled request is not an accepted completion. A lost record is not evidence that its associated work disappeared.

At each step, keep the same account: opening items plus incoming items, minus outgoing items, equals closing items. An item can leave checking for either acceptance or repair. Both are departures from the checking stage; only one is an accepted departure from the whole workflow.

You do not need elaborate software to begin. A small log can contain a temporary item label, arrival time, readiness state, stage transitions, check outcome and final status. If exact timestamps would disrupt the work, use agreed observation intervals and label the resulting precision honestly. Do not report minute-level certainty from a half-hour headcount.

A snapshot is useful but incomplete. Six items waiting at noon could represent a stable buffer, a growing queue, a batch that just arrived or a tray that has not been emptied in days. Compare the snapshot with movements and with the age of at least a few items.

Be especially careful around the finish time. A pack completed at 13:02 does not belong in a count ending at 13:00. It can be reported in a follow-up note, but moving the boundary to include favourable completions and exclude unfavourable arrivals changes the question after seeing the result.

When the counts fail to reconcile, investigate the record before explaining the process. Common causes include duplicated labels, an unrecorded repair tray, changed entry rules or a handoff recorded as a final exit. A mismatch is useful evidence of a recording gap. It is not an invitation to force the totals to agree.

Contents · Previous chapter · Next chapter

Here is the main fictional case. A community learning project prepares one standard pack type. Its coordinator wants to understand why checked packs are not keeping pace with usable requests. The observation lasts four calendar hours, from 09:00 to 13:00. Every count below refers to one pack unless explicitly labelled as an attempt or a resource-minute.

At 09:00, six usable requests await logging, eight logged requests await assembly and ten assembled packs await checking. No pack is actively being handled at the opening snapshot, and the repair holding area is empty. Opening unfinished work is therefore 6 + 8 + 10 = 24 packs.

During the four hours, 60 new usable requests arrive. Logging sends 60 packs onward, assembly sends 60 onward and checking examines 50 distinct packs once each. Of those 50 checks, 45 pass and five identify discrepancies. The five unsuccessful packs enter repair holding and receive no further work during this observation. There are no cancellations, lost packs, other exits or repeated checks.

The local accounts agree with the whole account. Closing unfinished work is 6 + 8 + 20 + 5 = 39 packs. Independently, 24 + 60 − 45 = 39 packs. The increase of 15 consists of ten additional packs at checking and five in repair holding.

That agreement makes the account credible enough to examine. It does not yet identify the cause. You still need to know whether checking had usable work available, how much time each resource had, whether packs could leave after passing, and whether this period was unusual.

The observed accepted throughput is 45 packs ÷ 4 hours = 11.25 accepted packs per calendar hour. New usable requests arrived at an average of 15 per calendar hour. Those averages describe this window. They do not imply evenly spaced arrivals, a permanent processing rate or a forecast for the next session.

Also notice that the 45 accepted packs are not necessarily 45 of the 60 new arrivals. Some began inside the workflow. Without item-level tracking, dividing accepted completions by new arrivals would mix cohorts and would not measure the success rate of this session’s new requests.

Contents · Previous chapter · Next chapter

The fictional project records its resource assumptions. Logging has one complete work position. Assembly has two independent positions that can operate simultaneously. Checking has one complete position. Each position has 180 usable minutes within the four-hour window; the other 60 minutes are scheduled periods unavailable to this workflow. No position borrows the same operator or essential tool from another during its usable periods.

The resources therefore do not each supply 240 usable minutes. Nor does assembly supply just 180 minutes: its two independent positions together supply 360 resource-minutes. Their simultaneous use changes capacity without changing the four-hour calendar boundary.

For this deliberately simplified case, logging takes exactly three resource-minutes per pack, assembly three, and the first check 3.6. These times include the routine handling assigned to each step. The observed pack type is uniform, and there are no additional changeovers or within-task interruptions. Actual settings would require observations of variation rather than assuming these exact times.

Each capacity figure is a conditional arithmetic ceiling for the stated time and task assumptions. It is not guaranteed output. A position cannot perform 120 assembly tasks if only 68 packs are available to it during the window, nor can it complete tasks before their inputs arrive. Here assembly has eight opening packs and 60 incoming packs, so 120 actual completions were never a realistic expectation.

The checking position uses 50 × 3.6 = 180 resource-minutes. Logging uses 60 × 3 = 180. Assembly uses 60 × 3 = 180 of its 360 available resource-minutes, distributed as 30 packs and 90 working minutes at each position in this example.

Checking has the smallest conditional task capacity, but remember that its units are attempts. A failed attempt consumes checking time without producing an accepted pack. The observed evidence also says usable packs were waiting whenever checking was available, and accepted packs could leave immediately. Checking was neither waiting for inputs nor prevented from releasing completed work during those periods.

Together, those facts support checking as the leading capacity-constraint candidate for this particular workflow and window. They do not justify a judgement about the person at that position, a change in staffing, or a claim that the same stage will constrain every future session.

Contents · Previous chapter · Next chapter

The checking queue grows from ten to twenty while logging and assembly finish with their opening counts unchanged. That is consistent with 60 packs arriving at checking and only 50 leaving it for either acceptance or repair. The arithmetic points to a mismatch at that step.

The observation of available work strengthens the explanation. A resource can look slow because upstream work arrives late, because an essential input is missing, or because completed output has nowhere to go. In this case, those alternatives were examined: checking had eligible packs throughout its usable periods and no blocked exit after acceptance.

Still, the number twenty is not decisive by itself. A queue may be deliberately large before a scheduled batch process. A tray may contain incomplete requests that cannot yet be worked. A large pile might include several days of abandoned work. Treating all three as identical would lead to different problems receiving the same intervention.

Ask what qualifies an item to enter the queue. “Ready for checking” should mean assembled and accompanied by the request information needed to judge it. If half the tray lacks that information, the visible queue exaggerates the amount of immediately usable work.

Ask how old the items are. A queue containing twenty packs that arrived five minutes ago means something different from a queue containing twenty that have waited since yesterday. Item age does not prove a capacity limit either, but it helps distinguish a temporary arrival burst from work that persistently cannot move.

Then examine the sequence. If a queue rises during a lunch closure and clears during the next usable period, a snapshot taken at the peak can mislead. If it repeatedly grows despite uninterrupted access to ready work, the case for a limiting stage becomes stronger. Record that pattern rather than choosing the most dramatic photograph.

Avoid trying to keep every upstream resource busy merely to make local activity look impressive. In the fictional case, sending more assembled packs toward checking without changing the limiting conditions would add work to a queue. It would not automatically increase accepted exits.

The useful question is whether an action helps the whole defined journey. Defence: Protect What Still Works is relevant here: preserve accurate labels, required checks and usable handoffs while investigating delay. Removing something that protects correct completion can make the queue shorter while making the result worse.

Contents · Previous chapter · Next chapter

Counts tell you how much work moved. A trace of one item tells you how its elapsed time was spent. Both views matter because reducing a task by a few seconds may make little difference when a pack spends most of its journey waiting for a handoff.

Lean Enterprise Institute’s time definitions distinguish measured task cycle time from the elapsed time needed to travel through the whole process.

Consider one fictional pack from the main case, using minutes after its arrival rather than clock times. It waits until minute 12, is logged from minute 12 to 15, waits until minute 35, and is assembled from minute 35 to 38. It then waits until minute 86.4 and is checked from minute 86.4 to 90. It passes immediately.

Active work totals 3 + 3 + 3.6 = 9.6 minutes. Waiting totals 12 + 20 + 48.4 = 80.4 minutes. Together they account for the 90-minute journey. The long wait before checking fits the queue evidence, although a single trace cannot establish the experience of every pack.

Do not call all waiting removable. Some waiting may come from agreed operating times, a necessary response from another party or a resource that cannot be used continuously. The observation tells you where elapsed time went; it does not grant permission to remove the condition that caused it.

Trace several items chosen by a rule established in advance, such as every tenth usable arrival, rather than selecting only the worst delay. Include unfinished traces separately. An item still waiting at the observation’s end has a known minimum elapsed time, not a completed journey time.

Also distinguish one item’s speed from the workflow’s output rate. A pack that moves through quickly may have entered when there was no queue. Its short elapsed time does not show that all packs could be processed at that pace simultaneously. Conversely, high accepted throughput during a window can coexist with long waits for work that entered much earlier.

Use these views together: count movements across the boundary, observe resource conditions, and trace a few journeys. Each catches mistakes that the others can miss.

Contents · Previous chapter · Next chapter

In the main case, checking examines 50 distinct packs and accepts 45 on their first attempt. The first-pass acceptance proportion for those examined packs is 45 ÷ 50 = 90%. The remaining five packs are unfinished, with recorded discrepancies. This percentage describes that examined group and those requirements.

It is not the proportion of new requests completed, because opening work contributed to the checked group. It is also not a forecast that every future group will have the same result. A different pack type or an unusual run of discrepancies could change both work time and the number of accepted exits.

The five unsuccessful packs matter twice: they failed to produce accepted completions during this window, and they create future repair work. Yet that future work must not be retroactively added to today’s observed resource use. None of the five was repaired or checked again before 13:00.

Suppose, as a separate planning illustration, correcting each of those five packs would require two assembly resource-minutes and a two-minute follow-up check. That would create ten assembly resource-minutes and ten checking resource-minutes of additional work. Those are conditional requirements under the new assumption, not measured work already completed.

A subsequent observation should record repair attempts separately and keep each pack’s identity. If all five later pass, count five accepted packs, not ten successes because there were both original and follow-up checks. The attempts explain the consumed time; accepted unique packs explain the useful exits.

Investigate the type of discrepancy as well as its frequency. Five failures caused by an unclear version label suggest a different next question from five caused by missing physical materials. “Quality problem” is too broad to choose a useful investigation. You need an observable mismatch with a stated requirement.

The checking queue does not make checking itself the origin of defects. A step that discovers an error may be protecting the receiver from an earlier mistake. Removing the check because it is where problems become visible can conceal the evidence while preserving the cause.

Record the good outcome you must protect: correct contents, correct label and a usable record, for example. Then distinguish time consumed by necessary checking from time consumed by avoidable confusion or repeated handling. That distinction turns a complaint about a slow station into a specific question worth examining.

Contents · Previous chapter · Next chapter

A queue, low output and unused resource time can appear together without proving a shortage of processing capacity. The queue may hold work that is not ready. The resource may be capable of more, while the workflow cannot yet supply the information or materials it requires.

Imagine a fictional request table with twenty entries, eighteen of which lack the selected pack version. A logging position cannot responsibly turn all twenty into usable instructions by working faster. The immediate question concerns the missing selection: when it is requested, how readiness is displayed and what happens when the answer does not arrive.

Separate total expressions of interest from ready arrivals. Interest may exist without complete specifications. Ready work may exist without reaching the appropriate station. Treating these situations as weak demand overlooks different obstacles at the entrance and handoffs.

Likewise, a low-output session with few requests, no growing ready queue and long idle periods does not establish a capacity bottleneck. It may simply contain less work than the available process could handle. That observation does not explain why demand is low, whether another session will differ, or whether the wider organisation is viable.

Several explanations can coexist. A morning may be limited by missing information and an afternoon by checking capacity. An improvement at the entrance might reveal a constraint that was previously hidden because too little ready work reached it.

State which explanation your evidence can actually support. “The checking station appears to constrain accepted output for this pack type under this schedule” is useful. “Checking is the problem” discards the conditions that made the observation meaningful.

The wider operational rebuilding guide helps choose between these problem types. This guide’s contribution is narrower: determine whether the pattern inside one defined workflow supports a capacity explanation, another explanation, or a need for better observations.

Contents · Previous chapter · Next chapter

The main case uses exact task times to make its arithmetic inspectable. Ordinary work is less tidy. Some tasks take longer, equipment is temporarily unavailable, arrivals cluster and several stages may depend on the same person or tool. A diagnosis should become more cautious as those differences become more important.

Suppose two assembly tables share one label printer. The tables may support simultaneous physical assembly, yet labelling may occur only one pack at a time. Adding their full nominal capacities would overlook the shared step. List dependencies before treating positions as independent resources.

The same problem occurs when one operator alternates between logging and checking. You cannot assign that operator 180 usable minutes at both stages within a period containing only 180 minutes of their availability. Split the time actually available to each activity, or model the combined resource explicitly.

Task mix can also change the apparent constraint. If one type requires three assembly minutes and another requires nine, a session with more of the second type may accumulate work at assembly. A previous observation of spare assembly time is evidence about its earlier mix, not a permanent certificate of surplus capacity.

Compare genuinely comparable windows. Record pack types, readiness rules, opening work, available time and unusual events. If these differ, show the differences alongside the counts. A single average can conceal the reason one period behaved differently.

Watch the arrival pattern as well. Thirty requests spread across three hours are different from thirty arriving in the final ten minutes. A closing queue after a late burst does not prove the process could not handle the same volume when distributed differently. You need to know when eligible work became available.

Do not fill missing observations with precision. If a resource was “available for roughly two hours,” avoid reporting a capacity estimate to two decimal places. A rough estimate can help choose what to observe next, provided its uncertainty remains visible.

A useful diagnosis survives reasonable challenges: would it still be plausible if the late arrivals were separated, the shared tool were counted properly, or the difficult pack type were examined alone? If the answer changes, that is information. Revise the boundary or explanation before proposing a larger intervention.

Contents · Previous chapter · Next chapter

A diagnosis becomes actionable when another person can inspect the evidence, recognise its limits and identify what observation would change the conclusion. A label alone does none of these things. “Bottleneck at checking” is a heading; the reasoning belongs underneath it.

Use a short record with six parts: boundary, observed pattern, leading explanation, alternatives considered, evidence still missing and the next diagnostic question. The following version belongs to the fictional main case.

Boundary: one standard activity pack, from usable request to accepted checked pack, 09:00–13:00. Opening unfinished work was 24; new usable arrivals were 60; accepted exits were 45; closing unfinished work was 39.

Pattern: checking received 60 packs and examined 50. Its queue grew from ten to twenty, while five unsuccessful checks created a separate repair holding count. The check position used all 180 available resource-minutes and had ready work available throughout those periods.

Leading explanation: checking is the strongest current candidate for the capacity constraint under the recorded pack type, task times and resource schedule. First-pass discrepancies also reduce accepted output and create further work beyond the observed window.

Alternatives considered: ready-work starvation and blocked accepted exits were not observed at checking. Assembly had independent spare resource time. The complete-request rule was maintained, and the movement counts reconcile.

Evidence still missing: whether the same pattern recurs, how variable checking time is in ordinary sessions, and which discrepancies account for the five unsuccessful checks. The observation does not establish a permanent constraint or a business-wide cause.

Next question: does a repeated observation with the same definitions show the same checking accumulation, and what portion of checking time involves finding or resolving ambiguous request information?

Notice that this record does not leap from diagnosis to removing a check or promising extra output. It identifies a candidate and a useful uncertainty. A future change should address the evidence while preserving the required result.

If more observations contradict the record, revise it. For example, discovery that the assembly positions secretly share the checking resource would invalidate the independence assumption. A challenge that changes the answer improves the diagnosis; it is not a failure to defend an earlier conclusion.

For keeping useful evidence and decisions consistent over time, Consolidate: Make Progress Reliable provides a broader learning route. The immediate operational task is to leave a record that the next observation can meaningfully confirm, narrow or overturn.

Contents · Previous chapter · Next chapter

Now analyse a different fictional workflow before reading the answer. A community craft project prepares personalised paper kits. The full observation boundary includes requests awaiting details, then logging, preparation and final checking. A request becomes ready only after its paper choice and kit size are known. The observation lasts two calendar hours.

At the opening snapshot, 22 requests await those details. Four ready requests await logging, four logged requests await preparation and two prepared kits await checking. There is no work actively underway at the snapshot. Thus, opening unfinished work is 32 kits or associated requests, each representing one eventual kit.

During the window, eighteen new requests arrive. Eight contain all required details; ten do not. Six of the previously incomplete requests receive their missing details and move to the ready logging queue. No request is cancelled or duplicated.

Logging completes eighteen tasks. Preparation completes twenty kits, and checking accepts 22 kits. There are no defects, repeat visits or other exits. Two logged requests reach preparation in the final minute and remain unfinished at the closing snapshot. All other described tasks fit within the available schedule.

Each of the following positions has ninety usable minutes within the two-hour window. The two preparation positions are independent and can work simultaneously. No resource or operator is shared across stages during usable periods. For this simplified case, logging takes three resource-minutes, preparation six and checking two per kit. Preparation’s twenty completions are split equally between its positions.

The observer sees the largest pile beside the incomplete-request tray and says, “That is obviously the bottleneck. We must speed up preparation.” Evaluate this statement using the information provided.

Work out the closing count at each location, the whole-workflow reconciliation and the conditional task capacity at each processing stage. Compare observed work time with available resource time. Then explain whether the evidence establishes a preparation capacity constraint, a broader lack of demand, or an incomplete-input problem that needs a different observation.

Finally, choose one next question. Make it specific enough that an answer could change your explanation. Do not propose new resources, remove requirements or claim that one afternoon proves how the whole organisation works. The challenge is to read the evidence more carefully than the most visible pile invites you to.

Contents · Previous chapter · Next chapter

Start with the incomplete-request holding area. It opens with 22, receives ten new incomplete requests and releases six newly completed requests to logging. It therefore closes with 22 + 10 − 6 = 26. This is the largest pile, but its items do not yet meet the entry conditions for processing.

The logging queue opens with four ready requests. It receives eight complete new requests plus the six clarified requests, then sends eighteen onward. Its closing count is 4 + 8 + 6 − 18 = 0.

Preparation opens with four, receives eighteen and completes twenty, leaving two. Checking opens with two, receives twenty and accepts 22, leaving zero. Closing unfinished work is therefore 26 + 0 + 2 + 0 = 28. The whole account agrees: 32 opening + 18 new arrivals − 22 accepted = 28 closing.

Next, examine capacity and time. Logging’s conditional capacity is 90 ÷ 3 = 30 tasks; it uses 18 × 3 = 54 of 90 resource-minutes. Preparation has 2 × 90 = 180 resource-minutes, giving a conditional capacity of 180 ÷ 6 = 30 tasks. Its twenty completions use 120 resource-minutes, sixty at each position. Checking’s capacity is 90 ÷ 2 = 45 attempts; its 22 successful attempts use 44 resource-minutes.

None of those processing stages uses all its available resource time in this fictional window. Preparation’s two unfinished items also arrived in the final minute, too late for their six-minute tasks. Their presence does not demonstrate an inability to keep pace with the period’s overall ready demand. Earlier unused time cannot process an item that has not arrived yet.

There were only fourteen newly ready arrivals to logging: eight complete new requests plus six clarified older ones. The workflow also completed work held at its opening. This explains why accepted completions can exceed new ready arrivals without implying extraordinary processing capacity.

The largest pile identifies an important readiness problem, but it does not prove which activity is a rate-limiting capacity constraint. Nor does the evidence prove generally weak demand: eighteen new requests arrived, and 26 incomplete ones remain. People may want kits while their requests remain unusable.

A useful next question is: “Which required detail is missing, and how long do requests wait between asking for it and receiving it?” That directs observation toward the condition preventing movement. Another observation may reveal an unclear question, a missed response, an agreed pause or something else. The present evidence supports investigating incomplete inputs; it does not justify declaring preparation slow.

Contents · Previous chapter · Next chapter

A bottleneck diagnosis should leave you able to say three things: what appears to limit the defined workflow, what evidence supports that explanation and what remains uncertain. Sometimes the honest result is that a capacity constraint has not been established. That can save time otherwise spent improving the wrong step.

In the main case, checking is a plausible candidate because the arithmetic, resource time, queue growth and readiness observations agree. In the independent case, a large incomplete-input holding area dominates the picture while processing positions retain unused time. Similar-looking unfinished work points toward different next questions.

Before testing a change, preserve the observation definitions. If you change the completion rule from “checked and correct” to “assembled,” the apparent improvement could come entirely from counting an earlier state. If you extend the working window, compare resource time as well as output. If you alter the pack mix, report it.

Do not present a conditional capacity calculation as a delivery commitment. Dividing available time by a task duration is useful for checking whether an explanation is plausible. Actual accepted completion also depends on ready inputs, timing, task variation, quality and downstream conditions.

Does the longest task always identify the bottleneck? No. A long task may have several independent resources, while a shorter task has one shared resource. Compare complete resource conditions and observations rather than task duration alone.

Does a growing queue prove the next station is too slow? It supports investigating that station, but a burst of arrivals, a scheduled closure, incomplete inputs or a blocked exit can produce accumulation. The queue’s readiness, age and movements matter.

Can accepted output rise without a faster process? Yes. A window may begin with more nearly completed work or contain an easier mix. Compare opening unfinished work, inputs, requirements and resources before attributing the difference to improvement.

What should we do when the counts disagree? Check definitions, duplicate items, exception routes and the observation boundary. Preserve the mismatch in the record until its cause is understood. A tidy but invented balance weakens every later decision.

When the evidence is sufficient for a small next step, use How to Test a Small Operational Change Before Scaling It. It covers predictions, measures, unwanted effects and a decision to continue, adapt or restore the previous approach. The operational rebuilding hub helps when the evidence points toward a different kind of repair.

This sits within Recovery and Transformation: protect useful capability, understand the obstacle and choose a change that can be checked. The practical result of this guide is a clearer process record and a better next question—one grounded in what the work actually did.

Contents · Previous chapter · Return to recovery and transformation