Phantom Capacity: Why Your Plans Are Built on Hours That Do Not Exist

Ask your organisation how much capacity its most constrained team has next week, and a number comes back with impressive speed. Four engineers, five days each, twenty engineer-days. Somebody sensible applies a factor and calls it sixteen. That number then becomes, unexamined, the foundation of everything built on top of it: what the plans assume, what the board approves, what the sales team promises, what the annual portfolio is sized against. It is the most load-bearing number in the whole system.

It is also, in most organisations, wrong by a margin large enough to explain nearly everything that goes wrong afterwards. Not wrong by five percent. Wrong by something closer to half. And it is wrong in a specific, structural, entirely predictable direction, which means it can be found and fixed. I want to give the gap a name, because a thing without a name cannot be managed: phantom capacity, the hours your plan counts and your constraint does not have.

The hours that are counted and are not there

Nominal capacity is a headcount multiplied by a calendar. It is arithmetic performed on an org chart. Real capacity is what is left of that calendar after everything else that has a legitimate claim on the same people has taken its share, and the list of claims is longer than any plan admits.

Some of it is obvious once written down, and still routinely omitted: annual leave, public holidays, sickness. Twenty-five days of leave and eight bank holidays is thirty-three days out of roughly two hundred and sixty, which is nearly thirteen percent of the year gone before anyone has done anything. Some of it is the ordinary overhead of being employed: the all-hands, the appraisal cycle, the mandatory training, the interview panels, the audit response somebody has to write.

But the largest share, and the share that never appears anywhere at all, is unplanned operational demand. The live-service incident. The escalation from a customer who has found something. The warranty period on the thing the same team shipped last quarter, which was scheduled as zero and is running at a day a week. The design review for another team's work. The "have you got five minutes" that is never five minutes. None of this is on a plan. All of it is real, all of it is legitimate, and all of it comes out of the same finite week.

The defining property of this category is not that it is large. It is that it is invisible to the instrument you use to plan. A project's work is estimated, sequenced and drawn as a bar with a length. Unplanned operational demand is none of those things. It has no bar, no estimate and no owner in the planning system. So when a capacity calculation is performed, the phantom hours are not deducted, because there is nothing on the page to deduct. They are not forgotten so much as structurally unrepresentable.

Phantom draw is worst exactly where it is most expensive

Here is the part that makes this an economics problem rather than an administrative one, and it is the thing most capacity models get precisely backwards.

You might assume phantom draw is spread more or less evenly, a general tax on everybody, something an organisation-wide factor could reasonably approximate. It is not. It concentrates, and it concentrates on your constraint.

Think about why a resource becomes the constraint in the first place. It is the scarcest skill, held by the fewest people, that the largest number of things need. Now consider who gets pulled into a major incident at two in the morning: the person who understands the system best. Who is asked to review another team's architecture, sit on the hiring panel, answer the auditor, brief the regulator, mentor the new starter, take the escalation. The same person. The very scarcity that makes someone the constraint for project work makes them the default answer for every unplanned demand in the organisation. These are not two different facts. They are one fact viewed from two directions.

So the error in your capacity number is not noise scattered evenly across the org chart. It is systematically largest on the single resource whose capacity sets the pace of the entire portfolio, and smallest on the resources with slack, where it would not have mattered anyway. An organisation-wide productivity factor is therefore not a rough approximation of the truth. It is a number that is too generous exactly where being wrong is fatal, and too harsh everywhere it is harmless.

And the hours do not subtract cleanly. An hour of incident work does not cost the constraint one hour of project time; it costs that hour plus the reacquisition of everything they had in their head about the project work it interrupted, which is the switching cost of multitasking arriving through the back door. Phantom draw is not subtracted from your capacity. It is subtracted with a multiplier.

Why the shortfall is never diagnosed as a capacity problem

If the gap is this large, why does an intelligent organisation not simply notice? Because the way the gap resolves itself guarantees a misdiagnosis.

When unplanned work and project work collide for the same hour, the contest is not fair. Unplanned work is urgent, it is small, and it arrives attached to a person's name rather than a plan's. Project work is patient; its date is weeks away and nobody is standing over it this afternoon. So the collision is settled the same way every time, and it is settled correctly by every local standard: you fix the outage. Which means the entire deficit lands on project work with perfect reliability. Not most of it. All of it.

That single asymmetry is what makes the problem self-concealing. Because the shortfall only ever surfaces as project slippage, project slippage is the only symptom anyone ever sees. Nobody ever reports "we were overloaded by seven engineer-days a week"; there is no field for that. They report that the integration work took nine weeks against an estimate of five. And the visible artefact in that sentence, the one thing written down in advance and available to be blamed, is the estimate.

