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 impact on four dimensions:
- Throughput
- Quality
- Operating expenses
- Investment or inventory
Ex-ante impact estimation matters: for example, automating a process may save employee hours, but it will not reduce operating expenses unless overtime, hiring, or another actual cost goes down.
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.
In overloaded orgs, priorities change constantly. Each escalation pulls someone away from work already in progress. Half-finished tasks accumulate, key people are requested, and the growing backlog produces even more requests for urgency.
The 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 placed on hold while the team works to remove the blocker.
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 state.
This may leave some people idle for short periods, which is seen as inefficient in orgs that equate busy-work with performance. However, keeping every resource busy is a local optimum, it backfires. The system objective is to complete valuable work quickly and reliably, not to keep people busy.
A short daily meeting can then focus on flow rather than status reporting: evaluate what is blocked, what is waiting, and what must happen to finish the current work in progress.
Protect complex work from small interruptions
Task segregation is another necessity to improve flow. 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.
Moreover, since small jobs wait behind larger ones, they create pressure and escalations. Large jobs are interrupted repeatedly, which extends project duration and increases the risk of mistakes.
The authors suggest 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 DMs and side requests will quietly recreate the old system.
Do not start without a full kit
Starting early only helps if the work can continue.
Projects often begin with incomplete requirements, missing inputs, unresolved decisions, or no access to the expert. The task starts, stops, waits, and eventually returns for rework. The early start has increased WIP 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.
To address this:
1) Use expert knowledge to standardize repeatable work. 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.
2) Simplify the range of work also helps (as an example, the book refers to Gordon Ramsay's decision to reduce restaurant menus: fewer variants make execution and quality easier to control).
3) Train other people: cross-training allows more people to handle routine issues and urgent work. This helps develop future experts, instead of operating permanently at the limit.
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 individual or team making it, but the whole system actually slows down.
Borrowing from the Theory of Constraints, the authors suggest the idea of a drum: a mechanism that determines how much work enters the system and the order in which it moves. The drum can 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. This is the set of critical tasks that deserves disproportionate attention.
Also, high-risk work should 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.
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 (due to Parkinson's law), or fails to compensate for delays elsewhere.
The authors suggest to remove 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 vs. 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 priority for management is to address whatever threatens progress on the critical chain and consumes the buffer.
To summarize
What is the work waiting for?
The book's most useful diagnostic question may also be its simplest: What is the work waiting for?
It is important to record the answers consistently: missing decisions, unavailable experts, unclear requirements, reviews, data, and approvals will reveal the recurring points where the system breaks down.
This is a better question than blaming who is late. It shifts the conversation from blame to flow, and turns daily delays into evidence for improving the system.
Getting started - how to apply the book
- Define the value of the project. 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 start the project 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 a shared safety buffer.
- Learn from tracking waiting time. Track why work stops and fix the recurring causes.