Resource smoothing is not enough when demand consistently exceeds capacity. It adjusts the timing and intensity of resource use within a fixed schedule, but it cannot create capacity that does not exist. When your team is carrying more work than it can realistically handle, smoothing redistributes the pressure without reducing it, and the underlying problem remains.
The distinction matters because many organisations apply resource smoothing as though it were a capacity solution, only to find that delivery still slips, specialists are still overloaded, and the portfolio still underperforms. What is actually needed is a different kind of decision: one about what to run, in what order, and at what cost to the organisation when the wrong things are prioritised.
This article works through the key questions practitioners ask when they hit that ceiling, from what smoothing can realistically fix, to how Flow Economics approaches the structural problem underneath.
What actually happens when demand consistently exceeds team capacity?
When demand consistently exceeds team capacity, work does not stop arriving. It queues. Projects start but cannot progress at the rate their plans assume, because the people those plans depend on are already committed elsewhere. The visible result is schedule slippage across multiple initiatives simultaneously, with each project manager reporting delays caused by resource unavailability rather than poor delivery.
The less visible result is more damaging. Every day a project waits for an overloaded specialist is a day its expected value is not being realised. If a product launch, a regulatory compliance milestone, or a revenue-generating system is sitting idle while its critical contributor works on something else, the organisation is paying a real economic cost. That cost rarely appears in any dashboard.
There is also a behavioural pattern that tends to emerge under sustained overload. Sponsors escalate. Priority decisions get made through negotiation and seniority rather than through any economic logic. The loudest voice determines which project gets the specialist this week, and the rest wait. This is not a governance failure in the conventional sense. It is what happens when the system has no mechanism for pricing the cost of delay and using that price to sequence work rationally.
What is resource smoothing and what can it realistically fix?
Resource smoothing is a scheduling technique that adjusts the timing of tasks within the float available in a project plan, so that resource demand stays within defined limits without extending the overall project end date. It works within the constraint of the existing schedule rather than changing it.
What smoothing can realistically fix is uneven demand within a project that has genuine schedule flexibility. If a project has tasks with float, and those tasks happen to demand the same resource at the same time, smoothing can spread that demand across the available window. The project finishes on time, and the resource is not asked to do two things at once.
What smoothing cannot fix is structural overcommitment. If the total demand across all active projects exceeds what the team can supply, there is no float to redistribute into. Smoothing a plan that assumes a specialist is available full-time when she is shared across four other projects does not change the arithmetic. It produces a tidier plan that still fails in practice.
Smoothing is a useful tool at the project level. Its limits become visible the moment you step back and look at the portfolio as a whole.
What's the difference between resource levelling and resource smoothing?
Resource levelling and resource smoothing are related techniques that solve different problems. Resource smoothing adjusts task timing within existing float to keep resource demand steady, without moving the project end date. Resource levelling removes overallocation by extending the schedule when necessary, accepting that the end date may shift in order to make the plan realistic.
The practical distinction is which constraint the technique treats as fixed. Smoothing treats the end date as fixed and works within it. Levelling treats the resource limit as fixed and adjusts the schedule to respect it. Both are legitimate approaches, and most project management tools offer both.
The more important distinction is what neither technique addresses. Both operate on a single project in isolation. Neither accounts for what happens when multiple projects compete for the same specialist. A levelled plan for Project Harbour and a levelled plan for Project Whitfield can each look perfectly rational on their own, while together they demand the same senior engineer for 160 hours in the same month. The conflict is invisible until it materialises as a delay, and by then both projects are already behind.
This is where the resource levelling vs resource smoothing question reaches its practical ceiling. The tools are sound. The frame is too narrow.
Why does resource smoothing stop working at the portfolio level?
Resource smoothing stops working at the portfolio level because it is designed for a single project with a defined schedule and known float. A portfolio is not one project. It is a set of projects competing for the same constrained people, and the interactions between those projects are where most of the value is lost.
Consider what happens when three projects, Harbour, Whitfield, and Calder, all depend on the same data architect. Each project manager has smoothed their own plan. Each plan looks achievable. But the combined demand on that architect across all three plans exceeds her available hours by a factor that no amount of internal float adjustment can resolve. Smoothing within each project has made the individual plans cleaner while leaving the portfolio-level conflict entirely untouched.
The deeper issue is that portfolio performance depends on sequencing decisions that project-level tools are not designed to make. Which project should get the constrained resource first? What does it cost the organisation for Project Calder to wait another three weeks while the architect finishes work on Harbour? These are economic questions, and answering them requires visibility across the whole portfolio, not just within each plan.
Most organisations do not have a mechanism for making those decisions explicitly. The order of work is decided by whoever escalates most effectively, which is a form of sequencing, but not an economic one.
What should organisations do when capacity cannot meet demand?
When capacity cannot meet demand, the organisation faces a sequencing decision, not a scheduling problem. The question is not how to fit everything in. The question is which work should go first, given that not everything can run concurrently at full speed.
There are three practical responses, each with different implications:
- Reduce active work in progress. Running fewer projects simultaneously allows the constrained resource to complete work faster and deliver value sooner. This is counterintuitive for organisations that equate starting projects with making progress, but starting less is often the fastest way to finish more.
- Sequence by the cost of delay. Not all projects cost the same amount per day of waiting. A project with a hard regulatory deadline or a revenue dependency has a higher cost of delay than one with flexible timing. Sequencing by that cost, rather than by sponsor seniority, directs the constrained resource to where it earns the most.
- Make the constraint explicit. Before any sequencing decision can be made rationally, the organisation needs to know which resource is the actual bottleneck. Without that visibility, decisions default to politics rather than economics.
None of these responses require new tools or a restructured PMO. They require a different way of framing the question: from "how do we deliver everything?" to "what is the right order, and what does the wrong order cost us?"
How do you identify which resource constraint is limiting portfolio throughput?
The resource constraint limiting portfolio throughput is the skill or role that appears most frequently on the critical path across multiple active projects. It is not simply the busiest person. It is the person whose availability determines when the most projects can move forward.
A practical way to identify it is to map which resources appear on the critical paths of the highest-value projects in the portfolio. The resource that shows up most often across those paths is the one whose schedule sets the pace for the whole system. This is the bottleneck in the Theory of Constraints sense: the constraint that governs throughput for the portfolio as a whole.
Once the constraint is identified, two things follow. First, the organisation can stop making scheduling decisions as though every resource were equally important. The constraint deserves disproportionate attention because every hour it loses to waiting, context-switching, or lower-value work is an hour of portfolio throughput that cannot be recovered. Second, the organisation can begin to price the sequencing decisions it makes about that constraint. Stephen Devaux's concept of drag cost, the economic cost imposed on a project by a task or resource sitting on the critical path, gives a way to quantify what it costs when the constrained resource is assigned to the wrong project first. That cost is not theoretical. It is the value the organisation fails to realise while it waits.
Identifying the constraint also changes the conversation about capacity. The question is no longer "do we have enough people?" in aggregate. It is "are we directing our scarcest skill to the work that earns the most, in the right order?" That is a more answerable question, and a more actionable one.
How Flow Economics approaches resource constraints in portfolios
Flow Economics is the framework that addresses exactly this layer: the shared resource system where competing project demands meet limited specialist capacity, and where the order of work determines the return on the whole portfolio.
Where resource smoothing and levelling operate within individual projects, Flow Economics operates across the portfolio as an economic system. It connects three things most organisations manage separately:
- Value, expressed as the cost of delay when a project waits for a constrained resource
- Flow, the rate at which work moves through the system when constraints are managed rather than ignored
- Constraints, the specific skills and roles that set the pace for portfolio throughput
The result is a sequencing logic grounded in economics rather than escalation. Projects are treated as investments competing for constrained capacity, and the order in which the constraint works is set by what each hour of that resource is worth, not by who argued loudest in the last steering meeting.
If you want to understand how this framework applies to your portfolio, the Flow Economics course walks through the full model, including a working simulator you can use to test sequencing decisions before making them in the real organisation. Modules 1 and 2 are free. If you would prefer to talk through your specific situation first, you can get in touch directly.