Learn

Seeing team overload before it happens

Nobody misses a deadline in a vacuum. Someone was at 145% three weeks earlier, and nobody was looking at that number.

The number that predicts the miss

Every assignment carries a share of someone's time: fixing the API might take 80% of Charlie's week, reviewing designs 25%. Add up everything a person carries in the same week, across every project they touch, and you get their load. Judge it against their own capacity (100% for full-timers, less for anyone shared or part-time) and the future becomes legible: a week at 145% three weeks from now is a missed deadline scheduled in advance, visible today, fixable today.

Three rules that make the number honest

Peak, not average. The crunch week is what breaks schedules; averaging it away is self-deception with math.
Across all projects. Per-project charts each look fine while their shared person quietly stacks to 150%. Sum per person, not per chart.
Against personal capacity. 60% load is relaxed for a full-timer and overload for someone whose real availability is 50%.

Reading a workload heatmap

The practical instrument is a heatmap: people as rows, weeks as columns, each cell that person's peak load for the week, green when comfortable, amber near capacity, red over it. Scanning one takes ten seconds: red cells are fires scheduled for later, and the empty or green columns next to them are where the fuel can be moved. Below, the real thing:

Ten seconds, whole story

GanttPulse's Workload view, a real fragment of the app: Charlie peaks at 145% in mid-July, the popover shows exactly which tasks stack up, and Evan has room in the same weeks.

Workspace Workload

Workload

Peak load per week across all projects, judged against each person's own capacity.

All (5)Over (1)Full (1)Under (5)Free (0)

DayWeekMonth

Today

Person

Jun 29

Jul 6

Jul 13

Jul 20

Jul 27

Aug 3

Aug 10

Aug 17

Sarah Ben

peak 80%

40%

60%

80%

75%

50%

30%

20%

Charlie Kim

peak 145%

90%

120%

145%

110%

95%

80%

60%

Bob Rivera

peak 100%

70%

85%

100%

92%

60%

40%

Diana Petrov

cap 80% · peak 64%

30%

45%

64%

50%

40%

25%

10%

Evan Torres

peak 47%

20%

35%

47%

30%

Charlie Kim

Jul 13 – Jul 19 · peak 145% of 100% capacity

Build API

80% · Jul 8 – Jul 24 · Atlas 2026

Integration tests

40% · Jul 13 – Jul 17 · Mobile App v2

Code review

25% · Jul 13 – Jul 31 · Atlas 2026

Fixing an overload (in order)

1Slide something with float. If a task in the red week has slack, move it out of the peak, cost: nothing, if it is off the critical path.
2Split the task so its halves land in different weeks, same work, flatter peak.
3Rebalance owners. The heatmap shows who has green room in the same weeks; move a task, not a person.
4Or tell the truth early. If nothing bends, the schedule is optimistic, saying so three weeks ahead is management; discovering it in the retro is archaeology.

Tools can help with the proposal step: GanttPulse's assistant can suggest a leveling plan for an overloaded person (which tasks to move where). The judgment stays human; the point of the heatmap is that the judgment happens weeks earlier.

Common questions

What allocation percentage should a task have?

Whatever is true. If Dana gives the redesign about half her time, that assignment is 50%. The number is not a performance target, it is an honest input so the sums mean something. Defaulting everything to 100% is how three parallel tasks quietly become a 300% week.

Why peak load and not average?

Because averages hide the crunch. Someone at 60% for three weeks and 180% in the fourth averages a comfortable 90%, and still burns out in week four, with every task of that week late. Deadlines are missed at the peak, so the peak is the number to watch.

What is personal capacity?

Not everyone is available 100%. A part-timer at 60%, a tech lead who really has 70% after meetings, a contractor shared with another department. Judging everyone against 100% marks the part-timer "fine" while they drown. Load should be judged against each person's OWN capacity.

My team works on several projects. Does that change anything?

It is the main reason overload goes unseen. Each project's chart looks reasonable on its own; the person assigned in three of them is at 150% and no single chart shows it. Workload has to be summed ACROSS projects per person, or the busiest people are invisible exactly where it matters.

I found an overload. What now?

In order of preference: move a task that has float (check the critical path first), split it so the halves land in different weeks, hand part of it to whoever has spare room, or, if nothing bends, accept the schedule is optimistic and say so out loud now rather than in the retro. Leveling suggestions from an AI can propose the moves; a human should approve them.

The workload heatmap is built in

Cross-project, capacity-aware, with AI leveling one click away. Free during the beta.

Join the free beta