Over-allocation is the condition where more work has been committed than the team has capacity to deliver. It is almost never named directly. Instead it shows up as slipped deadlines, deteriorating quality, and team burnout, and the cause gets attributed to poor project management or weak execution rather than to a structural commitment problem.
The reason over-allocation persists is that its symptoms look like execution failures. When projects are late, the instinct is to ask why the project manager didn't escalate, or why the developer isn't working faster. The more useful question is: was this project given enough realistic capacity to succeed in the first place?
The visible signs
Projects consistently miss committed dates
When schedule slips are the norm across most projects, not an isolated exception, the most common root cause is not poor estimating or weak delivery management. It is that the people doing the work are spread across too many simultaneous commitments. A developer allocated at 20% to five projects is not delivering 100% capacity across those commitments. They are delivering fragments, and the context switching between fragments absorbs a meaningful portion of every working day.
If your organization consistently adds two to four weeks of buffer to every delivery date because "things always take longer," you are experiencing over-allocation as a cultural adaptation rather than addressing it as a structural problem.
Small requests have long lead times
When a business stakeholder submits a genuinely small change request and is told it will take six to eight weeks, the reason is almost always a queue. The work is simple. But everyone with the skills to do it is already fully committed to approved projects. Long lead times on low-complexity work are one of the clearest signals that the team's available capacity is exhausted even before new requests arrive.
The same people are on every critical path
If two or three individuals appear as dependencies in the critical path of every significant project, the organization has a skill concentration problem that presents as over-allocation. Those people are the constraint. Adding more projects without addressing the constraint makes the situation worse. Every additional project that touches those individuals competes with every other project that already depends on them.
Quality is declining
When testing cycles get compressed because delivery is already behind schedule, when peer code reviews get skipped because "there's no time," when documentation never gets written because "we'll come back to it," quality is being traded for throughput. Teams under resource pressure consistently cut quality-adjacent tasks because they are the least visible to stakeholders in the short term. The technical debt accumulates until it becomes a delivery problem in its own right.
The hidden signs
Shadow projects
Business teams that cannot get approved work delivered through formal channels will find other ways. They hire a contractor directly and ask an IT team member to oversee the work informally. They get a developer to "just take a quick look" at something that expands into a three-month engagement. They build something themselves using low-code tools and then need IT to integrate it.
Shadow projects consume IT capacity that was already committed to approved work. They make the over-allocation worse while remaining invisible to portfolio management. When shadow projects are common, the formal portfolio is not a complete picture of what IT is actually doing.
Hero dependency
When specific individuals are expected to rescue every troubled project, and when those individuals are never not working a rescue, the organization has institutionalized over-allocation. The heroes are not performing exceptionally well. They are compensating for a structural commitment problem that the team cannot absorb any other way. Organizations that depend on heroes to make commitments land tend to lose those people to burnout or attrition, which creates a capacity crisis that reveals exactly how much invisible weight they were carrying.
Context switching as a way of life
A team member nominally assigned to six projects is probably making meaningful progress on none of them. Each context switch carries a re-engagement cost, typically estimated at 15 to 20 minutes to return to productive focus on a task after switching. A developer who switches contexts four times in a day loses at least an hour to the switching itself, before accounting for interruptions from Slack, production incidents, and ad-hoc requests. In heavily over-allocated teams, context switching is treated as normal rather than as a sign that something is structurally wrong.
How to measure over-allocation
The portfolio-level measure: sum total FTE demand from the approved project portfolio and divide by total available FTE capacity.
Demand-to-capacity ratio = Total FTE demand ÷ Total available FTE capacity
A ratio above 1.0 confirms over-allocation. Most over-allocated IT organizations are running at 1.2 to 1.5, meaning 20 to 50% more work is committed than capacity exists to deliver.
At the individual level: sum the allocated percentage for each person across all their project assignments. Anyone at 120% or more on paper is almost certainly delivering at below 100% across those commitments in practice. The overcommitment on paper translates to underdelivery across all assignments simultaneously.
The three structural fixes
Over-allocation has three solutions. The answer in most cases is some combination of all three, but the proportion matters.
Reduce demand. Stop, defer, or descope projects until the committed portfolio matches what the team can realistically deliver. This is the most structurally effective solution and the most politically difficult one. The governance body needs to make explicit decisions about what gets paused, with documented reasoning. For guidance on how to run that review, see the article on IT portfolio rebalancing.
Increase capacity. Hire, contract, or reallocate resources from lower-priority areas. This takes time to produce results. A new hire takes weeks to onboard and months to reach full productivity in a complex environment. Contracting is faster but requires well-defined scope to be effective. Increasing capacity treats the symptom at the margin; it does not fix a portfolio that is structurally overcommitted.
Reduce context switching. Assign people to fewer projects with higher allocation percentages. A developer at 80% on one project and 20% on one other is measurably more productive than the same developer at 20% across five projects. The throughput improvement from concentrating allocation can be significant without adding a single person to the team. The organizational challenge is that this requires explicitly de-prioritizing some projects to protect others, which surfaces the same governance conversation that reducing demand requires.
The governance conversation that over-allocation demands
Over-allocation is a portfolio governance problem wearing the costume of a delivery problem. The symptoms appear in projects. The cause is in how much work was approved relative to available capacity.
Fixing it requires the governance body to acknowledge that too much was approved and to make explicit decisions about what changes. That conversation is uncomfortable when it means telling a business stakeholder that their project is paused. It is less damaging than the alternative: a portfolio full of theoretically approved projects that are all simultaneously late and nobody can explain why.
For the capacity picture that drives this conversation, see the guide on capacity vs demand gap analysis in IT portfolio management. For how the governance body acts on it, see how to run a portfolio review meeting.
Frequently Asked Questions
What does IT resource over-allocation mean?
Over-allocation is the condition where more work has been committed than the team has capacity to deliver. It is measured as the ratio of total FTE demand from the approved portfolio to total available FTE capacity. A ratio above 1.0 indicates over-allocation. Most over-allocated IT organizations are running at 1.2 to 1.5, meaning 20 to 50% more work committed than capacity exists to deliver.
Why do projects slip when the team isn't actually behind?
When team members are split across many simultaneous projects, the context switching between commitments consumes a significant portion of each working day. A developer allocated to four projects is not delivering full capacity to any of them. Each task switch carries a re-engagement cost of 15 to 20 minutes. Four switches per day eliminates over an hour of productive work before accounting for any interruptions.
What is a shadow project in IT?
A shadow project is work that bypasses the formal portfolio process and gets done through informal agreements, direct business unit contracting, or quiet IT team commitments. Shadow projects appear when business teams cannot get approved work delivered fast enough. They consume IT capacity already committed to approved work, making over-allocation worse while remaining invisible to portfolio management.
What is the most effective fix for IT team over-allocation?
Reducing demand is the most effective structural fix: stopping, deferring, or descoping projects until the committed portfolio matches what the team can realistically deliver. Hiring and contracting help at the margin but take time. Reducing context switching by concentrating each person's allocation on fewer projects produces the fastest throughput improvement without adding headcount, but requires the same governance conversation as demand reduction.