Turn shadow capacity into usable float: measurement rules, sample calculations and reservation policies for shared teams

Most PMOs think they have a capacity shortage. What they actually have is a visibility shortage. There's a gap between what a resourcing spreadsheet says a person is doing and what that person is actually available to do — and that gap, sitting invisible in the seams between projects, is what we're calling resource shadow capacity. In a PMO managing shared specialists, this hidden float can be surprisingly large. Left unmeasured, it either gets wasted or, worse, silently over-committed until three project managers all discover they were counting on the same database engineer for the same two weeks.

This post is narrow on purpose. It's not about demand management broadly, and it's not another allocation framework. It's about the math and the policy for turning the fuzzy, unaccounted-for slivers of a shared team's time into a float you can actually book against — safely.

Why shadow capacity forms in the first place

Shadow capacity isn't idle time in the obvious sense. Nobody's sitting around. It's the difference between booked and consumed.

1. 1
   Padding on individual allocations. A PM books a specialist at 100% "to be safe," but the work genuinely needs 65%. The other 35% never gets released back to the pool. Multiply that across eight PMs and you have a phantom shortage.
2. 2
   Rounding to whole people. Resourcing tools love allocating in full-time-equivalents. A task needing 0.4 of an integration engineer gets rounded up to "1 engineer, part-time," and the remainder disappears from view.
3. 3
   Buffer stacking. The PM adds contingency, the resource manager adds a buffer on top, and the delivery lead reserves "just in case" hours. Each layer is reasonable alone. Stacked, they lock up 20–30% of a person's calendar that will almost never be touched.
4. 4
   Ghost bookings. A project slips, but nobody unbooks the specialist. The allocation lingers for weeks after the work moved.

The core issue is that most capacity systems track commitments, not consumption. You can't recover float you can't see, and you can't see it if your only data point is what someone booked three months ago.

The measurement rules: making shadow capacity visible

Before any policy, you need clean numbers. Here are the measurement rules that actually hold up in practice.

Rule 1 — Measure at two layers: committed vs. consumed. For every shared resource, track allocated hours (what's booked) against actuals (what's logged or reasonably estimated as consumed). The delta, sustained over 3–4 weeks, is your candidate shadow capacity. A one-week gap is noise. A four-week trend is signal. This is the same logic behind designing low-noise early-warning triggers — you're smoothing to avoid reacting to a single quiet week.

Rule 2 — Define nominal capacity honestly. Don't start from 40 hours. A realistic weekly baseline for a shared specialist, after meetings, admin, PTO accrual and context-switching, is closer to 30–34 productive hours. Call this your nominal capacity. Every calculation downstream uses this number, not the theoretical full week.

Rule 3 — Separate structural float from incidental float. Structural float is predictable and repeats — someone consistently books 100% but consumes 70%. Incidental float is one-off, like a project that paused this month. Only structural float is safe to build policy around. Incidental float you handle case-by-case.

Rule 4 — Attribute float to a person, not a team. "The integration team has 15% spare" is useless. Fifteen percent spread across five people in unusable 40-minute slivers is not the same as one person with a genuinely open day. Shadow capacity is only usable if it's contiguous enough to actually book.

Sample calculation: usable float for one shared pool

Let's run numbers through a small pool — four data engineers shared across a mid-size portfolio.

Raw gap across the pool = 19 hours/week. That's the number a naive tool would report as "spare."

1. 1
   Drop incidental gaps and noise — Engineer B's 1-hour delta isn't worth tracking. Gone.
2. 2
   Keep only structural float — Engineers A and C show consistent, repeatable gaps. That's 18 hours.
3. 3
   Apply a reserve buffer (more on this below) — hold back 25%. Usable, bookable float = 18 × 0.75 ≈ 13.5 hours/week.

The honest answer isn't "19 hours free." It's roughly 13–14 hours of genuinely bookable float, concentrated in two named people. That's a number you can promise against without lying to a PM.

The mistake most teams make is booking the raw 19. They promise the full gap, the buffer they never set gets eaten by normal variance, and within a month the pool is over-committed again — except now everyone trusts the spreadsheet less.

Reserve buffers: how much to hold back, and why

The reserve buffer is the discipline that keeps float honest. It exists because consumption is variable, not because you're being conservative for its own sake.

