2.5Resources & workload plan
The essentials in 30 seconds
- A resourceless schedule is fictional: assigning resources reveals overloads, invisible on the Gantt.
- The workload plan visualizes each person's allocation over time (cumulated per person and period).
- Reflex: smooth (floats, reassignment, shifting) and aim for a sustainable load (~80%), leave and multi-projects included.
Running mini-case — Bilal finds his developer everywhere at once
Bilal's Gantt is done — but assigning names, he sees his developer planned on three packages the same week, at 150% of availability already half-time elsewhere. He shifts one non-critical package using its float, reassigns the mockup to the designer, and grounds the schedule in reality. The deadline moves one week — owned — instead of silently exploding.
Sequel to cases 2.1-2.4 — Bilal confronts his schedule with real availability.
1. Invisible overloads
A schedule is only realistic if the resources (people, equipment) to execute it are available. Assigning resources reveals a problem invisible on the Gantt: overloads, when the same person is supposed to do several things at once.
The workload plan visualizes this allocation over time: for each person, assigned work cumulated period by period.
2. Smoothing
Detecting and fixing overloads is called smoothing (or leveling): you spread tasks, reassign, use floats to bring each resource back to a sustainable load.
A schedule ignoring people's real availability is a fictional schedule. Bilal folds in leave, part-time and multi-projects — and aims ~80% rather than 100%.
🔎 Concrete example — 🔎 Concrete example — Don't aim for 100%
Sustainable load.
Person loaded at 100% → no margin; the slightest hiccup derails.
Aiming ~80% of theoretical time leaves breathing room.
→ a saturated team is a fragile team.Outcome: a schedule aligned with people's reality.
Reflex: factor in leave and multi-projects.
Section vocabulary
- Resource
- Means needed for delivery: people (with skills) and materials/equipment.
Simple example: Bilal's two developers and designer, plus the test server.
What it is not: a task or a deadline (those are work and time).
Reflex: each package gets its named resource, with real availability.
- Workload plan
- View of workload assigned to each resource over time; reveals overloads and underloads.
Simple example: Bilal's developer weekly cumul: 150% in week 3.
What it is not: the budget or the risk register.
Reflex: cumulate per person and period, every week.
- Overload (overallocation)
- When a resource is assigned more work than they can deliver over a period.
Simple example: Three packages the same week for a half-time person.
What it is not: a quiet week with spare margin available.
Reflex: spot every cumul beyond real availability.
- Smoothing / leveling
- Respreading tasks (via floats, reassignment, shifting) to bring resources back to a realistic load.
Simple example: Bilal shifts one non-critical package and reassigns the mockup.
What it is not: adding permanent overtime to absorb.
Reflex: first use non-critical tasks' floats.
- Availability
- A resource's really available time (leave, other projects, part-time): fold into the plan.
Simple example: Bilal's developer is only half-time on this project.
What it is not: 100% theoretical time, leave and multi-projects ignored.
Reflex: plan on real time, never theoretical time.
In practice — In practice — Detecting and fixing overloads
- Assign a resource (person) to each schedule task.
- Build the workload plan: for each person, cumulate assigned work period by period.
- Spot overloads (>100% availability): times when someone is on too many tasks at once.
- Smooth: shift non-critical tasks (via their floats), reassign, or renegotiate the deadline. Fold leave and unavailabilities back in.
Ready-to-say script — announcing smoothing that shifts one week (1 min)
"Assigning names, I found an overload: one person on three packages the same week. I'm shifting one package that has float and reassigning the mockup. It moves the end one week — owned now rather than suffered later."
Say to the sponsor: show the overload before announcing the shift.
Copy-paste template — workload plan and smoothing
TASK → RESOURCE: _______________
REAL AVAILABILITY (part-time, leave, multi-projects): _______________
WEEKLY CUMUL: W1 ___ % / W2 ___ % / W3 ___ % / W4 ___ %
OVERLOADS SPOTTED: _______________
SMOOTHING (shift / reassign / renegotiate): _______________Small business / tight budget
A simple table is enough: rows = people, columns = weeks, cells = load — overruns jump out.
Algerian SME
Bilal folds in local realities: leave, travel, other jobs' activity peaks — the workload plan shows them in black and white.
Remote team
Multi-project is the remote norm: ask everyone their real rate per project, otherwise overloads silently add up.
Multi-project / matrix
Coordinate with other project managers and escalate allocation conflicts to the sponsor or PMO.
✓ Best practices
- Factor leave, part-time and multi-projects into availability.
- Use non-critical tasks' floats to smooth.
- Aim for a sustainable load (~80%), not 100%.
✗ Common pitfalls
- Ignoring overloads (invisible on a raw Gantt).
- Planning at 100% availability (no margin for contingencies).
- Forgetting a person is shared across projects.
Key takeaways
- A schedule is only realistic if resources are available.
- Assigning resources reveals overloads, invisible on the Gantt.
- The workload plan visualizes allocation over time.
- Smoothing (floats, reassignment) brings everyone back to a sustainable load.
48h Challenge — apply tomorrow
Assign one resource to each task of your schedule and cumulate load per person and week (template above). Spot one overload and propose smoothing.
- I can explain what a workload plan reveals.
- I can smooth via floats, reassignment or shifting.
- I've detected and fixed a real overload.
Frequently asked questions
How to handle a person assigned to several projects?
It is the most frequent, trickiest case: their availability for your project is partial. Factor their real assignment rate (e.g. 50%) into the workload plan, coordinate with other project managers, and escalate allocation conflicts to the sponsor or PMO. Ignoring multi-projects leads to systematically unrealistic schedules. A person "50% on three projects" is actually permanently overloaded.
Should you aim for 100% load to be efficient?
No, it is counterproductive: a person loaded at 100% has no margin for contingencies, exchanges, rework — and the slightest hiccup derails the schedule. Aim for a sustainable load instead (often 80% of theoretical time), leaving breathing room. A saturated team is a fragile team: it absorbs no shock and burns out, ultimately costing far more than the "margin" you thought you saved.
Bilal's Gantt is perfect, but adding names he sees his developer at 150% in week 3. What to do?