Capacity validation checks a plan against the people who actually exist, by name and by real availability, rather than against headcount or full-time equivalents on a spreadsheet. It is the step in the Focus practice that catches the same three specialists assigned to four concurrent workstreams, and it runs after the scope has been sliced and estimated, before a release plan is drawn. A plan that has not been validated this way is an intention with dates on it.
Why do FTE numbers fail?
Because a full-time equivalent is an accounting unit, not a person. It averages away the three things that actually determine whether a plan is deliverable: who specifically can do the work, what else that person is already committed to, and when they are available.
The failure is structural rather than careless. A resource plan that shows 4.0 FTE of back-end engineering available and 3.5 FTE required looks solvable. It stops looking solvable the moment you write the names down and discover that the 4.0 is made up of one person at 100 percent, two at 50 percent who are also the on-call rotation for a production system, and one at 100 percent who starts in six weeks and does not know the domain.
Two more errors hide inside the same number. Fungibility: FTE arithmetic assumes any unit of a skill can replace any other, which is untrue for the specialists who sit on the critical path of most initiatives. And fractional allocation: a person at 25 percent across four initiatives does not deliver a quarter of four things. They deliver less than that, because context switching has a cost, and because each of the four expects them at its own ceremonies.
How does capacity validation work?
Capacity validation works by resolving every estimate to named people and then subtracting what those people already owe to someone else.
The sequence is: estimates by workstream, then required skills by workstream, then named people against those skills, then each person's real availability over the planning horizon, then the comparison. The comparison is where the plan either survives or does not.
Real availability is the part that tends to get skipped. For each named person, subtract:
- Leave that is already booked, and a realistic allowance for the leave that is not booked yet.
- Support and on-call duties, including the recovery time after an incident week, which is not the same as the incident hours.
- Existing commitments to work already in flight, including initiatives that were approved in a previous cycle and never actually finished.
- Organizational overhead: line management, hiring, audits, mandatory training, and the meetings the organization requires regardless of project.
- Ramp-up time for anyone new to the domain or the codebase.
What remains is the capacity you can plan against. It is usually well under the headcount figure, and the gap between the two numbers is the single most useful thing capacity validation produces.
What does good capacity validation look like?
Every skill the plan needs resolves to a real name, specific enough to matter: not "engineering", but "someone who has worked on the settlement service". A line that resolves to "we will hire" or "contractor TBD" is treated as a risk, not a resource. Availability comes from people's actual calendars and commitments, confirmed by their managers, because a portfolio lead estimating someone else's availability produces the same fiction as the FTE sheet.
The clearest sign it is working is that it ends in a decision. A validation that finds a gap and produces no change to scope, dates, people, or other work has not finished.
What does it mean when a plan fails validation?
It usually means the ranking above the plan approved more than the organization can staff, and this is the most important thing to say plainly in the room. A failed validation is rarely a planning failure. The planner did not create the shortfall; they found it.
There are four honest responses, and only four:
- Cut scope. Return to MVP prioritization and take a smaller first slice. This is the fastest response and usually the right one.
- Extend the horizon. Keep the scope and move the dates, which is only honest if the date was not a real external constraint.
- Add the people. Legitimate, but it is slow, and it costs the existing team ramp-up time before it returns anything.
- Stop something else. The one that returns capacity immediately, and the one that requires a portfolio decision rather than a project decision. Deferring another initiative is what portfolio commitment is for.
The dishonest response is the fifth one: record the gap as a risk, keep the date, and hope. That is how a portfolio arrives at a quarter where every initiative is amber and no one can say which will finish.
A worked example: three workstreams, one integration engineer
Take a hypothetical initiative that came out of elaboration with three workstreams: a web form, a broker queue ingestion service, and a validation and routing service. The estimates totalled roughly 14 person-months over a 4 month window, against a department the spreadsheet showed as 6.0 FTE available. On paper it fit with room to spare.
Validation resolved the skill lines to names. Two of the three workstreams required the integration engineer who maintained the message broker, and she was the only person who had worked on it. Her calendar showed a 3 week compliance audit she was committed to, one week of booked leave, and a permanent 20 percent allocation to production support for the same broker.
Her available capacity over the window was close to 2 months, and the plan needed roughly 3.5 from her. The rest of the department was genuinely available and could not help, because the constraint was a system only one person knew.
The decision taken was a combination: broker queue ingestion moved to release 2, which removed about half her demand, and a second engineer was paired with her on the validation service for four weeks specifically to break the single point of knowledge. The release date held for a reduced first slice. The alternative, which the team had been about to accept, was a plan that would have failed in month three for a reason that was visible in week one.
Capacity validation vs resource allocation
Resource allocation assigns people to work. Capacity validation tests whether that assignment is possible. They run in opposite directions and answer different questions.
| Capacity validation | Resource allocation | |
|---|---|---|
| Question | Can this plan be staffed by real people? | Who is assigned to what? |
| Unit | Named person, real calendar | Role, FTE, or percentage |
| Direction | Tests a plan against supply | Distributes supply across demand |
| Typical output | A gap, and a decision about it | An allocation sheet |
| When it runs | Focus, before the release plan | Continuously, often in a PMO tool |
| Failure mode | None, if you act on the result | Allocations that sum to 100 percent and cannot be delivered |
Much PMO tooling does allocation well and validation not at all, because the tool holds roles and percentages rather than the calendar that would contradict them. The two are complementary: allocation tells you the intended shape of the plan, and validation tells you whether that shape is real. Run allocation without validation and the numbers will balance right up to the point where the work does not get done.
Where does validated capacity go next?
Into team mapping, where each workstream gets a specific team and a named owner, and from there into the release plan and its forecast window. The related terms are defined in the agile portfolio management glossary.
Validation is also the point where a portfolio finds out how much it has overcommitted in aggregate. In a PPM4Agile implementation it is worth running on a live initiative early, because one validated plan does more to change how leadership sets the ranking than any amount of capacity reporting.