The single-point specialist row matters most. If one person is the only one who can do a thing, their float should be booked cautiously regardless of how much appears available — because when they're out, there's no absorb. This connects directly to how you handle scarce skills in a broader capacity and demand management system; shadow-capacity recovery should never quietly erode the protection you've built around your rarest people.

Booking vs. reserving: the policy distinction that prevents collisions

Most PMOs never formalize this distinction, and it's where the double-booking chaos comes from. There's a real difference between booking shared time and reserving it. Treating them the same is the root cause of "wait, I thought she was mine that week."

1. 1
   Booking = a firm, committed claim. The hours are gone from the pool. Someone owns them.
2. 2
   Reserving = a soft, provisional hold. The hours are earmarked but can be released or challenged.

If your system only has one state — "allocated" — then a hopeful reservation and a hard commitment look identical, and PMs plan against both as if they're real.

A clean policy defines the states explicitly:

1. 1
   Available — in the pool, unclaimed.
2. 2
   Reserved (soft) — held for a specific project, expires if not confirmed by a set date.
3. 3
   Booked (firm) — committed and consumed against.
4. 4
   Buffer — not bookable by anyone without escalation.

“

Make reservation expiry automatic to recover ghost bookings quickly.

Two rules make this work. First, reservations expire — a soft hold that isn't converted to a booking within around 10 business days automatically releases back to Available. This alone recovers a surprising amount of ghost-booked float. Second, reservations don't win ties — when two projects want the same slot and one has a firm booking versus a soft reserve, the booking wins automatically with no meeting required. Contested reserves go to a quick priority call.

A workflow for running this in practice

Every Monday, the resource manager pulls committed-vs-consumed for each shared pool. Sustained gaps get flagged as structural. Structural float, minus the pool's reserve buffer, becomes the week's published usable float — a single number per named person.

The sequence from there is straightforward:

1. 1
   PMs requesting shared time submit against the published float only.
2. 2
   A request under the float gets a soft reservation with an expiry date attached.
3. 3
   If the PM confirms scope and dates before expiry, it converts to a firm booking and drops out of the float.
4. 4
   If they don't confirm, it releases automatically back to the pool.
5. 5
   Anything requesting more than the published float triggers an escalation — not a quiet override.

Visualized workflow:

The reason this beats ad-hoc requesting: nobody is negotiating against a made-up number. The float is derived from actual consumption, buffered honestly, and published openly. Single source of truth about what's genuinely claimable.

A short real scenario

A PMO at a roughly 400-person financial services firm ran six concurrent projects sharing a pool of five integration specialists. On paper the pool was "fully allocated" — every request got answered with "sorry, no capacity." Three separate initiatives were stalled waiting on integration work, and leadership was about to approve two contractor hires.

When they ran committed-vs-consumed over a month, the pool was consuming around 68% of what was booked. After stripping incidental gaps and applying a 30% reserve buffer (high interrupt load), they surfaced roughly 22–24 usable hours a week — a little over half an FTE hiding inside "full" allocations. They published it as named float, moved to soft-reserve-with-expiry, and unstuck two of the three stalled initiatives without adding headcount. The contractor hires got paused, saving somewhere in the $80k–$110k range over the following two quarters.

The more interesting outcome wasn't the money. The same PMs who'd sworn there was no capacity started trusting the pool again, because the published float actually held up when they relied on it.

When this is worth doing — and when it isn't

When it makes sense:

1. 1
   You share specialists across three or more projects and requests are constant.
2. 2
   You suspect over-booking but can't prove it.
3. 3
   You're being pushed to hire and want to check for hidden float first.

When it's a bad idea:

1. 1
   Your pool is one or two people with no substitutes — the overhead of the state machine outweighs the recoverable float, and buffers should dominate anyway.
2. 2
   You have no consumption data at all. Without actuals, every number here is a guess, and publishing guesses as "usable float" is worse than saying nothing.

Teams that won't enforce reservation expiry also shouldn't bother. If soft holds never release, you've just added a fourth buffer layer and made the shadow capacity problem worse than when you started.

The one thing to get right

Shadow capacity recovery lives or dies on one discipline: measuring what's consumed, not what's committed, and being honest about the buffer between the two.

Everything else — the states, the expiry rules, the escalation triggers — is just plumbing that protects that one measurement from wishful thinking.

Get the math honest and publish it openly, and the phantom shortage that had you queuing up contractor requisitions often turns out to be half a person you already had.