When Everyone Is On Three Projects

Week three of a six week release, your software team is stuck. The product manager needs a committed date for a customer demo, the engineering manager is warning about a defect spike, and QA is already working nights. Two engineers are each assigned to three initiatives, a production support rotation keeps pulling them away, and the designer is split across two squads. The decision that is stuck is simple on paper. Do you keep the date and cut scope, keep scope and move the date, or add capacity that you do not actually have. Every day you wait, rework grows and trust drops. This course builds the habits and artifacts that get you unstuck. You will read a schedule for hidden resource demands, build a capacity model that matches how people actually work, and use AI to generate options you can negotiate with real stakeholders.

What over allocation looks like in the work

The first signal is not the Gantt chart. It is the pattern of interruptions. An engineer starts a feature, gets pulled into a Sev 2 incident, returns to merge conflicts, then rushes a code review for another project because it is blocking their teammate. The milestone slips, then the team compensates by skipping tests. A week later defects rise, QA becomes the bottleneck, and the release candidate churns. Burnout shows up as longer cycle time, brittle handoffs, and more time spent asking for status than doing the work.

A common PM mistake is treating this as an execution problem. The instinct feels right because you can call more standups, tighten Jira, and push for focus. The consequence is that you increase coordination load on the same over allocated people. The actual problem is that the schedule is demanding more person hours, in the wrong weeks, than the team can supply without breaking quality.

Resource management is a constraint system

When you allocate people, you are solving a constraint problem, not filling boxes. Scope is the work you have promised. Schedule is when that work must be done. Capacity is how many hours of usable work time the team can supply each week. Skills are which people can do which tasks without unacceptable risk. Availability assumptions are the hidden rules, like on call, meetings, and shared services requests, that reduce capacity.

Before you choose an action, predict which constraint is actually binding in your situation, schedule, skills, or availability.

The reason this matters is that the same symptom can have different causes. In software delivery, skills constraints often dominate. Only one person knows the deployment pipeline. In a marketing campaign, the binding constraint might be calendar dates tied to external events. In a healthcare operations rollout, availability assumptions like training time and shift coverage can block even when headcount looks fine. Your job is to name the constraint, then pick a response that changes that constraint, not one that just adds pressure.

Baseline a capacity model you can defend

You cannot level resources until you know what you truly have. A capacity model is your explicit estimate of weekly usable hours per role, after subtracting time that will not move your project forward. Start with nominal hours. Subtract PTO and holidays. Subtract fixed meetings and ceremonies. Then apply a focus factor, the percentage of remaining time that can realistically be spent on planned project work given interruptions and coordination. Finally, subtract shared services time like production support or internal requests that you cannot ignore.

Use the builder to draft a sprint capacity plan that includes PTO and meeting load for each role.