Why Busy Teams Finish Too Little—and How to Restore Flow
Contents
Part I — Find the work that is not finishing
Part II — Understand the mechanics of waiting
Part III — Repair the restriction without weakening the work
Part IV — Keep the repair coherent across the whole project
- Buying capacity means buying capability at a particular time
- A critical path is not the same as a capacity bottleneck
- A faster handoff is useless when it carries the wrong version
- When AI makes drafts cheap, verification can become the constraint
- A portfolio can have more than one binding constraint
Part V — Make the improvement worth having
- Throughput is an instrument, not the purpose of the institution
- Read the tail, the mix and the unfinished work
- Test an intervention without pretending a before-and-after chart proves causality
- A ten-working-day diagnostic that does not promise a ten-day cure
- An improvement can cost more effort and still be worthwhile
Part VI — Practise the diagnosis and make it durable
Twenty pieces of work had started. Five had reached the people who needed them. At the meeting, everybody could explain the difference except the dashboard.
This is a guide to finding what actually limits a project’s useful completions, rather than asking every team to move faster. It follows an invented delivery team, works through the mathematics of capacity and waiting, and returns to the decisions a manager, teacher, specialist or small-business owner can make without buying a new management system.
Project bottleneck management means identifying a capacity restriction that limits the flow of accepted work, establishing why it exists, and changing the surrounding work system so more useful work can finish without weakening necessary standards. A missing permission or an unresolved requirement may stop work too, but not every blockage is a capacity bottleneck. The distinction determines the repair.
The continuing case is fictional. Farah coordinates a learning-service rollout; Tomas builds its technical components; Leena reviews release evidence; Nia receives the service into operations; Elliot sponsors the project. They are not real eduKate staff or pupils, and the case does not report an actual organisational result. All numerical examples are invented teaching models. Their assumptions are stated where they are used. Published theory is attributed through numbered source notes; the proposed operating practices and worked deductions are this article’s own explanatory treatment.
The question running through the article is deliberately narrow: what change would allow the next worthwhile completion to happen sooner, with its meaning intact? That question will take us through queues, handoffs, judgement, authority, learning and the promises organisations make to one another.
Part I — Find the work that is not finishing
1. Five finished, twenty started
Farah arrived with a plan for twenty-four release bundles. Each bundle represented a small, usable part of the new learning service: a configured workflow, the supporting instructions, the evidence that it behaved as intended, and a receiving owner who could run it. The bundles were not interchangeable in every detail, but the team had deliberately made them comparable enough to discuss their progress together.
By Friday, twenty bundles had entered active work. Five had been accepted into operation. Fifteen remained inside the delivery system; four more had not started. The distinction mattered, although the first slide concealed it. A long band of green showed that most development tasks had begun. A smaller number near the bottom recorded operational acceptance. Nobody was falsifying a number. The presentation was simply celebrating an event that was much easier to produce than the event the organisation needed.
Tomas could show working screens. Leena could show review requests arriving faster than she could resolve them. Nia could show two bundles that had passed technical review but still needed a usable support arrangement. Farah could show a team working conscientiously across all of them. Elliot could show the original commitment. Each account described something real. Together, they did not yet explain how the project would finish.
The first proposed remedy was another developer. It sounded reasonable because development was the visible work, and the service still needed features. Tomas did not reject the idea. He asked a different question: which of the fifteen unfinished bundles would the additional developer help the organisation accept next week? For several items the answer was clear. For the bundles waiting on evidence or operational preparation, it was not.
That question changed the meeting. Instead of asking which team looked busiest, Farah asked which item was nearest to a legitimate finish and what prevented it from crossing that boundary. One bundle needed a corrected source field. Another needed the reviewer to distinguish an actual defect from a misunderstanding of the requirement. A third needed the operational owner to demonstrate a recovery procedure. These were three different reasons for waiting. Hiring one kind of person would not necessarily address all three.
A bottleneck is often described as a narrow point in a workflow where insufficient capacity causes work to accumulate. That description appears in contemporary project-management guidance, including Atlassian’s overview. It is a useful first picture, but the picture does not identify the restriction for you. A pile of work is evidence to investigate, not a verdict against the team beside it. [1]
Leena’s queue was the largest visible pile. That made review a sensible candidate for investigation. It did not prove that Leena was the system’s permanent constraint. Some requests were incomplete and could not legitimately be reviewed. Some had already been answered but the authors had not responded. Some were waiting for a decision that Leena did not have authority to make. Counting them all as review demand would combine work she could perform, work she could not yet perform, and work that belonged elsewhere.
Farah left the meeting with a smaller ambition than a transformation programme. For the next few working days, the team would follow the unfinished bundles and record their actual state. They would not change acceptance standards, stop necessary support or add reporting to every minute. They would identify the missing condition behind each significant wait. That investigation could be done before the organisation decided what capacity to buy.
This is the first discipline of bottleneck management: resist the pressure to turn an incomplete explanation into a staffing decision. A queue can make the problem visible while still hiding its cause. The person standing next to it may be the constraint, the witness to the constraint, or the person who has been preventing an upstream defect from reaching the public. Those possibilities deserve different responses.
2. Decide what counts as a useful finish
Before measuring flow, the team needed to agree what was flowing. A task, a document, a customer request and a usable release bundle were not equivalent units. Counting all four together would give Farah an impressive number with no stable meaning. A developer could divide one task into ten; a reviewer could combine five findings into one; the dashboard would change even if the organisation received exactly the same capability.
For the rollout, the chosen unit was an accepted release bundle. Its finish meant that the intended function worked, the relevant checks were complete, its operating information matched the delivered version, and Nia had accepted responsibility for the defined operational use. This did not mean every future problem had been ruled out. It meant the bundle had met an explicit, bounded set of conditions that allowed the receiving organisation to use it.
The unit could have been different in another project. A construction team might count inspected installation sections. A research team might count completed experiments with interpretable records, rather than positive findings. A school event team might count stations that were staffed, supplied and ready to operate. The appropriate unit depends on the objective. It should not be selected merely because a software tool already has a convenient column for it.
The current Kanban Guide distinguishes work started but not finished, the count of finished items per time interval, the age of unfinished work, and elapsed time for completed work. It also requires the workflow’s start and finish points to be defined. Those definitions are important here because a flow measure inherits the meaning of the boundary you choose. [2]
A narrow finish boundary may be useful without being the final organisational finish. Tomas needed to know how many components development completed. Leena needed to know how many reviews reached a decision. Nia needed to know how many bundles operations could absorb. The mistake would be to let one local completion stand in for all the others. The team needed several views, with each labelled accurately, rather than one supposedly universal productivity number.
Farah therefore kept a distinction between local output and accepted system output. A completed configuration was a local output. An accepted bundle was the system output for this project. A functioning service used well by its intended users was a further outcome. The project could measure the first two through delivery records; the third required observation after delivery. More accepted bundles did not automatically prove better learning, easier administration or a worthwhile service.
This distinction protects the reader from a seductive version of efficiency. A team might improve throughput by accepting smaller and less useful items. It might avoid difficult cases. It might remove necessary checks. It might call an installation complete before anyone can operate it. All four actions could improve a count while damaging the purpose the count was meant to represent. A sound finish definition makes that trade visible rather than impossible to detect.
The five accepted bundles in Farah’s first Friday report were therefore not merely five things moved to the right of a board. Each had a receiving condition and a record. The fifteen unfinished bundles were not fifteen failures. They were fifteen commitments occupying the system without yet providing the defined finished output. The distinction allowed the team to examine delay without declaring unfinished work worthless or blaming the people responsible for it.
A useful test is to complete this sentence: “When we say one item is finished, the receiver can now do ___ without relying on an unresolved project promise.” The blank should identify a real capability, not a paperwork event. For some projects, acceptance itself is the necessary output; for others, operational use is the more meaningful boundary. Make the choice openly, retain the evidence, and do not move it halfway through an improvement exercise to make the results look stronger.
Once the finish was clear, Farah could ask whether a proposed acceleration preserved it. Removing duplicate formatting work might. Removing the test that established the bundle’s required behaviour would not. The question was no longer whether a step made delivery slower. Many necessary steps do. It was whether the step produced evidence, capability or authority that the chosen finish genuinely required.
3. Follow one item instead of interviewing the dashboard
The team began with a single bundle that had spent nine working days in the system. Its task records suggested steady progress. A closer chronology showed something else: two days of configuration, a day waiting for a clarification, half a day of correction, three days waiting for a review slot, a short review, and another wait while an operating instruction was reconciled with the latest build. The bundle’s elapsed journey was much longer than the direct work performed on it.
This did not establish a universal ratio between working and waiting. It established a fact about one invented case. That was enough to suggest what to examine next. Farah sampled bundles of different ages and types, including ones that had finished smoothly. Studying only the oldest problem would risk building the whole explanation around an exceptional case. Studying only successful completions would hide the work that never reached the sample.
For each item, she asked when the receiving team first had a usable input. A review request sent on Monday was not necessarily ready for review on Monday. An inaccessible attachment, an absent requirement or a changed version could make the nominal handoff earlier than the real handoff. Conversely, a receiver could leave a complete request unacknowledged for days. The project needed to distinguish those conditions without allowing either side to manipulate the clock.
A compact event record was enough: item identity, event time, state entered, reason for any significant block, responsible next actor, and the evidence needed to leave the state. It was not a diary of every keystroke. The purpose was to reconstruct the path through the system, including the intervals that ordinary task completion records omitted. The record belonged to the item, not to a judgement about how hard a person worked.
At the first snapshot, the fifteen active bundles were distributed as follows. Three were still in preparation, four in configuration, five in verification or awaiting it, one in deployment preparation, and two awaiting operational acceptance. The total matched the ledger: twenty started minus five accepted. The four unstarted bundles remained visible separately. This small reconciliation prevented a dashboard category from quietly swallowing unfinished work.
| Location inside the defined workflow | Active bundles at the snapshot |
|---|---|
| Preparation | 3 |
| Configuration | 4 |
| Verification and its waiting queue | 5 |
| Deployment preparation | 1 |
| Operational acceptance | 2 |
| Total started but not accepted | 15 |
The next question was not which column was largest but what was happening inside each column. Of the five verification items, one lacked a complete evidence packet, another awaited a sponsor decision, and three were ready for Leena’s work. These observations changed the capacity calculation. Five cards in a column did not mean five ready jobs were competing for the same service. A workflow board that hides these distinctions can make the wrong team appear overloaded.
The team also recorded the state of the receiver. Was Leena serving a ready item, correcting someone else’s input, attending an unrelated meeting, or waiting for information? Was Nia unable to accept a bundle because operations lacked time, because the handover was incomplete, or because the bundle’s purpose remained disputed? These were different mechanisms. A useful map made them explicit without requiring a new department for each category.
Following one item has another advantage: it exposes work that leaves the formal board. A request may continue through private messages, telephone calls, personal notebooks or a supplier’s system. The project does not need to centralise every conversation. It does need the consequential result to return to an authoritative record. Otherwise the next person repeats the enquiry, and time is consumed reconstructing decisions that somebody already made.
By the end of the exercise, Farah had not produced a perfect map. She had produced a map that could be challenged. Tomas could point to a handoff that was missing; Nia could correct an acceptance condition; Leena could show that a queue entry was not ready. That was more useful than a beautiful diagram nobody could dispute because it contained too little operational detail to be wrong.
4. Four different reasons that work stops
A useful diagnosis separates a capacity restriction from other reasons that work cannot move. Consider four bundles. The first has a complete evidence packet but no reviewer available until Thursday. The second cannot be reviewed because its required behaviour is ambiguous. The third has passed its checks but lacks an authorised release decision. The fourth can be delivered, but the intended receiver no longer needs it. All four are waiting. They are not waiting for the same thing.
The first is a plausible capacity problem: ready demand exceeds available review service during the relevant period. The second is a knowledge or definition problem. The third concerns authority. The fourth concerns demand or continuing value. Hiring another reviewer may help the first. It cannot legitimately invent the second bundle’s requirement, grant the third bundle’s permission, or create a reason for the fourth bundle to exist.
In practice the categories can interact. Ambiguous requirements create repeated review work and consume capacity. Slow decisions create bursts when approvals finally arrive together. Unwanted work can occupy the same specialists needed for essential work. The categories are not separate worlds; they are a way to avoid applying the same remedy to every kind of delay. Diagnose the immediate block, then trace how it affects the wider system.
It is also important to distinguish a bottleneck from a protective control. A required inspection restricts flow by design. That does not make it an organisational defect. The defect may be insufficient inspection capacity, poor preparation, unclear criteria or unnecessary duplication around the inspection. A proposal to remove it should be evaluated against the purpose it serves and the authority governing it, not justified solely by the fact that a queue exists nearby.
Leena made this point when a colleague suggested that straightforward bundles should bypass review. Some might qualify for an approved, lighter assurance route, but no such route had yet been defined. Calling them straightforward was not evidence of eligibility. The team could propose a proportionate classification system, obtain the necessary agreement and test it. Until then, the existing requirement remained part of the finish definition.
A second distinction concerns dependency and capacity. Suppose a specialist is free all afternoon but the current drawing is missing. The blocked work is not evidence that the project needs another specialist. Suppose the drawing arrives and ten jobs now compete for that afternoon. Capacity may become the controlling issue. The same item can change blockage type over time, which is why a static label such as “resource problem” can become misleading.
The project’s Dependency Management guide provides the neighbouring question: what usable input must arrive, from whom, and by when? Its Decision Management guide addresses the authority needed to choose. This article does not replace those subjects. It asks what happens to flow when ready work repeatedly competes for limited capability, and how to prevent those relationships from creating avoidable waiting.
A practical diagnostic conversation therefore begins with the next necessary event. “Waiting for Leena” is insufficient. “Ready for a two-hour evidence review, competing with six other ready requests, with Leena having four review hours available this week” describes a capacity mechanism. “Waiting for an agreed privacy boundary before the evidence can be assessed” describes something different. Both deserve attention, but they should not be added together as if they were the same service queue.
The distinction can protect people as well as schedules. Without it, the person who refuses to approve incomplete work can become the organisation’s supposed obstacle. With it, the team can see which preparation belongs upstream, which judgement belongs to the reviewer, and which decision belongs to the sponsor. Bottleneck management then becomes an investigation of the operating arrangement rather than a search for a person to pressure.
5. Ask what would change if the suspected bottleneck disappeared
Farah’s next step was a counterfactual. Suppose Leena could complete every ready review today. What would happen tomorrow? The answer was not “the project would finish.” Deployment still had a limited window. Nia still needed to prepare operations. Some bundles still lacked approved instructions. Extra review capacity could improve flow, but the gain depended on what the downstream system could use.
This is the difference between a local obstacle and a system-limiting restriction. A local obstacle delays particular work. A system bottleneck limits the relevant rate of completion under a specified demand mix, resource arrangement and time horizon. The label should identify the system and the horizon. A team can be constrained by verification this week and by operational absorption next month without either observation being dishonest.
The Theory of Constraints Institute describes a five-step focusing process: identify the constraint, improve its use, align the surrounding system with it, expand capacity where needed, and reassess when the constraint changes. The traditional terms include “exploit” and “subordinate”; here they concern the work system, not exploiting people. The method offers a disciplined order for investigation. It is not evidence that every project has exactly one permanent bottleneck or that every improvement will yield a particular percentage gain. [3]
For Farah, the practical value of that sequence was restraint. The team could first recover review time consumed by incomplete submissions. It could arrange ready work so the reviewer was not repeatedly interrupted. It could compare downstream capacity with the expected review output. Only then would it know more about the benefit of purchasing additional review hours. None of these actions required pretending the reviewer could work indefinitely at maximum intensity.
The counterfactual also prevented an easy reporting victory. Suppose a developer moved six items into review by Friday. Development output rose, but the accepted-output rate remained unchanged. If the additional items had no urgent purpose and only increased the queue, the local acceleration had created inventory rather than immediate organisational value. That does not mean development work is unimportant. It means the value of doing it now depends on the receiving system.
A sound constraint hypothesis has three parts. It names the suspected restriction, states the evidence supporting it, and predicts what should change if the restriction is relieved. For example: complete review-ready bundles are accumulating; Leena’s usable review time is fully allocated; recovering a defined amount of that time should increase accepted reviews, unless another constraint becomes active. The prediction makes the diagnosis testable rather than merely persuasive.
It should also name competing explanations. Perhaps arrivals were unusually high for two weeks and the queue will settle. Perhaps the work mix became harder. Perhaps approval batching, rather than review effort, controls elapsed time. Perhaps the reviewer is available but the records make that availability invisible. These possibilities matter because a one-off snapshot can make different systems look similar. A diagnosis earns confidence by surviving attempts to find a better explanation.
Farah did not need perfect statistics to begin. She needed enough observation to distinguish ready from blocked work, compare demand with usable capacity, and choose a small intervention whose result would be visible. She could record uncertainties instead of resolving every one before acting. A reversible change to preparation might be reasonable under moderate confidence; a costly staffing commitment deserved more evidence about the recurring workload.
This approach changes the manager’s role. Instead of commanding every part of the project to accelerate, the manager asks where an hour of improvement can alter the next useful completion. Sometimes the answer is a reviewer. Sometimes it is a decision, a clearer input, a smaller transfer batch or a receiver who needs preparation. The work of management is to locate that leverage without turning an attractive theory into an excuse to ignore the actual project.
Part II — Understand the mechanics of waiting
6. A capacity limit is not a promise of output
To reason about the rollout, Farah sketched a deliberately simplified rate model. Suppose preparation could supply twelve usable bundles per week, configuration ten, verification six, deployment eight, and operational acceptance five. These were illustrative planning capacities for a stated work mix, not universal productivity rates. Routine returns were assumed already reflected in them. Every bundle had to pass through every stage, and there was no alternative route around operational acceptance.
Under those assumptions, sustained accepted output could not exceed five bundles per week. Even an infinitely fast preparation team would not allow operations to accept more than five. The relevant upper bound was the smallest effective capacity along the required serial route. This was an upper bound, not a guarantee: poor timing, missing inputs, absence, incompatible versions or an empty upstream queue could make actual output lower.
| Stage in the illustrative recurring pipeline | Usable capacity per week |
|---|---|
| Preparation | 12 bundles |
| Configuration | 10 bundles |
| Verification | 6 bundles |
| Deployment | 8 bundles |
| Operational acceptance | 5 bundles |
The word “effective” carries much of the meaning. A reviewer who has thirty calendar hours allocated may not have thirty hours available for direct review. Support incidents, required meetings and other assignments consume real capacity. A machine’s rated capacity may assume uninterrupted supply and a different product mix. A team’s advertised capacity may ignore rework. Before comparing rates, the project must establish that the units, quality conditions and available working time are genuinely comparable.
There is also a distinction between capacity and observed throughput. If only three ready bundles reach operations this week, Nia may accept three even though she could have accepted five. That observation does not prove an operational capacity of three. The station may be starved of usable input. Conversely, accepting seven during an exceptional week might reflect overtime or previously completed preparation, not a sustainable new rate of seven. A single week’s output needs context.
The model helped explain why the largest queue did not automatically identify the final constraint. Verification might contain the most cards because upstream work arrived in a burst. Yet operational acceptance could still impose the lower sustained rate. Increasing verification capacity could improve particular completion dates and reduce an upstream wait, but it might eventually move the accumulation into operations. The gain depended on the time horizon and the distribution of work already inside the system.
Suppose operations could be increased from five to seven accepted bundles a week, with all other assumptions unchanged. The new upper bound would be six, imposed by verification. Two units of additional operational capacity would not yield two extra system completions per week because the next restriction would intervene. Increasing operational capacity to six might be enough for the current objective; increasing it further could still have resilience value, but that is a separate justification.
Now suppose verification and operations are performed partly by the same specialist. The simple minimum-of-stage-rates model may become invalid because the capacities are not independent. The same hours cannot be counted twice. The project would need a resource model showing how each bundle consumes shared time. This is a common place for optimistic capacity arithmetic: every team reports its own feasible rate, but each rate assumes access to the same person.
The serial-rate model also says little about a unique project’s finish date. A finite project starts with some stages empty and ends with the pipeline draining. A single long approval can dominate completion even if that approval is not the recurring capacity bottleneck. Rates illuminate repeated flow; a dependency network illuminates the sequence of a particular project. Both views may be necessary. Neither should be stretched into a universal description of all delivery work.
For a manager, the useful output of the capacity exercise is therefore not one mystical bottleneck label. It is a set of conditions: the defined work mix, the necessary route, the available capacities, the shared resources, and the evidence behind each estimate. Under those conditions, this restriction appears to limit useful output. When the conditions change, the conclusion must be reconsidered. That is disciplined modelling rather than indecision.
Farah kept the table as a conversation aid. Beside each rate, she added how it had been estimated and what could invalidate it. The table became less impressive as a forecast and more useful as a management tool. It showed which belief the team should test before promising that another hire, another tool or another round of acceleration would change what the organisation could actually receive.
7. Unfinished work obeys a simple accounting identity
There is an elementary calculation that many project dashboards avoid. Start with the number of items already inside the defined workflow. Add new admissions. Subtract legitimate departures. What remains is the work still inside. A status colour cannot alter that arithmetic.
For an interval with no cancellation or scope transfer, the identity is:
Ending unfinished work = beginning unfinished work + newly admitted work − accepted completions.
The formula is not a forecasting model. It is a reconciliation. If a team starts with twenty active items, admits eight and accepts five, it ends with twenty-three. When a board reports nineteen, the project should investigate the difference. Perhaps four items were cancelled legitimately. Perhaps they were moved to a different workflow. Perhaps a filter excludes blocked work. Perhaps the data is wrong. The discrepancy deserves an explanation, not automatic suspicion of wrongdoing.
Consider a separate, recurring-work illustration. The system begins with twenty active items. It admits eight every week and accepts five every week. There is no cancellation, splitting or merging, and the unit definition stays unchanged. After four weeks, unfinished work has risen to thirty-two. Every team may be performing at its stated rate. The system still accumulates three items per week because admissions exceed completions.
| Week end | Beginning active work | Admissions | Accepted completions | Ending active work |
|---|---|---|---|---|
| 1 | 20 | 8 | 5 | 23 |
| 2 | 23 | 8 | 5 | 26 |
| 3 | 26 | 8 | 5 | 29 |
| 4 | 29 | 8 | 5 | 32 |
This is why starting more work can make an organisation feel productive while making its delivery position worse. The starts are real. They may consume effort, create partial assets and provide some information. But under the stated conditions they do not increase accepted output. They increase the amount of unfinished commitment the organisation must coordinate, remember and eventually complete or consciously abandon.
Now reduce admissions to four per week while completions remain five. The existing stock declines by one per week. That is an arithmetic result under an explicit assumption about completions. It does not guarantee that reducing admissions will preserve throughput in the real system. A limit set too low could starve a specialist or prevent useful parallel preparation. The project must observe what happens rather than treat the admission rule as a law of nature.
Nor does the admission limit make incoming demand disappear. If customers continue requesting eight items a week and only four enter active work, another four wait outside the chosen workflow. The active-work dashboard may improve while the customer’s total wait worsens. The honest system shows both queues: requests awaiting admission and commitments already underway. Otherwise a team can improve its cycle-time metric simply by moving the starting line later.
Cancellations need the same honesty. Suppose three active items are deliberately withdrawn because their value no longer justifies the work. The active stock falls by three, but the organisation has not completed three useful deliverables. Report accepted completions and withdrawals separately. Withdrawal may be an excellent management decision; disguising it as throughput makes the improvement impossible to interpret.
Splitting work introduces another accounting problem. One large item becomes four smaller ones. The item count rises without an equivalent increase in scope. The four pieces may genuinely improve flow, but the measurement history needs a parent-child relationship or a revised unit convention. Otherwise comparisons before and after splitting mix different denominators. A manager can end up congratulating the team for producing four times as many things when it has simply changed how things are counted.
Farah used this identity to examine her own first-Friday report. Twenty bundles had started, five had been accepted, and fifteen remained. The four unstarted bundles belonged to the commissioned set of twenty-four but not to active work. That distinction protected two truths at once: the project had not forgotten the unstarted commitment, and it had not pretended that every authorised idea was already consuming the same kind of delivery capacity.
This small piece of arithmetic is often enough to clarify the strategic choice. When demand persistently exceeds completion capacity, the organisation must eventually expand effective capacity, reduce demand, change scope, change timing or accept a growing queue. Better communication may help implement those choices. It cannot make the imbalance vanish. Naming the alternatives early is more responsible than allowing the waiting list to become the organisation’s unspoken decision.
8. Little’s Law explains a relationship, not a shortcut
John D. C. Little’s 1961 paper established a formal relationship among the average number of units in a queueing system, the average arrival rate and average time in the system, under stated mathematical conditions. In operational language, the familiar relationship is average work in progress = average throughput × average flow time, when the measurement boundary and the conditions for using those averages are appropriate. It is an average relationship, not a deadline guarantee for an individual item. [4]
Suppose a suitably stable workflow averages twenty active items and completes five comparable items per week. The relationship gives an average flow time of four weeks. If the same system could sustain five completions per week with an average of ten active items, the corresponding average would be two weeks. The calculation is simple. Establishing that the second operating condition is feasible is the managerial work.
The phrase “could sustain” must not be omitted. A manager cannot cut the board limit in half and conclude that every item will finish twice as quickly. The change might remove excess queueing. It might also deprive a specialist of ready work, alter the work mix or expose a dependency that had been hidden by abundant inventory. The relationship describes compatible averages; it does not specify the intervention that produces them.
A snapshot also cannot be substituted casually for an average. Farah’s fifteen unfinished bundles on one Friday did not establish a long-run average inventory of fifteen. The project might be filling its pipeline, draining it, or experiencing an unusual burst. Dividing that one observation by last week’s five completions could be a rough conversational indicator, but it would not be a defensible application of the average law without further examination.
There is a useful finite-work intuition that avoids pretending a one-off project is stationary. Imagine watching a defined workflow from empty to empty, including every item that enters it. At any moment, count the items still inside. Add up that count across time: the result is an area measured in item-days. Alternatively, take each item’s time inside and add those times. You obtain the same area because each item contributes one unit for every day it remains inside.
For a concrete example used again in the batch chapter, six items start active processing on Days 0, 2, 4, 6, 8 and 10. They finish on Days 6, 9, 12, 15, 18 and 21. Their active flow times are therefore 6, 7, 8, 9, 10 and 11 days. The sum is 51 item-days, and the mean is 8.5 days. Observed across the full twenty-one-day window, average active inventory is 51/21, and throughput is 6/21 per day. Multiplying 8.5 by 6/21 gives exactly 51/21.
This finite identity is a transparent accounting exercise for that complete observation window. It is not permission to ignore unfinished items at a reporting cutoff. When a month ends with many items still active, their total eventual flow times are not yet known. Averaging only completed items can hide the oldest work, particularly when easy tasks finish first. The project should retain the age of unfinished work rather than assuming the completed sample represents everything.
The boundary can change the answer without changing reality. In the six-item example, suppose all six were requested and approved on Day 0. From the requester’s perspective, their total waiting times to delivery are 6, 9, 12, 15, 18 and 21 days: an average of 13.5 days. From active processing start, the mean is 8.5. Both are correct for their boundaries. Neither should be presented as the other.
For practical reporting, this suggests a paired view. Show the time from request to usable delivery when that matters to the receiver. Also show the time inside the actively managed delivery workflow. If the second improves while the first worsens, the project may have shifted waiting upstream. That can still be part of a sensible admission strategy, but it is not an unqualified customer improvement.
The existing Queueing Theory and Waiting Lines article owns the broader mathematical subject. Here the law’s purpose is narrower: make a team examine the relationship among unfinished commitments, useful completions and elapsed time. It helps reveal when a story about faster delivery is incompatible with the stock of work the organisation continues to admit. Its strongest use is as a disciplined question, not a numerical slogan.
9. Two teams can have the same utilisation and different waiting
Capacity and demand averages are necessary, but they do not tell the whole story. Timing matters. To see why, consider a deliberately simple twelve-hour service window. One reviewer needs exactly one hour per job. Six complete jobs must be reviewed. There are no breaks, failures, interruptions or priority changes in this teaching model, and the reviewer begins work whenever a job is ready.
In Arrangement A, the six jobs arrive at Hours 0, 2, 4, 6, 8 and 10. Each begins immediately and takes one hour. There is no queueing wait. The final job finishes at Hour 11. Across the twelve-hour observation window, the reviewer performs six hours of work and is occupied half the time. Each job spends one hour in the review system.
In Arrangement B, all six jobs arrive at Hour 0. They finish at Hours 1, 2, 3, 4, 5 and 6. Their waiting times before service are 0, 1, 2, 3, 4 and 5 hours. Mean waiting is 2.5 hours, and mean time including service is 3.5 hours. Across the same twelve-hour window, the reviewer again performs six hours of work and is occupied half the time.
The utilisation and total volume are identical. The waiting is not. The difference comes entirely from the arrival pattern. This is an exact result of the constructed schedules, not an empirical claim about a typical team. It demonstrates why “we are only at fifty percent utilisation” does not prove that nobody should be waiting. Averages can hide bursts, and a burst can be created by policy rather than by unpredictable customer behaviour.
For Farah’s team, weekly preparation reviews created such a burst. Several bundles were released to Leena together late on Thursday. The following Monday, the queue looked alarming. A proposal to redistribute some complete submissions across the week might reduce waiting without changing Leena’s total available hours. It would not be useful to distribute incomplete requests merely to make arrivals look smooth. Usable input, not early notification, is what consumes the service.
Variability in work duration creates another pattern. Suppose a supposedly one-hour queue contains a six-hour investigation. The work behind it waits longer, although the average over a month may still look acceptable. The project should not solve this by treating every long case as waste. Some long cases are necessary. It may instead need a visible route for investigations, realistic estimates, or capacity protection so a difficult item does not unexpectedly consume a slot promised to several routine ones.
Spare capacity can provide recovery room, but it is not free or unlimited. In the evenly spaced example, the reviewer has intervals that can absorb some late arrival or longer service without delaying every later job. If appointments are scheduled back-to-back for the entire window, the same overrun has nowhere to go unless some later work is shorter, delayed or moved. This is a simple consequence of the schedule. It does not imply one universally correct utilisation target for all work.
The correct allowance depends on variability, consequence, alternative capacity and the promises the organisation makes. A predictable machine process, a specialist investigation and an emergency response service should not inherit the same percentage merely because a management article recommends it. The project should examine its observed interruptions and work mix, then decide how much recovery room the relevant service commitment requires.
There is also a social cost to hiding this room. When every unallocated interval is interpreted as poor performance, people may fill it with new commitments. The system then loses its ability to respond when an important exception appears. In a project with uncertain work, a manager should be able to explain what reserved capacity protects. “Unused” and “useless” are not equivalent descriptions.
Farah’s revised question was therefore more precise than “How busy is Leena?” She asked how complete work arrived, how long different reviews actually required, which interruptions were unavoidable, and what capacity remained for exceptions. These observations could distinguish an insufficient overall service rate from avoidable timing friction. Both might need repair. They should not be confused simply because both produce a queue.
10. Six items, two transfer policies, fifteen days of difference
Batching can create delay even when nobody performs more direct work. Consider six identical teaching packages moving through three stages. Preparation takes two working days per package. Review takes three. Release takes one. Each stage has one dedicated worker, a worker handles one package at a time, all six are available at Day 0, and there are no errors, setup costs, holidays or external approvals. The example is intentionally small enough to calculate exactly.
Under a full-batch transfer policy, preparation completes all six packages before handing any to review. Preparation therefore occupies Days 0–12. Review then processes all six during Days 12–30. Only when all reviews are complete does release begin. Releases occupy Days 30–36. The first usable package appears on Day 31, and the last on Day 36.
Under an item-by-item transfer policy, each prepared package goes to review as soon as both the package and reviewer are available. Each reviewed package goes to release on the same basis. No stage becomes faster at its own work. The change is that later stages can begin before earlier stages finish the entire batch.
| Package | Preparation interval | Review interval | Release interval | Finished |
|---|---|---|---|---|
| A | 0–2 | 2–5 | 5–6 | Day 6 |
| B | 2–4 | 5–8 | 8–9 | Day 9 |
| C | 4–6 | 8–11 | 11–12 | Day 12 |
| D | 6–8 | 11–14 | 14–15 | Day 15 |
| E | 8–10 | 14–17 | 17–18 | Day 18 |
| F | 10–12 | 17–20 | 20–21 | Day 21 |
The last completion moves from Day 36 to Day 21. The first moves from Day 31 to Day 6. Total direct labour remains thirty-six worker-days: twelve in preparation, eighteen in review and six in release. Elapsed duration falls because work overlaps across stages. There is no claim that people became more productive per hour or that the required review was shortened.
The first package needs six days to traverse all stages. After that, the three-day review stage sets the rhythm in this particular pipeline. The finish time is therefore 6 + 5 × 3 = 21 days. This compact calculation depends on the stated identical-job assumptions and the absence of additional constraints. It is a result for the model, not a general formula for every project with three teams.
DORA’s guidance on small batches emphasises dividing work into smaller increments so feedback and delivery can occur earlier rather than waiting for a large collection to finish. Its context is software delivery. The table above is an original, simplified calculation that isolates the transfer-policy mechanism; it does not borrow an empirical performance claim from that guidance. [6]
The qualification about setup cost matters. Suppose each separate review delivery requires an hour of secure preparation, or each release requires a costly equipment reset. Very small transfer batches may add overhead. The right question is not whether batching is always bad. It is which batch size balances setup, waiting, feedback, coordination and risk for the actual work. A large production batch and a small transfer batch can sometimes coexist: prepare related work together but release finished portions sooner.
Independence matters too. Six chapters that must agree on one argument are not six unrelated products. Six interfaces sharing a common contract may need joint verification. The team should split where each piece can be meaningfully received, not where a board can most easily display more completions. Smaller packages that cannot be used or checked independently may create an illusion of flow while postponing the same integration burden.
The model also tests staffing proposals. Halving preparation time from two days to one, while review still takes three and release one, moves the first completion to Day 5 and the last to Day 20. That is only a one-day reduction in total finish time. Adding a second equally capable reviewer, while preparation stays at two days, can reduce the last completion to Day 16 under the model’s assumptions. The interventions affect different parts of the pipeline, so equal enthusiasm does not imply equal benefit.
Farah did not copy these numbers into her rollout plan. Her bundles differed, reviewers had other work, and operational acceptance added another stage. She copied the question: are we waiting for a whole collection when the receiver could legitimately begin with a coherent part? The resulting change was modest. Complete evidence packets could move individually; shared requirements still received joint treatment. The purpose was not a doctrine of tiny batches. It was to stop a convenient administrative habit from deciding when useful feedback could begin.
Part III — Repair the restriction without weakening the work
11. Rework is demand that arrives again
Leena’s calendar showed six review slots. Her queue did not behave like six new bundles a week. Some bundles returned. A corrected item consumed another slot; a misunderstood finding generated another discussion; a late version change reopened evidence already examined. The project had been measuring the number of new submissions while the reviewer was serving both new submissions and returning work.
That distinction is essential. A resource is loaded by the work it actually has to perform, not only by the number of original requests. Ten new items with frequent returns can create more service demand than twelve well-prepared items. Counting only arrivals at the project’s outer boundary can therefore understate demand at an internal specialist. Counting every return as a new completed deliverable creates the opposite distortion: activity appears to multiply while useful output does not.
Consider an isolated teaching model with six full review attempts available per week. Every attempt takes the same time. An attempt succeeds with probability 0.75; an unsuccessful item returns for another attempt under the same conditions. Assume independent attempts, no abandonment, and eventual completion. The expected number of attempts per accepted item is 1 + 0.25 + 0.25² + … = 1/(1 − 0.25) = 4/3. Six attempts therefore support an average of 4.5 accepted items per week in the simplified long-run calculation.
The number 4.5 is an average rate, not a claim that half an item can be accepted in an actual week. Nor is the model a description of Leena’s real reviews. It isolates a mechanism: repeated visits consume capacity. If an upstream improvement reduced the return probability to 0.10 while all other assumptions held, expected attempts would become 1/0.90 and the capacity equivalent would become 5.4 accepted items per week. No review criterion has been weakened in that comparison.
Actual rework is rarely so uniform. A return may need a twenty-minute check rather than another full review. A difficult item may be more likely to return again than a straightforward one. Some findings require a different specialist. The project should therefore model the actual kinds of return when the decision is important, rather than applying the geometric formula indiscriminately. A simple average-time model can sometimes be more useful.
For example, suppose each new item requires five hours of initial review, one quarter require exactly one additional two-hour check, and all items are accepted after that check. Expected review work is 5 + 0.25 × 2 = 5.5 hours per accepted item. Thirty available review hours provide a workload-based capacity of 30/5.5, approximately 5.45 items per week. This is a different model from repeated full reviews. The assumptions, not the impressive decimal, explain what the result means.
Rework also creates timing effects beyond the specialist hours. The author must revisit the item, understand the finding and reconstruct the context. A dependent task may already have begun from the old version. The returning item then competes with new work, often with a claim of urgency because its promised date is now close. The queue becomes harder to prioritise. A seemingly small defect can therefore consume capacity and disturb sequence at the same time.
The sensible upstream repair is not to demand “better quality” in general. Identify the return categories. Are sources missing? Are requirements inconsistent? Are test records attached to the wrong version? Are the same formatting defects repeatedly reaching an expensive specialist? A preparation improvement should target a repeatable cause, with evidence that the cause actually consumes constrained capacity. Otherwise the team can add a checklist that creates new work without reducing returns.
There is a necessary boundary here. Some review findings are valuable discoveries, not preventable mistakes. A genuinely difficult question may require expert judgement that the author cannot safely perform alone. The goal is not a zero-return target that discourages challenge. It is to prevent avoidable work from repeatedly consuming the capability needed for difficult work. The project should distinguish correction of a preventable defect from legitimate learning that changes the solution.
Farah’s team began recording the reason for each significant return, not a blame score against the person who submitted it. Within the fictional case, several returns came from an unstable interface description used by more than one writer. Correcting the shared description was more promising than telling five people to be more careful. The bottleneck investigation had travelled upstream to the information that shaped the work arriving at the reviewer.
12. Protect scarce judgement from work that does not require it
One tempting response to a scarce expert is to ask that expert to work longer. A more revealing first question is what currently occupies the expert’s time. The answer may include valuable judgement, necessary coordination, avoidable administration and work that could be prepared elsewhere. Those categories should be separated before the project decides that the expert’s only remaining capacity lies in evenings and weekends.
In an illustrative week, a reviewer has thirty hours available to the project. Six are spent locating documents, reconciling file names and asking for missing attachments. Twenty-four remain for the review work itself. Using the separate five-and-a-half-hour model from the previous chapter, the workload-based rate is about 4.36 accepted items. Recovering those six hours could raise the rate to about 5.45, before considering downstream limits or variability. These are calculated possibilities, not promised improvements.
The recovery action is not to delegate the review decision to someone unqualified. It is to prepare the material so the qualified person can spend more of the available time on judgement. A coordinator can check that required attachments exist, that links open, that the stated edition matches the submission, and that a question has a named owner. A coordinator cannot infer that the evidence is correct merely because the documents are present.
This distinction between preparation and judgement is useful across domains. An engineer may need complete measurements before assessing a design. A teacher may need a clear account of a pupil’s attempted reasoning before identifying the misconception. An editor may need source access before evaluating a claim. Better preparation can improve the use of expertise without pretending that preparation itself has become expertise.
DORA’s guidance on work-in-process limits advises making work visible, accounting for real capacity, and focusing on finishing a manageable amount of prioritised work rather than spreading people across excessive simultaneous tasks. Its setting is technology delivery. The operational principle used here is to count the actual demand on a specialist, including supporting work, instead of treating their nominal allocation as uninterrupted production time. [5]
The team should be cautious about removing all interruptions. Some interruptions are the mechanism by which serious new information reaches the project. A protected review block should not prevent urgent safety information, a significant defect or a changed requirement from reaching the reviewer. The aim is a deliberate interruption policy, not isolation. Define which matters can wait, which need an alternate contact, and which justify breaking the planned sequence.
Farah and Leena agreed on a small preparation test. Before a bundle entered the ready queue, its owner would identify the version, the requirement being checked, the relevant evidence and the exact decision requested. The check was short and concerned availability and identity. It did not duplicate the substantive review. A bundle that failed the check stayed visible as incomplete preparation, with an owner and a reason, rather than being placed in Leena’s ready queue.
The policy created a risk of its own: a new gatekeeper could become a second bottleneck. To prevent that, preparation checks were distributed among capable authors and spot-checked, rather than routed through one additional central office. The team also examined whether a recurring missing field indicated a poor template. A preparation rule should make the required input easier to produce, not merely create a new place to reject it.
There is a deeper ethical distinction between exploiting a constraint in the technical sense and exploiting a worker. The former means using scarce system capability deliberately. The latter means extracting more labour without respecting limits, competence or consequences. The article’s proposed repair concerns the first. Sustainable capacity must account for rest, learning, support and necessary variation. A system that depends on permanent emergency effort has not solved its capacity problem; it has hidden part of its cost.
When Leena’s next review block began, the important improvement was not that every minute had been filled. It was that the first bundle was genuinely ready, the second had a coherent question, and the missing information on the third was being resolved elsewhere. The project had reduced the amount of expert attention spent discovering that work could not yet be done. That made the remaining judgement more productive without making it less careful.
13. Control admission, and keep the waiting outside visible
Once a team sees that more starts are increasing unfinished work, it is natural to impose a work-in-progress limit. The difficult part is not choosing a number. It is deciding what the limit means, what happens to existing work, how exceptions are authorised, and how demand outside the workflow remains visible. A number without those policies can become another colour on the dashboard.
For the fictional rollout, Farah considered a trial limit of ten active bundles across the defined delivery workflow. The number was a provisional operating choice, not a universal rule or a result derived from the number of employees. The team had fifteen active bundles already. It would not move five into a hidden category to make the board comply. It would show the over-limit state and reduce it through actual acceptance, authorised withdrawal or a legitimate transfer of ownership.
If five bundles were accepted while no new ones were admitted, active work would fall from fifteen to ten. At ten, another start would normally wait until a completion created space. The four unstarted commissioned bundles would remain in a visible pre-admission queue. Their promised dates and reasons for waiting would still matter. The policy controlled entry into active delivery; it did not cancel the project’s responsibility for the full commissioned set.
The trial also needed a starvation check. Suppose the ten active items were all waiting for an external permission and no ready work remained for configuration. A rigid global limit might leave useful capacity idle while the blocked set could not move. That observation would not justify abandoning all control. It would justify reviewing whether the system needed distinct limits, a controlled exception or a different definition of ready work. The policy should expose the conflict so the team can decide openly.
Different work classes may need different treatment. A serious defect in a live service cannot always wait behind optional enhancements. But an unlimited emergency lane destroys the ordinary limit. The project should define what qualifies, who can admit it, what existing work is displaced, and how repeated emergencies affect capacity planning. An exception is a change to the operating decision, not a magic item that consumes no time.
A limit also requires a replenishment rule. When space becomes available, the next item should be selected by an agreed combination of value, urgency, dependency and readiness. The rule need not be mathematically elaborate. It must be clear enough that the loudest message does not automatically decide. When a lower-ranked item is pulled forward, record the reason so the policy can be learned from rather than quietly eroded.
The most important reporting safeguard is the outer queue. Suppose the team reduces active work and reports shorter internal cycle time, while requests wait longer before admission. The customer may receive no improvement at all. The project should therefore show both request-to-delivery time and active-work time where those boundaries are relevant. The admission policy can still be valuable because it reduces overload and makes promises more credible, but it should not claim a customer benefit that the broader measure does not support.
There is a corresponding safeguard for blocked work. A started item remains a commitment even when nobody is currently touching it. Moving it out of WIP merely because it is blocked can free a nominal slot while the real coordination burden persists. The board should distinguish blocked state from absence. An actual cancellation or transfer can change the accounting; an inconvenient wait should not disappear through a filter.
Farah’s trial made a difficult conversation unavoidable. Elliot could no longer ask for every remaining bundle to start immediately without seeing the consequence. He could authorise an exception, change the sequence, increase capacity or reconsider the deadline. The limit did not make that decision for him. It made the trade-off visible at the point where a new commitment would enter the system.
A work limit is therefore not chiefly a way to stop people from working. It is a way to decide which work the organisation will actively promise to carry at once. Used well, it shifts attention from personal busyness to collective completion. Used badly, it becomes a device for hiding demand or delaying the measurement clock. The difference lies in the boundaries and evidence that accompany the number.
14. Split work for usable flow, then choose the sequence deliberately
Smaller items can move sooner, but smallness alone is not the objective. A release bundle should be divided where a receiver can obtain a coherent result or where a distinct uncertainty can be resolved. Splitting a document into arbitrary page ranges may increase the count of completed pieces while leaving every meaningful decision dependent on the whole. The correct division follows use, verification and dependency, not a desire for more cards.
Tomas proposed separating a bundle’s optional reporting feature from its core booking workflow. The core could operate without the report, and its acceptance criteria could be demonstrated independently. That made the split potentially useful. Another proposal separated the workflow from the supporting access rules. Those parts could not be treated as independently usable in the same way. The team rejected that split because it would make a partial result look more complete than it was.
A good slice has a defined receiver, a bounded purpose, enough evidence to establish its state, and an understood relationship to the remaining work. It may still depend on shared architecture. Independence is not absolute. The question is whether delivering or learning from the slice now creates something useful without concealing the obligation that remains. A thin but usable result is different from a disconnected fragment.
After splitting, sequencing matters. Consider three independent jobs requiring one, three and eight days on a single worker. All are ready at Day 0, there is no setup cost or interruption, and every job has equal value and no special deadline. In shortest-first order, completions occur on Days 1, 4 and 12, giving a mean completion time of 17/3 days. In longest-first order, they occur on Days 8, 11 and 12, giving a mean of 31/3 days. Both arrangements finish all work on Day 12.
The calculation shows that order can change when recipients receive value without changing total effort or final makespan. It does not prove that shortest-first is always the right project policy. The eight-day job may protect a critical deadline, enable other work, carry a mandatory obligation or serve someone who has already waited too long. Those conditions change the decision. A useful sequencing rule must account for them rather than treating mean completion time as the only objective.
Repeated arrival makes the fairness problem sharper. If new short jobs continually move ahead, a long job may wait indefinitely. An ageing rule can prevent such starvation: as a job’s wait increases, its priority is reconsidered. The rule should be explicit, particularly when different customer groups have unequal ability to escalate. Flow optimisation should not systematically disadvantage quiet or complex cases merely because they make the averages less attractive.
Another risk is pretending that estimates are exact. The one-day job may reveal hidden work; the eight-day job may be overestimated. Sequencing based on uncertain durations should carry that uncertainty. Small, informative first steps can be useful when they reveal whether a supposedly routine job is actually an investigation. But a team should not slice solely to manufacture optimistic estimates that are never reconciled with actual effort.
For Farah, the practical policy was a short, visible queue of genuinely ready bundles. The next selection considered the receiving date, dependencies, value and age. Leena could flag a bundle whose uncertainty required a different review arrangement. Nia could identify a bundle that operations could not yet absorb. The queue was not fixed forever; changes were made in the open, with an explanation of what would wait as a result.
The policy also distinguished starting from interrupting. An urgent new item could be next without automatically stopping the item already underway. Interruption might be justified, but it could impose restart work or invalidate a concentrated review. The project should compare the urgency with the cost of switching, rather than treating every priority update as an instruction to abandon current work immediately.
The point of smaller batches and deliberate sequencing is to improve the timing of worthwhile results, not to make the system look more active. A strong team can explain why a particular piece moves next and what value its finish will release. It can also explain why another piece must remain whole. That judgement is more demanding than adopting a slogan about tiny tasks, but it respects the actual structure of the project.
15. Some queues are calendars disguised as work
A decision can require thirty minutes of competent attention and still take two weeks to arrive. The delay may come from a monthly committee, an incomplete submission, an absent decision-maker or a rule that routes every exception to the same executive. Calling this a thirty-minute task does not describe its scheduling consequence. Calling it an executive-capacity bottleneck may also be premature until the reason for the wait is clear.
Farah found one bundle that had passed its technical checks but needed a choice between two operating arrangements. The decision paper described the background well and the decision poorly. Elliot had asked for clarification twice. The item appeared to be waiting for sponsorship, but part of the delay came from a question that nobody had framed sharply enough to answer. A shorter paper with a clear choice, consequence and required date could improve flow without changing authority.
Another bundle was different. Its decision was clear and the evidence complete, but the relevant forum met only once a week. A submission just after the cutoff waited almost a full cycle before discussion. If the decision then required one minor clarification, another cycle could be lost. The elapsed delay was generated partly by the calendar. Additional analytical effort would not necessarily shorten it.
A proportionate repair might reserve a short exception window, delegate a bounded class of reversible decisions, or allow an authorised asynchronous decision on a complete record. These are proposals for governance design, not instructions to bypass existing rules. The person who wants faster delivery may not have authority to alter the approval route. Until the authorised change occurs, the original boundary remains part of the project.
The decision queue should therefore record a latest useful decision point as well as a preferred meeting date. Suppose an alternative supplier needs three working days to mobilise before an installation window. The project may need the sourcing decision several days before the original component is due. Waiting until the delivery date to escalate loses the alternative. The meaningful deadline belongs to the remaining options, not merely to the visible milestone.
It is useful to separate preparation time, waiting for authority, decision time and implementation time. A signed decision that nobody incorporates into the plan has not yet changed the operating system. A change to the approved route may require updates to instructions, resource allocations, supplier communications or acceptance evidence. Counting the decision as the final completion can leave a second queue of authorised but unimplemented work.
Delegation must also preserve the decision’s scope. Authority to reorder low-risk work does not imply authority to waive a required test. Authority to prepare a recommendation does not imply authority to approve it. Clear boundaries can make local decisions faster precisely because people know which choices they may make without escalation. Vague delegation creates either unnecessary waiting or unauthorised action.
The team should avoid turning every delay into a demand for more executive involvement. If Elliot becomes the route for routine clarifications, he may become the bottleneck the project was trying to remove. The better repair may be clearer criteria, an identified technical owner or an agreed operating rule. Senior attention is valuable when it resolves a genuine cross-boundary choice; it is expensive when used to compensate repeatedly for missing local definitions.
There is a useful test for any approval step: what decision does it protect, what evidence does the decision-maker need, what authority is exercised, and what consequence would follow from an incorrect decision? A step with no defensible answer may be a candidate for removal or redesign. A step with a strong answer may need better preparation or more appropriate capacity. The existence of a queue does not decide which.
By the next meeting, Farah could distinguish a review backlog from a decision backlog. That mattered because the remedies belonged to different owners. Leena needed complete evidence and protected judgement time. Elliot needed a small number of explicit choices with consequences. The team stopped sending the same vague request around both queues. Work began moving not because everyone had become more urgent, but because each person could finally see the specific action that only they could take.
Part IV — Keep the repair coherent across the whole project
16. Buying capacity means buying capability at a particular time
Eventually a project may genuinely need more people, equipment or specialist access. The earlier disciplines are not an argument against investment. They are a way to understand what the investment must provide. “Another person” is not a capacity specification. Which work must the person be competent to perform, under what authority, with which access, and by what point in the schedule?
A new reviewer may bring relevant expertise while still needing time to understand the project’s requirements and evidence conventions. An existing colleague may understand the project but lack the specialist judgement required for a particular check. A contractor may be technically suitable but unavailable during the release window. These are different constraints. A headcount total hides them; a capability-and-calendar view makes them visible.
For an illustrative staffing comparison, suppose the team needs twenty additional hours of qualified review during each of the next three weeks. Candidate A can start immediately but needs ten hours of supervision in the first week and five in the second. Candidate B is already familiar with the work but cannot begin until Week 3. Neither can be described accurately as “twenty hours a week of extra capacity” across the whole period. The timing and supervision burden determine the usable addition.
The existing expert’s time must not be counted twice. If Leena spends ten hours onboarding Candidate A, those hours are unavailable for her own reviews unless other work is moved legitimately. The new colleague may still be the better choice, especially for a longer horizon, but the first week’s net gain could be smaller than the nominal allocation suggests. The project should model that temporary effect instead of treating onboarding as free.
Cross-training has similar trade-offs. It can create resilience and reduce dependence on one person, but it consumes current capacity and may not produce interchangeable expertise. Some tasks can be learned quickly; others require substantial supervised practice or formal qualification. The project should distinguish the work that can be distributed safely from the judgement that must remain with a suitably competent and authorised specialist.
A useful division is between routine preparation, routine execution and exceptional judgement. Several people may prepare complete evidence packets. Fewer may be able to perform a standard check reliably. A smaller group may need to handle unusual failures or disputed interpretations. Making these layers explicit can increase usable capacity without pretending every team member can perform every role. It can also give people a clearer development path.
There is a resilience argument even when average throughput does not rise immediately. A second capable reviewer may protect the project against absence or an unexpected surge. That benefit should be stated as resilience, not mislabelled as a guaranteed increase in ordinary weekly output. The same investment can have several purposes, but each purpose needs its own evidence and acceptance condition.
For equipment or software tools, capability includes integration and support. A faster test environment may still depend on prepared data, licences, access and staff who know how to use it. A second machine may compete for the same operator or utilities. A new workflow application may improve visibility while adding maintenance and training. The proposed purchase should be placed inside the complete work system, not treated as a self-contained capacity generator.
Farah therefore asked for a capacity proposal rather than a recruitment request. It identified the constrained work, the required competence, the calendar, the onboarding burden, the evidence of readiness and the downstream capacity available to use the output. Elliot could compare that proposal with alternatives: reducing scope, changing sequence, recovering existing expert time or accepting a later completion. The decision became more specific and therefore more defensible.
The underlying lesson is that capacity is not an abstract quantity detached from context. It is the ability to perform a defined kind of work to the required standard at the time the project needs it. A plan that hires the right skill too late can fail. A plan that hires the wrong skill immediately can fail faster. Bottleneck management improves the investment decision by making the required capability and timing explicit before money is committed.
17. A critical path is not the same as a capacity bottleneck
The critical path describes the dependency chain that determines a project’s duration under the model’s assumptions. A capacity bottleneck describes a restriction on the flow of work through a resource or process. They can coincide, but they answer different questions. Confusing them can produce a schedule that is logically connected and physically impossible, or a capacity improvement that does little for the actual completion date.
Consider an original four-stage example with two parallel design packages. Design A takes two days and Design B takes two days. Each then needs a three-day specialist review. A final two-day integration activity requires both reviews to finish. Assume both designs can begin on Day 0, and disregard holidays, rework and setup costs.
If each review has its own equally capable reviewer, both designs finish on Day 2, both reviews run from Day 2 to Day 5, and integration finishes on Day 7. The dependency-only model supports a seven-day duration. Now suppose there is only one reviewer and that reviewer can handle only one review at a time. One review runs from Day 2 to Day 5, the other from Day 5 to Day 8, and integration finishes on Day 10.
The task durations have not changed. The requirements have not changed. The resource arrangement has changed the feasible schedule. The additional three days are not explained by a missing technical dependency between the reviews; they arise from competition for the same person. Representing that competition is necessary for a credible plan.
The GAO Schedule Assessment Guide describes a reliable integrated schedule as a model that supports realistic timing and analysis of change. Its broader framework treats scheduling as more than a list of preferred dates. The miniature example here is our own calculation, used to show why the resources behind simultaneous activities must be credible. [7]
Now imagine the reviewer also supports another project whose deadline has higher organisational priority. The ten-day plan may still be optimistic if it assumes exclusive access. A project manager cannot repair that conflict by changing the dependency diagram alone. The decision belongs partly to shared-resource or portfolio governance. The schedule should record the actual allocation or a clearly labelled assumption, with a route for resolving it.
Critical-chain approaches explicitly address resource interactions and buffers, but this article is not presenting a complete implementation of that method. The transferable point is simpler: time precedence and resource feasibility are different layers. A useful project plan must reconcile both where they matter. Adding a buffer does not make an impossible simultaneous allocation possible; it provides protection only within a coherent model of the work.
The opposite confusion is also common. A team may identify the resource with the lowest recurring throughput and assume that improving it must shorten the current project’s finish. Yet the remaining project might be waiting on a one-off permit, a fixed external window or an entirely different near-critical path. Improving the recurring bottleneck could benefit future work while leaving the present milestone unchanged. That is not a failed investment if it was justified correctly, but it is not the promised schedule recovery.
Farah used two views together. The flow view showed where bundles accumulated and which capacities limited repeated completion. The project schedule showed which remaining dependencies controlled the committed rollout. When a proposed intervention looked valuable in one view, she tested it in the other. More review capacity could be worthwhile, but only if the relevant bundle and its downstream acceptance could use that capacity before the target window closed.
The existing Critical Path Method guide owns the detailed scheduling method. The Resource Management guide owns broader capacity allocation. Bottleneck management connects those subjects at a practical decision: which feasible change to the current resource-and-dependency system will alter the finish that matters? It is not enough to accelerate something important. The acceleration must reach the controlling path or improve a separately stated flow objective.
18. A faster handoff is useless when it carries the wrong version
The next problem did not look like a capacity problem at first. Tomas had updated a shared interface, and several bundles used the new description. Leena’s evidence packet still referred to the previous version. Nia’s operating instructions contained a mixture of both. Each team had worked quickly. Together, they had created a queue of questions about which state the project was actually reviewing.
This is where bottleneck management meets the preceding article in the series, Project Configuration Management. The configuration discipline preserves the identity of what was approved, built, tested and released. When that identity is unclear, scarce specialists spend time reconstructing the product before they can assess it. Apparent lack of review capacity may partly be a repeated information-consistency problem.
NASA’s configuration-management guidance connects controlled product identity, change records and consistency between a product and the information describing it. Its interface-management guidance addresses the definitions and responsibilities at the boundaries between cooperating elements. These are engineering sources, not a mandate to reproduce aerospace bureaucracy in every project. Their relevant point is that a handoff needs an agreed, identifiable state. [8] [9]
For Farah’s bundles, the minimum repair was a release identity that travelled with the evidence and operating instructions. The record identified the relevant build, requirement set and source packet. A reviewer could then determine whether a finding concerned the current candidate or an earlier one. The team did not need an elaborate new database before it could stop referring to everything as “the latest version.”
The distinction among approval, implementation and observation remained important. An approved change did not prove that Tomas had implemented it. An implemented change did not prove that deployment used the intended build. A successful technical write did not prove that the receiving service displayed or operated the new state correctly. Each event had a different evidential role. Collapsing them into one “done” status created uncertainty that returned later as rework.
A similar distinction applies to physical handoffs. A drawing may be revised while an installed part remains unchanged. A supplier may make an authorised substitution but omit the corresponding record. A training manual may describe the intended procedure while staff are using an older version. The project should not infer consistency merely because each separate document has an approval mark. The approvals must concern compatible states.
When a version changes, ask what evidence remains valid. A spelling correction may leave a technical test unaffected. A changed data transformation may invalidate a relevant test. The answer should come from an impact assessment, not an automatic decision to repeat everything or to repeat nothing. Both extremes can waste constrained capacity: unnecessary retesting consumes time, while missing retesting creates defects that return under worse conditions.
The team also examined feedback paths. A reviewer could identify a wrong version, but who corrected the shared reference so the next five authors did not repeat the mistake? A local correction resolved one bundle; a corrected source and clear effective date could prevent a family of future returns. This is how a bottleneck investigation becomes a system improvement instead of a permanent queue-clearing exercise.
There is an important restraint. Stable identifiers and content checks do not prove that the content is true or that its author had permission to release it. They prove which representation is being discussed. A checksum can show that two copies match; it cannot establish that the matched claim is correct. Identity is necessary evidence for some decisions, not a substitute for the substantive evidence those decisions require.
After the repair, Leena’s queue did not become magically empty. It became more reviewable. Questions about identity no longer consumed the same share of each review. Nia could tell which instructions belonged to the candidate she was receiving. Tomas could see which changes required another test. The flow improvement came from reducing ambiguity at the boundary, while preserving the review itself. That is a more durable gain than simply asking the reviewer to move faster through contradictory material.
19. When AI makes drafts cheap, verification can become the constraint
Automation can change the location of a bottleneck without changing the project’s final capacity. Suppose a drafting stage can produce forty candidates per week and the complete verification-and-release system can accept ten. Increasing drafting capacity to eighty does not, by itself, increase the ten accepted outputs. It may improve selection, reduce drafting effort or make experiments cheaper. But uncontrolled admission of the extra candidates can also create a larger verification queue.
This is an arithmetic and workflow observation, not a prediction about a particular AI product. The actual benefit depends on which work the tool replaces, which new checking it creates, and where the resulting output enters the controlled system. A model that helps assemble a clear evidence packet may save reviewer time. A model that produces fluent but unsupported claims may consume more of it. Generation speed alone does not distinguish those outcomes.
Consider a separate cost-of-effort illustration. A person takes forty minutes to produce a draft. Initial review requires twenty minutes, and one fifth of drafts need a ten-minute correction check. Expected effort for that simplified route is 40 + 20 + 0.2 × 10 = 62 minutes. Now suppose an automated route takes two minutes to generate a candidate, still needs twenty minutes of review, and half its candidates need the same ten-minute correction check. Expected effort is 27 minutes. The model suggests a gain, but the assumptions about review and correction carry most of the decision.
Change those assumptions and the result changes. If the automated output needs sixty minutes of source reconstruction, the apparent drafting gain may disappear. If it reliably prepares data and citations the reviewer would otherwise spend time locating, the gain may be larger. The project should measure the complete route to accepted use rather than stopping the timer when the model finishes producing text or code.
NIST presents its AI Risk Management Framework as a resource for incorporating trustworthiness considerations into AI design, development, use and evaluation. Its public material reinforces the need to manage the system’s risks, not merely its generation capability. The application here is an original operational proposal: treat generated work as a candidate until the project’s actual evidence and authority requirements are satisfied. [10]
A useful workflow keeps candidate state separate from verified state. An assistant may propose a dependency, suggest a test, summarise an issue or identify a possible inconsistency. The accountable owner determines whether the proposal reflects the real project. The record should preserve source identity and uncertainty. A fluent summary must not silently turn “not yet observed” into “complete,” or “recommended” into “approved.”
The same model reviewing its own output can provide a useful additional check, but it should not be described as an independently accountable reviewer merely because it receives a different role name. Independence concerns the actual review arrangement, access to evidence, competence and accountability. Where a project requires separate approval or review, automation should support that requirement rather than simulate its existence through labels.
Farah considered using AI to triage incomplete submissions. The bounded job was to identify missing attachments, inconsistent version references and unanswered required fields. The tool would not decide that a source supported a claim or that a bundle was safe to operate. False alarms would be reviewed; missed omissions would be recorded. The purpose was to reduce avoidable preparation friction without granting the tool authority over release.
The intervention also needed an admission policy. Faster generation should not force more work into Leena’s queue simply because the candidates exist. The team could compare alternatives cheaply, reject weak approaches early and admit only the selected work. That is one potential use of abundant generation capacity: improve choice before commitment rather than maximise the stock of unfinished commitments afterward.
The broader lesson is not that AI inevitably creates a review bottleneck. It is that any dramatic acceleration should be followed through the complete system. Ask what becomes scarce next. It may be verification, integration, operational absorption, decision authority or meaningful demand. The organisation gains when automation increases useful capability under the required conditions. It does not gain merely because the easiest stage of the workflow now produces more than everyone else can responsibly use.
20. A portfolio can have more than one binding constraint
The convenient image of one narrow neck becomes less reliable when different kinds of work consume different resources. A reviewer may constrain one project mix while deployment constrains another. Two resources may bind at the same time. The correct bottleneck diagnosis therefore depends on the work the organisation chooses, not only on the capacities it owns.
Consider an original two-resource model. The organisation has twelve review hours and twelve deployment hours available during a planning interval. Type A bundles require three review hours and one deployment hour each. Type B bundles require one review hour and three deployment hours each. All bundles are ready, resources are independent, only whole completed bundles count, and the deliberately simplified objective is to complete as many bundles as possible. There are enough eligible requests of both types.
Let a be the number of Type A bundles and b the number of Type B bundles. The constraints are 3a + b ≤ 12 for review and a + 3b ≤ 12 for deployment. Choosing only A produces at most four bundles; review is fully used while deployment has spare capacity. Choosing only B also produces at most four; now deployment is fully used while review has spare capacity.
Choosing three of each produces six bundles and uses all twelve hours of both resources. Adding the two capacity inequalities gives 4a + 4b ≤ 24, so a + b ≤ 6. The three-and-three mix reaches that bound. It is therefore optimal for the stated count objective and assumptions. No intuition about the single busiest department is needed to establish the result.
| Planned mix | Review hours | Deployment hours | Completed bundles | Feasible? |
|---|---|---|---|---|
| 4 A, 0 B | 12 | 4 | 4 | Yes |
| 0 A, 4 B | 4 | 12 | 4 | Yes |
| 2 A, 3 B | 9 | 11 | 5 | Yes |
| 3 A, 3 B | 12 | 12 | 6 | Yes |
| 4 A, 3 B | 15 | 13 | 7 | No |
The example reveals two important qualifications. First, the constraint is partly a property of the chosen work mix. Second, improving one resource may produce little immediate gain if another remains binding. Adding two review hours while deployment stays at twelve gives a combined bound of a + b ≤ 6.5; with whole bundles, no more than six can finish. Extra review time might still improve resilience or support another objective, but it does not increase the maximum count in that modified model.
Real portfolio decisions cannot usually treat all bundles as equally valuable. Type A might address a mandatory obligation; Type B might be optional. One bundle may enable several later projects. Another may serve a group that would otherwise receive no service. The count objective is a teaching simplification, not an ethical ranking rule. A real model must represent the organisation’s actual objective and non-negotiable obligations, then make the judgement behind its weights visible.
Demand limits also matter. If only one useful Type B bundle exists, the attractive three-and-three solution is unavailable. If the two resources share a person, their nominal capacities cannot be treated as independent. If a bundle must finish before another begins, time sequencing can invalidate a plan that fits aggregate hours. The arithmetic model is valuable because it exposes these assumptions, not because it can safely ignore them.
Farah used this way of thinking when several projects requested Leena’s time. Her own project might improve its local finish by taking every review slot, but the organisation could lose more important output elsewhere. The appropriate decision required a view across commitments. The Portfolio Management article owns that selection problem; bottleneck analysis supplies evidence about the resource consequences of different choices.
The lesson is a limit on a familiar slogan. A project system does not always have one permanent bottleneck that can be improved in isolation. It can have interacting constraints, changing mixes and several legitimate objectives. A manager should use the simplest model that preserves the decisive relationships. When the one-neck picture no longer fits, adding a second constraint to the analysis is not overcomplication. It is the minimum honesty required by the work.
Part V — Make the improvement worth having
21. Throughput is an instrument, not the purpose of the institution
Nia asked a question that the rate table could not answer: what happened after a bundle was accepted? Some changes made the service easier to operate. Another created a new report that nobody needed during ordinary work. Both counted as one accepted bundle under the delivery definition. The project had improved the precision of its completion measure without proving that every completion had equal value.
This is not a reason to abandon throughput. It is a reason to place it inside a larger account of purpose. A delivery measure tells the organisation how reliably it turns selected commitments into accepted outputs. It does not determine which commitments deserve selection. A learning programme, a public service and a commercial product can all require flow discipline while pursuing different outcomes and observing different obligations.
For an educational example, a teacher may produce twenty marked exercises while a learner continues making the same reasoning error. The count establishes that feedback activity occurred. It does not establish that the learner can recognise the error independently, repair it or transfer the understanding to a new problem. The relevant educational question remains with the learner’s demonstrated capability, not the quantity of material processed.
This example should not be interpreted as a formula that turns learning into factory throughput. Learners are not interchangeable work items, and developmental progress cannot be reduced to an arbitrary production rate. The useful transfer is narrower: distinguish the activity a teaching system performs from the capability it intends to develop. Then investigate the specific point at which the intended change fails to occur, with suitable evidence and professional judgement.
The same distinction applies to publishing. Producing a long article is an output. Helping a reader understand a mechanism, diagnose a situation or make a better decision is the intended benefit. Word count can establish that a commission’s scale has been met; it cannot establish that the words are worth reading. A long article earns its length through necessary development, worked reasoning, counterexamples and a route back to practical use.
Farah used this principle to revisit the optional report. It had a plausible origin: an early stakeholder wanted reassurance that the system could generate it. By the time the bundle reached review, the operating process had changed. The report no longer served the same purpose. Finishing it quickly would improve the completion count, but it would also create another feature to maintain. The appropriate decision was to reconsider the commitment through the authorised scope route.
Stopping that work was not a throughput increase. The team recorded a withdrawal separately. It also preserved the reason so a future request could be assessed without reconstructing the old debate. A cancellation can improve the allocation of scarce capacity even though it does not produce another accepted deliverable. This is one reason a mature management account needs more than a single success number.
The organisation should also examine who benefits from a faster flow. A team might reduce its own processing time by transferring preparation to customers or another department. That can be reasonable when the receiver has the capability and the arrangement is fair. It can also be a hidden transfer of burden. The improvement claim should include the work moved outside the measured boundary, especially when the people receiving it have little influence over the decision.
Accessibility belongs in the same conversation. A standardised process may serve most users quickly while making legitimate exceptions difficult. The apparent bottleneck might be the specialist handling those exceptions. Removing the specialist could improve the average while excluding people the service is meant to support. A responsible repair considers whether routine work can be simplified to preserve capacity for difficult cases, rather than treating difficult cases as the reason the system is inefficient.
The Benefits Realisation article owns the fuller route from outputs to outcomes and value. Bottleneck management contributes by making selected work finish more reliably. It must remain subordinate to the selection and acceptance standards that give those finishes meaning. An organisation should become better at delivering worthwhile work, not merely more efficient at completing whatever happened to enter its queue first.
22. Read the tail, the mix and the unfinished work
Averages are useful summaries, but a bottleneck can hide inside them. Suppose one class of work reliably takes two days and another reliably takes ten. In Week A, eight completed items belong to the two-day class and two to the ten-day class. Mean completion time is 3.6 days. In Week B, eighteen completed items belong to the two-day class and two to the ten-day class. The mean falls to 2.8 days.
Nothing improved within either class. The mix changed. This is an exact arithmetic example, not a reported organisational study. It shows why a manager should ask what work the average represents before attributing a change to a new method. A growing share of easy cases can make the dashboard look better while difficult cases remain just as slow.
The reverse is possible too. A team that deliberately tackles old, difficult work may report worse average completion time for a period. That can be a healthy change if previously neglected commitments finally finish. A dashboard that punishes the team for those completions may encourage it to continue selecting only easy items. The metric then shapes the queue in a way that contradicts the organisation’s stated responsibility.
Unfinished work requires its own view. An item that has been active for twenty days does not appear in a completed-items average until it finishes. If the reporting period ends before that happens, the oldest work can remain statistically invisible. Record current age and the reason for continued waiting. Age does not prove a bottleneck, but it identifies items whose eventual flow time is already becoming long.
The tail matters because recipients experience individual waits, not only averages. A service that usually completes work in three days but sometimes takes thirty may need a different management response from one that consistently takes six. Which is preferable depends on the need and the consequences. Do not assume that a lower mean compensates for every extreme delay. A promised deadline, a vulnerable user or a critical dependency may make the tail decisive.
A practical dashboard can remain small. It might show accepted completions by work class, active inventory, the age of the oldest material items, ready demand at the suspected bottleneck, and significant return work. Add a quality indicator tied to the actual acceptance standard. The point is not to collect every possible measure; it is to retain the distinctions that could change a management decision.
Ready demand should be separated from blocked demand. A review queue containing ten cards, eight of which lack required information, tells a different story from ten complete reviews awaiting a fully occupied specialist. Both can be serious. The first may call for upstream repair; the second may justify capacity or sequencing changes. A total queue count can conceal that distinction unless the state definitions preserve it.
Forecasts need the same care. If last month’s work mix differs from the coming month, historical throughput may not predict the new workload. A project can still use it as a starting point, but the adjustment should be explicit. Changes in staffing, review criteria, tools or source quality can also alter the process. A forecast built from history should say what makes that history relevant to the current decision.
Farah added a small note beside her weekly figures: which kinds of bundles were included, which remained unfinished, and what had changed in the operating conditions. It made the report less tidy. It also prevented the team from claiming that every movement in the average was caused by the intervention they happened to like. The point of measurement was to learn which explanation survived the evidence.
A useful management question is therefore not simply “Did cycle time fall?” It is “For which work, under which conditions, with what effect on the oldest cases, quality and total customer wait?” That question is longer because the real system contains more than one number. A good dashboard can compress the answer, but it should not erase the distinctions that make the answer true.
23. Test an intervention without pretending a before-and-after chart proves causality
The team selected one initial intervention: complete, consistently identified evidence packets would enter the ready-review queue individually rather than in a weekly batch. This combined a preparation change with a transfer-policy change. Farah recorded both because she did not want to attribute any improvement to only one of them later. A practical experiment can change more than one thing, but its interpretation should admit that fact.
The hypothesis was specific. Incomplete submissions and batch arrivals were consuming review time and extending waits. Better preparation and smaller transfers should reduce avoidable clarification and allow some reviews to begin earlier. The expected result was not a guaranteed increase in final accepted bundles, because operational acceptance might still limit output. The intervention’s first measures therefore concerned the mechanism it directly addressed.
Farah recorded the proportion of submissions missing required material, the time from complete submission to review start, the amount of significant clarification work, and the review disposition. She also retained final acceptance and downstream queue information. Without the downstream view, the team could celebrate a faster review stage while simply transferring the accumulation to Nia.
A short before-and-after comparison could reveal a promising pattern, but it would not isolate cause automatically. The later period might contain easier bundles. Leena might have more available hours. A shared interface defect might have been fixed independently. An external deadline might have altered priorities. These conditions should be recorded as possible alternative explanations rather than ignored because the chart moved in the preferred direction.
Where practical and appropriate, comparable work can be introduced to a new preparation method in stages. The project might retain the same substantive acceptance criteria and compare the operational experience of similar bundles under the old and new preparation arrangements. It must not withhold necessary safety or quality controls merely to create an experiment. The variable being tested should be a legitimate, bounded work method.
Small samples require modest claims. Suppose clarification returns fall from five to two across two short periods. That is encouraging, but the denominator, case mix and reasons for returns matter. Five returns among fifty submissions differ from five among ten. A return caused by a newly discovered requirement differs from one caused by a missing attachment. The project should inspect the actual cases before converting the observation into a general performance claim.
An unsuccessful trial can still be useful. If complete submissions arrive smoothly but review waiting remains unchanged, the capacity restriction may be more fundamental than expected. If review waiting falls but final acceptance does not, the next stage may now be controlling. If the preparation rule consumes excessive author time without reducing returns, the rule may need simplification. The experiment should have a route for rejecting the preferred intervention.
The stopping conditions matter as well. An intervention that creates unsafe work, conceals blocked items or causes important obligations to be missed should not continue merely to complete the observation period. A trial is a controlled change to the project, not permission to suspend judgement. Define who can stop it and what evidence would justify reversal or adjustment.
Farah’s report used three levels of statement. “Observed” described the recorded events. “Consistent with” described a plausible explanation supported by the pattern. “Not established” identified the causal claim the short trial could not prove. This vocabulary did not weaken the report. It made the next decision clearer: continue the low-risk change, gather more evidence, or examine a competing cause.
The Project Assumption Management guide provides the adjacent discipline of recording what the plan treats as true. A bottleneck intervention should use the same honesty. The project can act on a reasonable hypothesis without promoting it to certainty. What matters is that the action is proportionate, the expected mechanism is visible, and the team remains willing to change its explanation when the evidence does not cooperate.
24. A ten-working-day diagnostic that does not promise a ten-day cure
A team can begin investigating flow without waiting for a perfect information system. The following ten-working-day sequence is a proposed diagnostic, not a promise that every bottleneck can be removed in that time. A project with monthly approval cycles or long production lead times may need a much longer observation window to evaluate results. The short sequence is intended to establish a coherent question, a usable record and one bounded next action.
On the first two days, define the objective, item and boundaries. Select one material workflow rather than every activity in the organisation. Agree what counts as started, what counts as accepted, and where requests wait before admission. Name the receiving owner. Reconcile the current stock so that blocked work, withdrawals and unstarted demand do not vanish into different reporting conventions.
During Days 3 and 4, follow a sample of actual items. Include a recent smooth completion, an old unfinished item, a typical item and a difficult exception. Record significant state changes, missing inputs and decision waits. Ask the people doing the work to correct the map. The purpose is not surveillance; it is to identify the intervals and relationships the task list fails to explain.
On Day 5, compare the competing explanations. Is ready work accumulating at a fully loaded service? Is the queue mostly incomplete submissions? Is a calendar or authority rule causing delay? Is the work mix different from what the capacity plan assumed? Select one hypothesis whose correction is reversible enough to test and consequential enough to matter. Record the expected change and the conditions that could invalidate the interpretation.
During Days 6 to 9, run the bounded change where authorised. Possible interventions include a clearer submission packet, smaller coherent transfers, a protected specialist block, an explicit replenishment rule or a revised decision-preparation format. Do not start five unrelated improvement programmes and then attribute every result to the combined label. Preserve the acceptance standard and record any exceptions or unintended effects.
On Day 10, review what has actually been observed. The correct outcome may be a better diagnosis rather than a measured throughput gain. A queue that takes weeks to traverse cannot provide a complete before-and-after answer in four days. In that case, inspect leading evidence: fewer incomplete inputs, clearer ownership, usable capacity recovered or a threatened decision window made visible. Keep final outcome claims open until the relevant work can finish.
| Diagnostic interval | Main question | Tangible output |
|---|---|---|
| Days 1–2 | What are we trying to make finish? | Defined item, boundaries and reconciled stock |
| Days 3–4 | Where does real work wait, and why? | Small event sample and corrected workflow map |
| Day 5 | Which explanation is worth testing first? | Constraint hypothesis and bounded intervention |
| Days 6–9 | Does the predicted mechanism change? | Observations, exceptions and unchanged standards |
| Day 10 | What can we responsibly conclude? | Continue, revise, stop or extend the observation |
The sequence needs named ownership but not a large steering group. One coordinator can maintain the record. The producer and receiver clarify handoffs. The relevant authority approves changes to rules or commitments. A specialist determines whether technical or safety evidence remains sufficient. These roles can be combined where legitimate, but the project should not confuse coordination with approval or self-checking with a separately required review.
The diagnostic should also preserve the baseline. Record the original dates and operating rules before changing them. Otherwise the team may discover at the end that it cannot distinguish improved performance from revised promises. Keeping history does not prevent sensible re-planning. It makes the difference between the old commitment and the current authorised plan intelligible.
A useful final artefact is a short decision record, not a grand transformation presentation. It states the suspected restriction, supporting observations, intervention, observed result, remaining uncertainty, next owner and next review condition. A manager reading it later should be able to understand why the team acted and what would cause it to reconsider. The record turns a local experiment into reusable organisational knowledge.
Farah’s first diagnostic did not eliminate every wait. It established that several supposed review delays were preparation defects, that complete work arrived in batches, and that operational acceptance would become more important if review improved. That was enough to change the next resource conversation. The team had replaced a general demand for more effort with a specific set of choices about input quality, timing and capacity.
25. An improvement can cost more effort and still be worthwhile
Efficiency discussions often treat reduced total effort as the only possible gain. Bottleneck management asks a different question: how does a change affect the objective under the actual constraints? A project may legitimately spend more non-constrained effort to save scarce specialist time, reduce a consequential delay or prevent a defect. That does not make the extra effort free. It means the trade-off should be evaluated explicitly.
Return to the thirty-hour reviewer week. Suppose eight hours of coordinator preparation can remove six hours of avoidable work from the reviewer. Total project effort rises from thirty to thirty-eight hours if nothing else changes. The reviewer gains six hours for the work only that role can perform. The organisation may find that worthwhile if those hours protect an important completion and downstream capacity can use the result.
It would be misleading to describe the change simply as “saving six hours.” It saves six hours of one capability while consuming eight hours of another. Costs, availability and alternative uses may differ. The correct proposal identifies both sides. It should also ask whether the coordinator’s work can be simplified or partly eliminated by improving the submission template, rather than permanently transferring a poorly designed task.
Not every worthwhile improvement increases throughput. A clearer record may make incident investigation faster. A second capable person may reduce absence risk. Better accessibility may serve users previously excluded. A safer process may reduce unacceptable exposure. These benefits can justify work outside the currently binding production constraint. A narrow throughput doctrine should not be used to dismiss them merely because the weekly completion count stays unchanged.
Conversely, not every throughput increase is worth purchasing. If the organisation has no additional useful demand, more capacity may sit idle or encourage unnecessary work. If another stage immediately limits output, the marginal gain may be small. If the new method creates maintenance or support obligations that exceed the benefit, the apparent acceleration can become a long-term burden. The full lifecycle matters.
The timing of value can also matter more than the final quantity. In the six-package example, item-by-item transfer produced the first usable package on Day 6 instead of Day 31, even though all six eventually finished under both policies. Earlier use might reveal a requirement problem before the remaining work is committed. It might also be unnecessary if the receiver cannot use any package until a fixed event. The project should investigate that value rather than assume every earlier local finish is beneficial.
This is where the language of “cost of delay” needs care. A delay can affect revenue, service, learning, risk or an external obligation. The consequence is context-specific. A manager should not invent a monetary value merely to make a prioritisation formula work. When the value cannot be measured credibly in money, it can still be described through the actual consequence and the authority responsible for weighing it.
There are also non-negotiable boundaries. A required safety condition or lawful obligation is not simply another weighted preference that can be offset by enough speed elsewhere. Where a change affects such a boundary, the appropriate specialist and decision authority must be involved. Bottleneck analysis can show the operational consequence of the condition; it does not grant permission to disregard it.
Elliot’s eventual capacity discussion therefore contained several alternatives, each with a different purpose. Recovering existing review time addressed avoidable preparation friction. Adding qualified review capacity addressed recurring ready demand. Preparing operations earlier addressed a downstream restriction. Withdrawing an obsolete reporting bundle addressed unnecessary demand. The options were not competing slogans about working smarter. They were different changes to the same delivery system.
A strong improvement proposal ends with an observable condition. What useful result should change? What additional work or risk is being accepted? What evidence would show that the trade was worthwhile? What would cause the organisation to stop or revise it? These questions keep bottleneck management connected to stewardship. The aim is not to maximise activity at any stage, or even to maximise throughput without qualification. It is to use limited capability responsibly in service of a worthwhile outcome.
Part VI — Practise the diagnosis and make it durable
26. Clinic one: the board says seventeen, but the work says nineteen
A project begins a week with eighteen active items. Nine new items enter the defined workflow. Six items reach accepted completion. Two are formally withdrawn after an authorised scope decision. There are no splits, merges or transfers. At the end of the week, the board shows seventeen active items. Two additional started items appear in a separate “blocked by supplier” view and are excluded from the headline total.
The team says it has reduced WIP because the main board fell from eighteen to seventeen. It also says the supplier is the bottleneck because the two oldest items are in the supplier-blocked view. Before accepting either conclusion, reconstruct the system. The exercise concerns an invented project; all the information needed for the accounting question is provided above, but not all the information needed for a bottleneck diagnosis is provided.
First, calculate the actual active stock under the stated boundary. Second, decide how the withdrawals should be reported. Third, identify what additional evidence would be needed to determine whether the supplier controls overall completion. Fourth, describe a next action that improves the information without pretending the diagnosis is already complete.
Open the worked answer: reconcile the stock before diagnosing the constraint
The ending stock is 18 + 9 − 6 − 2 = 19 active items. The two supplier-blocked items remain started and unfinished, so they remain inside the defined active boundary. Seventeen is the count in one board view, not the count of all active commitments. The project has increased active inventory by one, not reduced it by one.
The six accepted completions and two withdrawals should be reported separately. Both reduce active stock, but only the six establish the defined completed output. The withdrawals may be sensible decisions that release scarce capacity. They should not be hidden, and they should not be described as equivalent to delivering accepted work.
The two old supplier-blocked items establish an important delay, not necessarily a system bottleneck. Ask what they need from the supplier, when that input is required, whether the supplier’s capacity is actually the problem, what downstream work depends on them, and whether other ready items can still finish. They may control the final project milestone even if they do not limit the recurring throughput of the rest of the workflow.
A useful immediate action is to reconcile the main board with the blocked view, retain a single identity for each item, and assign a specific next event to each supplier block. “Confirm the current accepted delivery forecast and assess the last useful alternative date” is more actionable than “chase supplier.” The project should also identify whether the supplier is waiting on information from the client. Ownership of the visible queue does not establish ownership of its cause.
The exercise tests a common weakness in improvement reports: the measurement boundary changes just when the data becomes uncomfortable. A team may sincerely believe that a blocked item is not work in progress because nobody can currently work on it. But the item still consumes commitment, coordination and future capacity. Its age continues to matter to the receiver. A clear definition should survive the inconvenience of the blocked state.
The next diagnostic step depends on the project’s objective. If the two supplier items are essential to final integration, they may deserve priority even while many other items continue to finish. If they concern optional work that can be withdrawn, a scope decision may release the project. If the supplier is waiting on an unanswered client question, the immediate repair may be internal decision-making. The same two red cards can conceal three different management problems.
It is also possible that the main board’s seventeen items contain a more significant recurring capacity restriction. Perhaps ten complete reviews await one specialist while the supplier issue affects only a small side path. That would not make the supplier delay unimportant. It would mean the organisation should distinguish the recurring flow objective from the final-project milestone objective. The correct prioritisation could involve both, with different owners and different measures.
A mature report can therefore say: active inventory is nineteen; accepted completions are six; two items were withdrawn; two old supplier blocks need a dependency-and-options review; the current system bottleneck is not yet established. That statement is less dramatic than “supplier bottleneck resolved by reducing WIP,” but it gives the next manager a trustworthy starting point. The discipline begins with a reconciled account of what exists.
27. Clinic two: the plan with the biggest count is the wrong plan
A release team has sixteen qualified review hours and twelve deployment hours available in a fixed planning window. A standard bundle requires two review hours and one deployment hour. A complex bundle requires four review hours and three deployment hours. All work is ready. The resources are separate, there are no other timing constraints, and every bundle must meet the same defined acceptance conditions for its type.
The commissioned objective requires three specific complex bundles to finish during the window. There are also many useful standard bundles waiting. The team proposes completing eight standard bundles because eight is the largest simple output count it can see. Another proposal completes four complex bundles, fully using both resources. A third completes the required three complex bundles and as many standard bundles as the remaining capacity permits.
Which proposal satisfies the brief and produces the largest count of accepted bundles under that brief? What is the smallest addition of review capacity that would allow one more standard bundle? Would adding deployment hours alone change the best feasible result? The exercise is about respecting an objective before optimising it, not about treating complex work as inherently more important in every real project.
Open the worked answer: preserve the required work, then optimise the remainder
Eight standard bundles use sixteen review hours and eight deployment hours, but they complete none of the three required complex bundles. The count is large and the plan is wrong for the stated brief. Four complex bundles use sixteen review hours and twelve deployment hours, satisfy the minimum complex requirement, and produce four accepted bundles.
The required three complex bundles use twelve review hours and nine deployment hours. Four review hours and three deployment hours remain. That capacity supports two standard bundles, using another four review hours and two deployment hours. The result is five accepted bundles: three complex and two standard, with sixteen review hours and eleven deployment hours used.
A third standard bundle requires two more review hours and one more deployment hour. The deployment hour already exists in the baseline allowance. Increasing review capacity from sixteen to eighteen hours therefore permits six accepted bundles: three complex and three standard, using eighteen review hours and all twelve deployment hours. Adding deployment hours alone does not overcome the original sixteen-hour review limit.
Once review capacity reaches eighteen hours, further review capacity by itself does not support a fourth standard bundle while the three required complex bundles remain. Deployment is now fully used. The next additional standard bundle would need both further review capacity and further deployment capacity. The binding restriction has changed because the feasible plan changed.
The exercise is deliberately deterministic. A real project would need to account for uncertainty in the durations, availability and acceptance effort. It might also need to preserve reserve capacity for urgent defects. The calculated plan uses all review capacity in the five-bundle baseline and all capacity of both kinds in the six-bundle option. That leaves no allowance for disruption. Whether such a commitment is responsible depends on the actual variability and consequences.
The example also shows why local utilisation is not a complete objective. The five-bundle plan leaves one deployment hour unused, yet it produces more acceptable output under the brief than the four-complex plan, which fills both resources. Filling every available hour is not necessarily the same as making the best use of the system. Unused capacity can be the natural consequence of another binding limit or of indivisible work.
There is a governance lesson as well. The three required complex bundles are requirements of the exercise, not preferences the optimiser may silently trade away. In a real organisation, some commitments can be changed by an authorised decision and some are governed by external obligations. A model may help reveal the consequence of changing them. It must not redefine the objective on its own because a different plan produces a more attractive count.
For Farah, this was a useful analogy to the rollout’s difficult bundles. A plan that completed only the easiest features could look fast while leaving the core service incomplete. The right response was to make the required work visible, understand its resource demands and choose the surrounding work accordingly. That might lower the headline count for a period while protecting the purpose of the project.
The practical question is therefore: which commitments must remain fixed before we optimise the rest? Write them down. Then show the resource use of candidate plans, including unused capacity and missing capacity. A small table can make the trade clearer than a weighted score whose assumptions nobody can explain. The best model is the one that helps an accountable person make the actual decision, not the one that produces the most impressive mathematical result for a different problem.
28. When a sensible repair stops being sensible
Bottleneck management must remain revisable because the work system changes. A policy that was useful during one stage can become an obstacle during another. The answer is not constant improvisation; it is an explicit review of the assumptions under which the policy was selected. Preserve the purpose, examine the new condition, and change the method through the appropriate authority when the evidence justifies it.
Consider a WIP limit that successfully reduced a review backlog. Several weeks later, most active items are waiting on external equipment, while the design team has no ready work left. The original limit may now prevent useful preparation that could occur safely in parallel. The team should not hide blocked items to create artificial room. It should review the limit’s scope, the dependency horizon and the consequences of an exception. The need for a change is information about the system, not proof that limits never work.
Consider a small-batch policy introduced to reduce waiting. Later, the work involves a tightly coupled interface change that requires coordinated verification across several components. Continuing to release tiny fragments may create incompatible states or repeated integration effort. The appropriate repair may be a coherent combined release for that change, while retaining smaller transfers elsewhere. A principle of early feedback does not require ignoring technical coupling.
Consider a preparation checklist that initially removes common omissions. As the team learns, the checklist grows whenever a rare problem occurs. Eventually every submission requires a long set of fields, many irrelevant to the work. Authors spend more time explaining why fields do not apply than preparing the evidence that matters. The checklist has become a candidate for simplification. Retain the necessary controls, distinguish common from exceptional cases, and remove requirements whose purpose can no longer be defended.
Consider a dedicated specialist block that protects concentration. If the organisation then routes every routine question into the block, the block becomes another batching mechanism. If it prohibits urgent escalation, it may delay consequential information. The repair is not necessarily to abandon protected time. It is to define which questions can be handled elsewhere, which can wait, and which require immediate attention. A schedule rule should serve the work, not become an unexamined authority of its own.
A capacity investment can become stale too. The organisation may hire for the old bottleneck just as the work mix changes. That does not make the new capability worthless; it may provide resilience or support future demand. But the original throughput promise should be reassessed. Continuing to label the old station as the bottleneck can lead the team to optimise a resource that no longer controls the current objective.
There is also the case where the project should stop improving the existing route and reconsider the route itself. Repeated attempts to accelerate an unnecessary report, an obsolete integration or a service nobody can operate may be treating the wrong problem efficiently. The evidence may call for a scope or strategic decision rather than another local process intervention. The Project Recovery guide addresses wider reconstruction when the current plan no longer provides a credible path.
The review should preserve a distinction between an ordinary shortfall and a crisis. A queue that is longer than expected may need a capacity decision. An active event threatening safety, essential service or serious irreversible harm may require the organisation’s specialist incident arrangements. This article is not an emergency-response procedure. Flow improvement should not displace the authority and competence needed to contain acute harm.
Farah used a simple review trigger: whenever the work mix, acceptance boundary, key resource or external dependency changed materially, the constraint hypothesis would be revisited. The team would not automatically redesign the whole process. It would ask whether the reason for the existing rule still held. That preserved useful stability while leaving a legitimate route for adaptation.
The durable capability is therefore not one perfect queue policy. It is the ability to notice when a policy’s assumptions expire. A team that can revise its explanation without erasing its history is better equipped than a team that declares every local success a permanent law. The bottleneck is a feature of a changing system. Good management keeps the model connected to that system, even when reality stops supporting the preferred story.
29. Leave behind a small operating record that another person can use
An improvement is fragile when it survives only in the memory of the people who made it. Farah did not want the next coordinator to inherit a new set of rituals without understanding why they existed. The project needed a compact operating record that connected the current policy to the evidence and decisions behind it. It did not need a second, longer version of every existing project document.
The record began with the objective and boundary. It named the unit of accepted output, the starting event, the receiving condition and the queue outside the active workflow. These definitions made the measures reproducible. A successor could tell whether a reported improvement concerned internal cycle time, customer lead time, local review output or operationally accepted bundles. Without those distinctions, even accurate data could be interpreted incorrectly.
Next came the current constraint hypothesis. It named the suspected restriction, the supporting observation and the conditions under which the hypothesis applied. For the fictional rollout, the record distinguished complete review-ready work from incomplete submissions and documented the expected downstream acceptance limit. It also stated what would count against the hypothesis, such as available review time remaining unused while complete items waited elsewhere.
The intervention record described what actually changed. It did not say merely “Kanban introduced” or “process streamlined.” It stated that complete evidence packets could transfer individually, that the ready queue required stable version references, and that active-work admission followed a trial limit with explicit exceptions. The reader could identify the operational differences and reproduce them without guessing what the label meant.
| Field in the proposed operating record | Example of useful content |
|---|---|
| Objective | Increase accepted, operable bundles without weakening required review |
| Unit and boundaries | Bundle identity; admission event; operational acceptance condition |
| Current hypothesis | Ready-review delay is partly driven by incomplete packets and batch arrival |
| Evidence | Item histories, missing-input categories and available review-time record |
| Intervention | Complete packets transfer individually; unchanged substantive criteria |
| Decision authority | Named owner for workflow policy; separate owners for release and risk decisions |
| Measures | Complete-submission wait, return reasons, active age and final acceptance |
| Guardrails | No hidden blocked work, no changed acceptance meaning, visible outer queue |
| Review trigger | Material change in mix, capacity, requirements or downstream readiness |
| Current conclusion | Observed result, plausible explanation and remaining uncertainty stated separately |
The record should identify an owner for continuing observation. A project can close while the service continues to change. Someone must notice when support demand rises, a supplier alters an interface, or the work mix no longer resembles the sample that informed the limit. Ownership does not require permanent daily reporting. It requires a route by which meaningful new evidence reaches the person capable of acting on it.
It should also preserve superseded decisions. A previous WIP limit or transfer policy may no longer apply, but the reason it changed can be valuable. Erasing the old rule loses the learning. Leaving the old rule beside the new one without a clear status creates ambiguity. Retain history while making the current authorised arrangement unmistakable, consistent with the configuration discipline already discussed.
A useful handover includes a difficult example, not only the normal procedure. Show how the team handled a missing evidence packet, an urgent exception or a conflict between local throughput and a project milestone. The example reveals the judgement behind the rule. It helps the successor recognise when to apply the standard path and when to escalate rather than improvise.
The Lessons Learned and Knowledge Management article owns the wider process of turning experience into organisational capability. The contribution here is specific: leave a record that allows the next team to understand the flow boundary, the constraint hypothesis and the evidence that justified the intervention. A lesson becomes more useful when it can be found at the next relevant decision.
This is also a test of whether the improvement was real. Could another competent person explain the mechanism without repeating a slogan? Could they reproduce the key measures? Could they tell which authority must approve an exception? Could they identify the next warning sign? When those answers are available, the organisation has gained more than a temporary reduction in a queue. It has gained a small, inspectable capability for managing work under changing conditions.
30. The meeting at which nobody asks everyone to work faster
In the fictional case’s closing review, the twenty-four commissioned bundles were accounted for. Twenty-three had reached their defined operational acceptance. One had been withdrawn through an authorised scope decision because its report no longer served the intended operating purpose. The withdrawal was not counted as a completion. The final record showed both the delivered state and the decision not to carry an unnecessary feature into maintenance.
The story does not establish an empirical effect size for a method. It is an explanatory case constructed to show how different mechanisms can interact. The team improved preparation, changed transfer timing, clarified decisions and prepared operations earlier. Those changes were not identical interventions, and the narrative does not pretend that one of them alone caused every improvement. Its value is the chain of reasoning it makes visible.
At the final meeting, Leena no longer had to defend every queue entry as though it were a personal failure. The ready-review queue contained work that was actually ready. Incomplete packets remained visible with their producers. Decisions outside her authority had named owners. The work still contained difficult judgement, but the surrounding system spent less of her attention on discovering what was missing before judgement could begin.
Tomas could see why beginning another configuration was not always the best use of the next hour. Sometimes that hour was better spent correcting a shared interface description or helping a nearly finished bundle reach a usable state. His contribution had not become less technical. It had become more connected to the point at which the organisation received the benefit of the technical work.
Nia’s role had changed too. Operations was no longer the place that received whatever the project declared finished. It had helped define the finish, identify the required support conditions and prepare for the transition. The project could distinguish technical readiness from the ability to sustain the service. That distinction prevented a faster delivery pipeline from becoming an unsupported operational burden.
Elliot could see the cost of admitting more work. An exception was still possible, but it now came with a visible consequence for existing commitments. The decision was not hidden in a queue that grew while every local team reported green. He could change scope, sequence, capacity or timing with a clearer account of what the choice would mean. The admission policy had made authority more explicit rather than replacing it with a mechanical rule.
For Farah, the lasting improvement was a different conversation. The team could ask what was ready, what was blocked, what the receiver needed, which capability was scarce, and what evidence would show that the next intervention helped. It could distinguish an actual capacity shortfall from a missing decision. It could recognise that a good local improvement might move the constraint rather than remove every limit. It could keep unfinished and withdrawn work visible without treating either as an embarrassment to be filtered out.
That is the practical meaning of restoring flow. It is not a world without limits. Every project has finite time, attention, capability and authority. It is a world in which the limits can be seen clearly enough that effort is directed toward the next useful completion rather than dispersed across an expanding collection of promises.
The reader can begin with one item. Find the last meaningful state it reached. Identify the next state it must reach. Ask what condition prevents the transition and who can change that condition. Then test whether the same restriction recurs across enough worthwhile work to limit the system. The first answer may be incomplete. Preserve that uncertainty, improve the evidence and choose a proportionate next action.
The mathematics provides discipline. Capacity constrains possible output. Admissions and departures reconcile unfinished work. Average inventory, throughput and flow time must be interpreted within compatible boundaries. Batching and sequence can alter elapsed time without changing direct effort. Rework consumes the same scarce capability again. Shared resources and mixed work can make several constraints active at once. None of those ideas removes the need for judgement; each gives judgement a firmer structure.
The ethical discipline is equally important. Do not improve the number by weakening the finish. Do not call a required reviewer the problem simply because that person is preventing unsupported work from proceeding. Do not hide waiting outside the chosen boundary. Do not optimise away the difficult cases an institution exists to serve. And do not use uncertainty as a reason to avoid decisions that can be made responsibly with the evidence available.
A useful project-management library should leave its reader with more than names for techniques. It should make the next real situation more intelligible. After following this argument, a queue should look less like a pile of inconvenient tasks and more like a set of relationships: demand, readiness, capability, sequence, authority, evidence and consequence. Those relationships can be investigated. Some can be changed. Some must be respected.
The best next move is not the one that makes the greatest number of people look busy. It is the one that makes a worthwhile completion possible sooner, without losing the conditions that make it worthwhile.
Sources and boundaries
The continuing rollout story, all named characters, the numerical datasets, the diagnostic exercises and the proposed operating practices are original teaching material. They are not reports of an actual eduKate project, measured staff performance or verified customer outcomes. The calculations establish results only within their stated assumptions. They do not establish a universal productivity improvement, a forecast for an actual project or a substitute for specialist safety, legal, security or financial judgement.
The sources below were consulted on 15 September 2026. Publication dates and the scope of access are distinguished from that consultation date. The article selectively explains published concepts, then develops its own cases and deductions; it does not reproduce a professional standard or claim certification by any cited organisation. The original Little paper was consulted through its published abstract, and the GAO guide through its official overview, not through a claimed full-text audit.
1. Atlassian — Project bottlenecks
Read the vendor’s project-bottleneck overview. Used for the introductory workflow meaning of a bottleneck. The article does not infer that every visible queue identifies the system constraint, or that one bottleneck must remain permanent.
2. The Kanban Guide — May 2025 edition
Read The Kanban Guide. Used for the definitions of work in progress, throughput, work-item age and cycle time, and the importance of an explicitly defined workflow. The case’s admission rules and trial limits are teaching choices, not prescribed numbers from the guide.
3. Theory of Constraints Institute — Five Focusing Steps
Read the Five Focusing Steps explanation. Used for the sequence of identifying a constraint, improving its use, coordinating surrounding work, increasing capability where justified and reassessing. No claimed percentage of spare capacity or guaranteed improvement is adopted from this source.
4. John D. C. Little — A Proof for the Queuing Formula: L = λW
Read the publisher’s abstract. Published in Operations Research, volume 9, issue 3, pages 383–387, in 1961. The article identifies the average relationship and its need for appropriate conditions. The empty-to-empty item-day demonstration, its boundary comparison and all numerical values are independently worked teaching examples, not data from Little’s paper.
5. DORA — Work in process limits
Read the DORA capability guidance. Used for the software-delivery practice of limiting work in progress. This article separately examines the risks of starvation, hidden upstream waiting and inappropriate transfer of a software practice into other settings.
6. DORA — Working in small batches
Read the small-batch capability guidance. Used for the practical role of smaller batches in software delivery. The six-package comparison is an original deterministic schedule, with zero transfer overhead assumed; its dates are not measured DORA results.
7. U.S. Government Accountability Office — Schedule Assessment Guide
Read the official overview of GAO-16-89G. Published on 22 December 2015. Used to support the importance of a credible integrated schedule and the assessment of change. The shared-reviewer example is original, and this edition does not claim that the complete guide was audited for the article.
8. NASA Systems Engineering Handbook — Interface Management
Read section 6.3, Interface Management. Used for the discipline of defining and controlling relationships between separately owned components. The ordinary project examples are proportionate applications, not a claim that every organisation should adopt aerospace governance.
9. NASA Systems Engineering Handbook — Configuration Management
Read section 6.5, Configuration Management. Used for stable configuration identity, controlled changes and consistency between an actual product and its defining information. The publishing and learning-service applications are this article’s own treatment.
10. NIST — AI Risk Management Framework overview
Read the official AI Risk Management Framework overview. Used as a primary reference for considering AI risk across an intended use and its lifecycle. The manual-versus-assisted review calculation is hypothetical, not a NIST benchmark or a claim about any particular AI product.
Continue the Project Management series
Return to What Is Project Management? for the broad subject, or follow How Project Management Works for the whole delivery system. Read Project Configuration Management for the preceding article’s distinct question: how to preserve the identity of the work being built, tested and released. The links inside individual chapters lead to the existing owners of scheduling, dependencies, resources, risk, benefits and organisational learning.