Your resource plan says 140 percent. Now what?
It is 8:40 on a Monday. You open the resource view before your coffee has cooled, and there it is.
Three developers are overallocated. Your lead data analyst, the one person who understands the billing migration, is somehow assigned to four projects at once. One project manager has already started negotiating dates quietly with stakeholders.
The plan is not telling you something might go wrong.
It is telling you something already has.
This is where resource planning gets interesting, because identifying overload is the easy part. The harder question is what the PMO does next.
You cannot fix 140 percent utilization by asking people to work 40 percent harder. You have to change the portfolio.
That means figuring out what is really causing the overload, separating commitments from wishes, and forcing decisions that probably should have happened weeks ago.
First, make sure the overload is real
Before escalating anything, clean up the signal.
A resource plan can show 140 percent for several very different reasons.
Maybe the person really is committed to too much work.
Maybe an old project never released them.
Maybe one project entered an average allocation of 50 percent even though the work actually happens in two intense weeks.
Maybe proposed work is being counted alongside committed work.
Maybe support and operational responsibilities are missing entirely, which means the 140 percent number is actually optimistic.
Those are very different problems.
So do not start with, "Priya is at 140 percent."
Start with:
What work is actually consuming Priya's capacity, when does it need her, and how much of it is truly committed?
That question usually turns one scary percentage into a much more useful picture.
Find the constraint, not the average
Portfolio overload is rarely spread evenly.
You may have twenty people showing reasonable utilization while two specialized resources are quietly determining the delivery dates for half the roadmap.
That is why solving "overall utilization" is often the wrong goal.
Suppose you have twelve engineers available across the portfolio. On paper, capacity looks healthy.
But your payments modernization work requires one of the only two engineers who understands the legacy transaction service. Your reporting initiative needs that same skill. So does the regulatory project leadership just approved.
Your bottleneck is not engineering capacity.
Your bottleneck is legacy transaction expertise.
That distinction matters because adding another general engineer does not solve the problem. Neither does shuffling percentages around until the dashboard turns green.
You have to solve the constraint that is actually governing the portfolio.
General capacity can often be planned by role or skill pool. Scarce specialists may need to be planned individually because one person's availability can move multiple project dates.
Plan at the level where the constraint exists.
Separate commitments from demand
Once you understand the overload, the next question is uncomfortable:
How much of this work have we actually committed to?
Portfolios get into trouble when everything is treated as equally real.
One project may already have a contractual deadline.
Another may be approved and funded but not started.
Another is still technically a proposal, but somebody entered resources against it because they wanted to reserve capacity.
Another has been "finishing up" for four months.
If all four appear as equivalent demand, your capacity picture becomes impossible to interpret.
Split the work.
You need to know what is:
- Committed: work the organization has genuinely agreed to deliver.
- Planned: approved work that can still be sequenced or moved.
- Proposed: demand that has not yet earned capacity.
- Residual: cleanup, support, or leftover project work that may belong somewhere else.
That separation alone can reveal that your 140 percent problem is not actually a staffing problem.
It may be a prioritization problem wearing a staffing costume.
A worked example: Priya is at 160 percent
Let me make this concrete.
Priya is the only analyst who fully understands the legacy billing schema.
Her capacity view shows three assignments:
- Billing migration: 90 percent during the next two cutover weeks.
- Finance support: about 20 percent of her time.
- Customer portal: 50 percent.
That is 160 percent.
The wrong response is to ask Priya which work she can "fit in."
The right response is to look at the portfolio.
The billing migration has an external commitment and a fixed cutover window.
Finance support is operational work. It does not disappear because a project needs her.
The portal is important, but its start date is still movable.
Now the decision becomes obvious.
You have a few real options.
Option one: protect the migration and move the portal.
Option two: find temporary coverage for some of Priya's finance support and preserve more portal work.
Option three: reduce the portal scope so the work needing Priya starts later.
Option four: keep everything as planned and accept that one or more dates are likely to slip.
Notice what is missing from that list:
Priya works at 160 percent.
That is not an option. It is avoidance.
Make the tradeoff visible
This is where the PMO earns its keep.
The PMO does not need to personally decide which initiative matters most. But it should make the decision impossible to avoid.
Instead of taking this to leadership:
> "Priya is overallocated. What should we do?"
Take this:
> "The billing migration and customer portal both require Priya during the same two-week period. Finance support consumes about one day per week and cannot simply be removed. We can protect the billing cutover and move the portal two weeks, or we can preserve the portal date by finding temporary finance coverage. I recommend protecting the billing cutover because the date is externally committed."
Now leadership is deciding a tradeoff.
That is portfolio management.
Overcapacity should not end in a scheduling puzzle. It should end in a business decision.
Do not solve overload by stealing from operations
One of the easiest ways to make a capacity problem disappear on paper is to pretend support work does not exist.
Do not do that.
Production incidents, customer support, maintenance, security work, administrative obligations, and other operational responsibilities still consume people whether the portfolio model acknowledges them or not.
Before assigning project work, account for that standing demand.
The remaining capacity is what projects actually have available.
That number may be uncomfortable.
Good.
It is far better to discover in planning that a specialist has 26 project hours available than to build a roadmap assuming 40 and spend the quarter explaining why everything slipped.
Release capacity that should already be free
Overallocation is not always caused by too much new demand.
Sometimes old work simply never let go.
Look for people still allocated to:
- Projects that have already launched.
- Initiatives with no meaningful activity.
- Cleanup work that should have moved into operations.
- Projects waiting indefinitely on external decisions.
- Optional enhancements still living under an old project code.
That capacity is often recoverable without hiring anyone.
But recovering it requires making a closure decision.
If the leftover work is genuinely required, give it an owner and a finish date.
If it is support, move it into the appropriate operational bucket.
If it is optional, send it back through intake and make it compete with everything else.
Do not allow old demand to keep first claim on scarce resources simply because it arrived first.
Rebaseline the plan
Once the tradeoff is made, change the plan.
This sounds obvious, but organizations are surprisingly good at making a decision verbally while leaving the original dates, allocations, and forecasts untouched.
Then, three weeks later, somebody asks why the dashboard still says the old thing.
If the portal moves, move it.
If capacity changes, update it.
If a project loses priority, reflect that.
If the organization consciously accepts delivery risk, show that too.
A portfolio plan is useful only when it describes the decisions the organization has actually made.
Otherwise it becomes historical fiction.
Where a portfolio tool helps
You can do all of this in a spreadsheet.
The hard part is not the arithmetic. It is maintaining the connections.
One person's allocation may affect three projects. Moving one project may resolve one conflict and create another. A delay may change a dependency somewhere else in the roadmap.
That is where a portfolio tool becomes useful.
Perspective brings demand, capacity, dependencies, and roadmap timing together so resource contention can be evaluated as a portfolio problem rather than project by project.
But software cannot make the tradeoff for you.
It can show that two initiatives want the same scarce resource.
Someone still has to decide which one moves.
The tool exposes the decision. The organization owns it.
How to recover an overloaded portfolio this week
Start with the biggest conflict, not the entire organization.
- Identify the worst overload. Find the resource or skill constraint creating the most delivery risk.
- Validate the demand. Remove stale allocations and separate committed, planned, proposed, and residual work.
- Protect operational capacity. Account for support and maintenance before assuming project availability.
- Build two or three realistic options. Resequence work, reduce scope, add targeted capacity, or move a date.
- Take the tradeoff to the right decision-maker with a recommendation.
- Update the portfolio immediately after the decision.
Then move to the next constraint.
You do not need to make every resource chart perfect.
You need to make the portfolio executable.
A plan showing 140 percent is not asking you to optimize harder.
It is asking you to choose.