So the organisation reaches the wrong conclusion with total sincerity: our people cannot estimate. And it applies the corresponding remedy, which is to pad the estimates. This adds not one hour of capacity. It makes every plan longer while leaving the arithmetic that caused the problem completely untouched, and the padding then gets consumed by the behaviours that always consume it. The next round slips too, which is taken as proof that the padding was insufficient. An estimating remedy is applied to a capacity disease, year after year, and the fact that it never works is read as evidence that it has not yet been applied hard enough.

There is usually a second mechanism sealing the diagnosis shut. The incident and support hours are booked to an operational cost centre, because that is what they are. The same person's project hours are booked to project codes. Nobody adds the two together, because they live in different reports owned by different people. The finance view of that engineer and the plan view of that engineer are, in effect, two different employees, and no process in the organisation is responsible for noticing that they are one person with one week.

A worked example

Numbers make this concrete. They are illustrative rather than exact, but the shape is what matters and the shape is very common.

Your constraint is a team of four senior integration engineers. Nominal capacity: 20 engineer-days a week. The portfolio plans against it.

Now account honestly for the week. Leave, holidays and sickness average about 2.5 days. The live-service rota and the escalations that come with it take about 3 days. Advisory draw, design reviews for other teams, interview panels, the audit response, the questions that are never five minutes, takes about 2.5 days. Warranty and hypercare on what they shipped last quarter, planned as zero, runs at about 1 day.

That is nine days gone. Capacity genuinely available for project work: 11 engineer-days a week, not twenty. The planners, being experienced, had already applied an eighty percent factor and were working to sixteen. They were wrong by five days a week, and the factor gave them the confidence not to check.

Against that eleven, six projects have integration work in their plans. Their combined claim on the team, once you add up what each project's schedule assumes it will get, is 18 engineer-days a week. Nobody ever performed that addition, because no single document contains all six claims.

Eighteen demanded against eleven available is a loading of 164 percent. And this is where the arithmetic turns nasty, because loading a resource past a hundred percent does not make it proportionally late. It makes the queue in front of it grow without limit, which is the mechanism behind The Utilisation Trap. Every week, seven engineer-days of committed work arrives that cannot be done and does not go away.

After one quarter, thirteen weeks, the pile in front of that team is about ninety engineer-days, which at their real capacity is over eight weeks of work. The average piece of integration work now waits roughly two months before anyone starts it. That wait is on nobody's plan, and every one of the six projects has silently acquired it. If those six carry a combined cost of delay of £22,000 a week, the queue represents something like £180,000 of value pushed into the future. Note that this is the position after one quarter, not a one-off charge. While the loading stays above a hundred percent, the number keeps climbing.

Now consider the two ways out, because the comparison is the most useful thing in this example. You could hire a fifth senior integration engineer. That takes perhaps four months to find and onboard, costs around £95,000 a year fully loaded, and delivers about 2.75 project-available days a week, because the new engineer inherits exactly the same phantom draw as everyone else. Or you could move the live-service rota to a second-line team, which recovers 3 days a week, costs a fraction of a hire, and lands in weeks rather than quarters.

The rota change buys more real capacity than the hire does. That is worth sitting with: the cheapest capacity available to most organisations is the capacity they already own and are giving away for free. But notice too that even after recovering those three days, demand of eighteen against capacity of fourteen is still a loading of 129 percent, and the queue still grows. Recovering phantom hours is necessary and it is not sufficient. The number that must finally move is the commitment, and no amount of clever capacity recovery will substitute for the decision to commit less.

Why single-project management is structurally blind to this

Every actor in the story above behaved reasonably.

Each of the six project managers built a plan that assumed a reasonable share of the integration team. None of them assumed anything greedy. But each planned in isolation, against a capacity figure they had no way to validate, and nobody held the sum. The addition that would have revealed the impossibility was not anyone's job, because in a single-project frame there is no artefact on which six projects' claims on one team appear together. The overload does not exist in any document. It exists only in the engineers' calendars, where no planning process ever looks.

And the phantom draw belongs to no project at all, which is the deeper problem. Support is not project work. The audit response is not project work. Because they belong to no project, they appear on no project's plan, and therefore are deducted from no project's assumption. A frame that tracks work project by project can only see demand that has been assigned to a project. It is not that it measures the phantom draw badly. It has no category in which such a thing could be recorded.

This is the Project Illusion in one of its purest forms. Six plans, each defensible on its own terms, each reviewed and approved, summing to something arithmetically impossible, and the impossibility invisible to every governance process the organisation runs, because each process examines one project at a time and the contradiction only exists in the sum. The projects then fail one at a time, are investigated one at a time, and each investigation reaches a local conclusion about estimating or scope, while the actual cause sits between them all, uncounted, in a team's week.

