The Capacity Planning Trap: Why Your Team Is Always Full and Always Behind

Your team says they have capacity — then the project slips anyway. This episode unpacks why standard capacity planning consistently lies to you, and what to do instead before the next deadline blows up.

Show Notes

Capacity planning is supposed to prevent overload — so why do teams keep ending up exhausted and behind schedule even when the numbers looked fine at the start? This episode of ProjectManager.co breaks down the hidden structural flaws in the way most organizations measure and allocate capacity, and offers a practical framework for fixing them before they cost you another slipped deadline.

The episode walks through three compounding mistakes that turn a confident "yes, we have capacity" into a six-week crisis, and what project leaders can do to close each gap:

• Calendar hours ≠ productive project hours. A person booked at 75% utilization is rarely 25% available — invisible loads like reactive work, recurring meetings, and context-switching consume most of what looks like slack on paper.
• Audit before you allocate. A two-week time-tracking exercise — bucketed into planned work, reactive work, meetings, and personal overhead — reveals the real baseline capacity figure that planning should actually be built on.
• Average utilization hides collision points. When three concurrent projects all hit a review milestone in the same week, average load figures tell you nothing useful; a week-by-week resource histogram exposes the spikes before they become emergencies.
• The 80% rule as a forcing function. Treating any week where a person exceeds 80% of their real baseline as an automatic red flag builds in the shock absorber that unplanned work will inevitably consume.
• Hours are not the unit — skills are. A capacity plan that doesn't map specific skill demand against a team skills matrix will routinely book the right number of hours from the wrong people, leaving projects under-resourced in practice even when headcount looks sufficient.
• Tools should do this work for you. Features built into dedicated platforms — like AI resource planning — are designed precisely for this kind of demand-versus-capability matching; using them only as task lists leaves the hardest planning problems unsolved. Teams wanting to go deeper can also explore the resource management framework and run the numbers with the resource capacity calculator.

The core argument the episode makes is that capacity is not a single number — it is a shape across time, made of specific skills, with a category of invisible load baked in that will never appear on any project plan. Recognising that shape is what separates teams that plan realistically from teams that stay permanently full and permanently behind. For more on diagnosing your team's planning maturity, the PM maturity assessment is a useful next step. If you enjoyed this episode, the conversation on How to Run a Project Retrospective That Actually Changes Anything pairs well with it — retrospectives are often where capacity problems finally get named out loud.

ProjectManager.co

What is ProjectManager.co?

Project management for people who deliver, not people who certify. Estimation that survives contact with reality, scope and dependency management, status reporting nobody has to decode, and where self-hosted and AI-assisted tooling genuinely helps.

Each episode takes one practice — a re-estimate mid-project, a dependency nobody owns, a status meeting that produces nothing — and works through a better way to handle it. Written for delivery leads and PMs running real projects, with no methodology evangelism. Five or six minutes, one practice at a time.

Topics include estimation that survives reality, dependency and critical path management, scope negotiation, status reporting nobody decodes, resource planning, retrospectives that change something, and self-hosted versus SaaS tooling.

Produced by ProjectManager.co, self-hosted AI project management. Full details, services and further reading at https://projectmanager.co