Resource allocation is more than counting projects
Workload planning should reflect the actual weight and lifecycle of the work, not simply the number of projects beside someone's name.
A project count can hide the real load
In a fast-moving development program, one of the hardest questions is not whether the work can be done. It is whether the same people are being asked to make the impossible happen too many times at once.
A list of assignments rarely answers that question. Two people can each own four projects and carry completely different workloads. One portfolio may include repeatable locations moving through predictable milestones. The other may include a large site in a difficult jurisdiction, heavy demolition, an interconnecting stair, unresolved engineering, or a launch date that cannot move.
The project count is the same. The lift is not.
Workload changes with the lifecycle
Phase matters as much as complexity. A project in design development asks something different of a designer than one in construction administration. Permitting may be quiet until an agency comment creates a concentrated push. Procurement can appear stable until a long-lead item threatens the critical path. Closeout often looks small on a schedule while demanding persistent coordination from the project manager.
The same project can therefore carry a different weight from one month to the next. A useful resource model has to account for where the work is in its lifecycle, which milestones are approaching, and which roles will absorb the lift.
That distinction matters because broad averages make pressure look manageable until several demanding moments overlap.
A practical model
Weight the work before assigning the people
On a high-growth development team, we built a workload model around the variables that changed the actual effort. The inputs included square footage, jurisdictional difficulty, demolition, structural and engineering complexity, interconnecting stairs, milestone intensity, schedule overlap, and the role each person played.
We also layered in lifecycle. Design development, permitting, construction, and closeout each created a different demand profile for designers and project managers.
The goal was not to create a perfect score. It was to give leaders a more honest and empathetic view of what the team was carrying before another urgent assignment landed.
The model should support judgment, not replace it
No formula can fully capture the human reality of a team. A new manager may need more support on a familiar project. A strong performer may be capable of carrying more, but that does not mean they should always be asked to. A difficult stakeholder relationship can consume time that never appears in the program schedule.
The value of the model is not that it makes the decision automatic. It makes the pressure visible. It gives leaders a better starting point for a conversation about capacity, sequencing, support, and tradeoffs.
That is also where technology can help now. A modern system can read schedules, milestone changes, project attributes, and team assignments continuously. It can flag upcoming collisions, test scenarios, and show where a two-week delay in one workstream creates a four-week capacity problem somewhere else.
What it should not do is quietly turn people into utilization percentages.
Optimize for sustainable delivery
The wrong goal is maximum utilization. A team operating at full theoretical capacity has no room for a surprise, a sick day, a permit comment, a design revision, or the informal coaching that helps people improve.
The better goal is sustainable delivery. The team should have enough visibility to focus, enough flexibility to respond, and enough support to maintain the quality of the work when conditions change.
That often means using the data to make a harder leadership decision: move a date, narrow a scope, add support, change the sequence, or acknowledge that the current ask is not reasonable.
Technology can make workload visible. Leadership still has to decide how to respond.