What to do instead

The remedy is not a heavier planning process. It is a small number of honest measurements applied in the right place.

1. Measure the availability of the constraint, and only the constraint. Do not launch an organisation-wide time-recording exercise; it will be resented, gamed and abandoned. Take one team, the one you believe sets your pace, and for four weeks record honestly where its hours actually went, with unplanned operational work as its own category. Four weeks on one team will tell you more than a year of universal timesheets, and it is the only number in the building that changes your portfolio's arithmetic.

2. Plan against demonstrated capacity, not nominal capacity. You do not need a theory of how many days the team should have. You have evidence of how many days of project work it actually completed last quarter. Use that. Demonstrated throughput has every deduction already baked into it, honestly, including the ones nobody would have thought to list.

3. Give unplanned work a named allocation instead of letting it preempt. If support genuinely takes three days a week, put three days a week on the board as support. This changes nothing about the work and everything about the visibility: an invisible draw is something you suffer, whereas a named allocation is something you can debate, price and decide to move. You cannot relocate a cost that does not appear anywhere.

4. Move phantom draw off the constraint before you buy capacity. Every hour of the constraint's week spent on something a non-constraint resource could have done is throughput given away at full price, the mirror image of the non-constraint trap. Second-line the rota. Route advisory requests to a named deputy. Take the constraint off the interview panel. This is subordination in its most literal form, and it is almost always faster and cheaper than recruitment, which is the reflex it should replace.

5. Cut committed demand until it fits the real number. This is the one that actually stops the queue growing, and the only one that requires courage. It means starting fewer things at once, and it means pricing each new commitment against the constraint's real availability rather than its nominal one, which is what the price of yes is for. When you must choose which claims survive the cut, rank them by value per constrained resource hour, not by size or by who asked loudest.

6. Re-baseline the commitments you have already made, once and deliberately. Every date currently promised was calculated from the nominal number and is therefore wrong. You will find this out either way. The choice is between one honest conversation now, with a corrected capacity figure and a defensible reordering, or six separate apologies over the next two quarters, each of which looks like a delivery failure rather than an arithmetic correction. Holding the real capacity number and forcing that single conversation is precisely the job of a Value Management Office.

The objection you are already forming

"We know all this. That is exactly why we do not plan at a hundred percent. We apply a productivity factor, we plan at eighty, everyone does. You have described standard practice and dressed it up as a discovery."

The factor is real and it is not enough, for four reasons that compound.

It is folklore rather than measurement. Eighty percent is a number that gets inherited, not derived; almost nobody can tell you which study, or which quarter of their own data, produced it. In the example above, eighty percent of twenty is sixteen and the truth was eleven. The factor did not merely fail to close the gap, it made things worse, by supplying enough apparent rigour that nobody felt the need to check.

It is applied uniformly, and the problem is not uniform. As the section above argued, phantom draw concentrates on the constraint by construction. An average across the organisation is comforting and irrelevant; the only availability figure that governs your delivery rate is the constraint's, and that is the one an average flatters most.

It is applied to estimates rather than to commitments. Padding every task by twenty percent lengthens each plan. It does nothing whatsoever to prevent six plans from collectively committing eighteen days a week to a team with eleven, because that addition happens at the portfolio level and the factor is applied at the task level. The arithmetic that destroys you lives one layer above where the correction is being made.

And it is a mean applied to demand that is anything but average. Suppose eighty percent were the correct long-run figure. Unplanned work does not arrive at a steady drip; it arrives in bursts, and a major incident takes not twenty percent of the week but all of it. At a loading comfortably below capacity, a bad week is absorbed and forgotten. At a loading near or above capacity, a bad week is not absorbed at all, it is converted into a queue that never fully drains before the next one arrives. Variability and high loading are separately survivable and jointly ruinous, which is why the buffer burn on projects behind an overloaded constraint accelerates rather than accumulating steadily.

None of which is an argument against productivity factors. It is an argument that a factor is a substitute for a measurement, and you are running the most important number in your portfolio on a substitute. The commitment your organisation made this quarter rests on a figure that no one has ever validated against a single real week of a single real team. That validation costs four weeks of honest recording on one team. Until someone does it, every plan in the building is a confident statement about hours that do not exist.

If this changed how you read your own capacity numbers, the two ideas underneath it are worth reading next: why loading a resource towards a hundred percent slows everything down, in The Utilisation Trap, and how to identify which resource's number actually matters, in How to Find the One Resource That Sets Your Delivery Speed.