When projects are late, the usual response is to push harder. Add people. Schedule more meetings. Escalate tasks. Ask everyone to move faster.
In Mastering Flow, the authors argue that this often treats the wrong problem. Most project environments are not slow because people don't work enough or work too slowly. They are slow because the organization has started more work than it can finish.
Resources keep switching between priorities, experts become bottlenecks, and tasks begin before the elements needed to complete the work are available.
The book's central suggestion is to optimize the system for flow, focusing on finishing, not starting.
This sounds obvious, yet many organizations reward the opposite. A large portfolio of open projects creates the appearance of ambition. Keeping everyone busy looks efficient. Starting a project early feels safer than waiting. But in practice, these practices increase work in progress, stretching cycle times and making delivery less reliable.
The authors suggest to treat speed as a property of the whole system. The objective is to identify and solve chokepoints and practices that prevent valuable work from moving through the org without stopping.
Stop low-value work before trying to accelerate
Project portfolios often contains initiatives that sound reasonable on their own but add little direct value. The problem is not so much the time spent on those projects, it's that low-value initiatives compete for the same experts, management attention, and decision-making capacity needed by higher-value work.
Thus, spreading resources across more projects slows everyhting down. Even the projects that matter most finish late or with reduced scope because the organization is trying to advance too much at once.
The authors recommend to triage projects based on four dimensions:
- Throughput: Will the project increase the rate at which the organization generates value?
- Quality: Will it materially improve what customers receive?
- Operating expense: Will it produce a real reduction in spending?
- Investment or inventory: Will it reduce the money tied up in the system?
The distinction between theoretical and real value matters: automating a process may save employee hours, for example, but it does not reduce operating expenses unless overtime, hiring, or another actual cost goes down (or productivity increases).
The point of triaging is to stop enough low-value work so that selected projects receive the resources and attention they need.
Limit work in progress
Once the right projects have been selected, the next obstacle is bad multitasking: people switching between tasks and projects before finishing them.
Prioritization alone does not solve this. In overloaded orgs, priorities change constantly. Each escalation pulls someone away from work already in progress. Half-finished tasks accumulate, key people are requested everywhere, and the growing backlog produces even more urgency.
The practical response is to limit work in progress. As a general rule, the book recommends that a person should have no more than one active task. If the task cannot move forward, it should be visibly placed on hold while the team works to remove the blocker. Starting another task may keep the person busy, but it hides the actual flow problem.
At portfolio level, the same logic can require temporarily freezing a substantial share of active projects. Resources can then move to the projects or phases closest to completion until the organization reaches a more stable, low-WIP state.
This may leave some people idle for short periods, which is uncomfortable in orgs that equate busy-work with performance. But keeping every resource busy is a local optimum. The system objective is to complete valuable work quickly and reliably, not to keep people busy.
A WIP board helps keeping work visible: work waiting to start, work in progress, work on hold, and completed work. A short daily meeting can then focus on flow rather than status reporting: what is blocked, what is waiting, and what must happen to finish the current work in progress?
Protect complex work from small interruptions
Not all work behaves in the same way. Complex tasks need sustained concentration. Small requests may be quick individually but arrive unpredictably and often feel urgent. When the same people handle both, each type of work damages the other.
Small jobs wait behind larger ones, creating pressure and escalations. Large jobs are interrupted repeatedly, which extends their duration and increases the risk of mistakes.
The book proposes separating these streams either by resource or by time. Different people can handle high-load and low-load work, or the same people can protect defined periods for complex work and process smaller requests during specific windows.
The exact method matters less than the boundary. Every incoming request cannot be allowed to interrupt work the organization has already decided is important. Informal channels also need to respect the separation; otherwise direct messages and side requests quietly recreate the old system.
Do not start without the full kit
Starting early only helps when the work can continue.
Projects often begin with incomplete requirements, missing inputs, unresolved decisions, or no access to the right expert. The task starts, stops, waits, and eventually returns for rework when better information appears. The early start has increased work in progress without bringing the completion date forward.
The authors call the alternative the full-kit approach. Before a project or phase crosses an agreed gate, the team checks that everything required to execute it is available. Depending on the work, the kit may include approved requirements, data, designs, decisions, people, materials, and system access.
This doesn't mean that the project needs to wait until every uncertainty disappears. Rather, the shift is from starting as soon as possible to ensuring the work can finish without stopping.
Use experts to improve the system
Experts are often the scarcest resource in a project environment. As the portfolio expands, they are pulled into more reviews, exceptions, and emergencies. The org responds by relying on them even more, which makes the bottleneck worse.
One way out is to use expert knowledge to standardize repeatable work and train other people. Simplifying the range of work also helps. The book uses Gordon Ramsay's recurring decision to reduce restaurant menus: fewer variants make execution and quality easier to control.
Moreover, cross-training allows more people to handle routine issues and urgent work. This helps develop future experts, instead of operating permanently at the limit.
Often, the expert's highest-value contribution is not to help on the task per se but rather helping refine the system so fewer tasks need expert intervention.
Give the system a drumbeat
When every team chooses its next task according to local priorities, the organization becomes desynchronized. Each choice may look sensible to the team making it but the whole system actually slows down.
Borrowing from the Theory of Constraints, the authors suggest the idea of a drum: the mechanism that determines how much work enters the system and the order in which it moves. The drum might be a scarce expert, a constrained resource, a portfolio priority, or the project plan itself.
For a single project, the drum is closely related to the critical chain: the longest sequence of dependent activities after accounting for resource constraints and technical dependencies. This reduces the project to a smaller set of critical tasks that deserve disproportionate attention.
The project plan should remain simple enough to guide decisions. An extremely detailed plan can hide the constraint beneath hundreds of tasks.
Also, high-risk work should also be prioritized to move forward early. Teams naturally prefer low-risk tasks because they create visible progress, but postponing uncertain, high-impact work often creates late surprises and costly iterations.
Protect the deadline with a shared buffer
Task estimates usually contain hidden safety time. When every task protects itself, that safety is easily lost as wasted time. Work starts late, expands to fill the estimate, or fails to compensate for delays elsewhere.
Critical Chain Project Management removes much of that by consolidating safety into a project buffer. Progress can then be judged by comparing how much of the critical chain has been completed with how much of the buffer has been consumed.
The book suggests a traffic-light system. The project remains green while buffer consumption is within the first third, moves to yellow after one third, and turns red after two thirds. The colour is tied to the relationship between actual progress and the protection remaining, rather than being a subjective status chosen by the project manager.
Then, the priority for management is whatever threatens the critical chain and consumes the shared buffer.
Ask what the work is waiting for
The book's most useful diagnostic question may also be its simplest: What is the work waiting for?
Record the answers consistently. Missing decisions, unavailable experts, unclear requirements, reviews, data, and approvals will start to reveal the recurring points where the system breaks down.
This is a better question than asking who is late. It shifts the conversation from blame to flow and turns daily delays into evidence for improving the system.
How to apply the book to a slow project
- Define the value. State what the project must change in throughput, quality, operating expense, or investment.
- Cut the portfolio. Stop or freeze low-value work competing for the same people and attention.
- Limit active work. Allow only one active task where possible and make blocked work visible.
- Protect focus. Separate complex and interrupt-driven work by resource or by time.
- Enforce the full kit. Do not until the inputs, decisions, and resources needed to finish it are ready.
- Set the drum and buffer. Let the constraint determine the work sequence, then protect the deadline with shared safety rather than padded individual tasks.
- Learn from waiting. Track why work stops and fix the causes that recur.
The main pattern running through these steps is restraint.
Start fewer projects. Release fewer tasks. Interrupt people less. Put fewer items on the menu. Keep the plan focused on the small number of activities that determine delivery.
A slow org rarely needs more urgency. It needs fewer competing commitments and a clearer path for the most valuable work to keep moving until it is finished.