Why doesn't MS Project's built-in resource leveling catch all overallocation?

It catches all overallocation at the unit/time granularity you ran it at — which for most PMs is 'by day' or 'by week.' That misses three things: partial-unit assignments (0.5 units on two tasks looks fine at 1.0 but is actually two context-switches), peak-hour overallocation hidden by daily averaging (8 hours on task A + 6 hours on task B = 14 hours which averages to 'fine over the week'), and resource calendars with exceptions that leveling ignores if it was run against the project calendar. The tool is doing what you asked; the question is whether what you asked maps to reality.

Is a weekly heatmap better than a daily one?

For most PMOs, yes. Daily heatmaps are too noisy — every resource has 1-3 hours of slop per day for meetings, small tasks, interruptions, and a daily view flags every resource as 105-110% utilized every day. Weekly rollups smooth that noise while still being granular enough to surface real problems. Monthly rollups hide too much: a resource who's 150% utilized in week 2 and 50% utilized in week 4 shows as 100% utilized for the month, which is wrong. Weekly is the Goldilocks zone.

What's the difference between 'over 100%' and 'overallocated'?

Over 100% is a data fact; overallocated is a judgment call. A resource at 105% utilization for one week is probably fine — they work a little overtime, nobody burns out. A resource at 105% utilization for 12 consecutive weeks is overallocated. A resource at 95% utilization who just started chemotherapy is overallocated, and no tool can tell you that. The heatmap surfaces the data fact; the judgment call still lives with the PM and resource manager.

Should I include part-time resources and vendors in the heatmap?

Yes, with their correct MaxUnits. MS Project's MaxUnits field defines what 100% means for each resource — 0.5 for a half-time person, 1.0 for a full-time person, 2.0 for a two-person team. If your MaxUnits values are wrong (a common sin in files accumulated over years), the heatmap will be wrong. Fix MaxUnits first, then generate the heatmap.

What about matrix resources — people working on multiple projects?

This is where single-file heatmaps break down. MS Project's per-file heatmap only knows about the assignments in that file. If a resource is in three projects' .mpp files, each file will show them at 70% utilized and the PM of each file will say 'fine.' They're actually at 210%. Portfolio-level resource planning is the only way to catch this — which is why our resource heatmap tool imports a single file as a starting point but Onplana's PRO tier rolls up matrix-resource utilization across every project in the portfolio.

How do I fix overallocation once I've found it?

Three options, in order of preference: push the timeline (add days/weeks to accommodate the real capacity), reassign work (move tasks to under-utilized resources), or add capacity (hire/contract). The wrong option is 'ask the resource to work harder,' which is the option most PMs default to because it's the cheapest short-term. It's also the most expensive long-term because it produces burnout, errors, and attrition. Push timeline first, reassign second, add capacity third, apply overtime only as a last resort.

What if the .mpp doesn't have assignments with work hours?

Then the tool can't compute utilization and the heatmap will show 'neutral' cells. Common scenarios: assignments with only percent-complete (no work hours specified), milestones (no effort by definition), or schedules authored in 'manual scheduling' mode where durations are free-floating text. The fix is to add work-hour data to the assignments that matter. Every serious resource-capacity conversation needs hours; without them, you're tracking who's assigned to what, which isn't the same as how hard they're working.

Resource Overallocation in MS Project: The Invisible Math That Breaks Schedules

The resource allocation problem nobody graphs

Here's a test. Pull the latest status report for a project you know well. Look at the resources section. It probably says "resources on track" or "team operating at capacity" or "80% utilization across the team." Now open the underlying .mpp file, go to View → Resource Sheet, and look for red names (MS Project flags overallocation in red).

If there are red names, the status report was wrong. If there aren't red names but the project has slipped resources, the status report was also wrong — just in a direction the standard tool can't show.

Most PMOs operate blind on resource utilization. The information exists — every assignment in every .mpp has work hours, every resource has MaxUnits, every week has a finite number of hours — but the math to turn that into "who's overloaded in which weeks" is tedious to run and rarely gets run outside of formal replanning events. In between, status reports describe a fictional version of resource health.

This post walks through how overallocation actually forms (it's not what most PMs think), why the standard reporting views hide it, what a weekly utilization heatmap actually shows, and how to act on one. At the end there's a free Resource Allocation Heatmap tool that computes the whole thing in about 30 seconds from a .mpp upload — but the math is interesting regardless of whether you use it.

How overallocation actually forms

Textbook overallocation is simple: someone assigns a resource to 50 hours of work in a 40-hour week. In practice this rarely happens from a single action. It forms through a series of small, individually-reasonable decisions:

A PM notices a task needs a senior engineer and checks the resource sheet. Sarah is "60% utilized." PM assigns 16 hours of task work to Sarah. That brings Sarah to 76% on that project.

A second PM on a different project sees that the same Sarah is "30% utilized" on their project's assignments. They assign 12 more hours. Sarah is now 76% + 30% = 106% across the portfolio, but neither PM's view shows the overlap.

A third PM pulls Sarah into a "quick architecture review" — estimated 8 hours, never formally scheduled in any .mpp. Sarah is now 130% utilized this week.

At the end of the week Sarah works 54 hours, complains privately about the workload, and the status reports from all three projects say resources are on track. Two months later one of the projects misses a deadline, and the retrospective identifies "resource contention" as the root cause. Nobody mentions that the contention was mathematically obvious from the day the second PM made their assignment, if anyone had been looking at the sum.

This is the invisible part. Each individual decision looked responsible. The failure was in aggregation.

Why the standard views hide it

MS Project's resource views are designed for single-project operation. The Resource Sheet shows overallocation within this file. The Resource Usage view shows hours-by-day within this file. The Resource Graph shows one resource's utilization within this file. All three stop at the file boundary.

There are two granularity problems with the built-in views:

Too fine → daily noise. A daily heatmap shows every resource bouncing between 60% and 130% utilization because that's just how calendars work. Monday is meetings, Tuesday is deep work, Friday is catching up. The daily view flags almost everyone as overallocated most weeks, which trains PMs to ignore the flag.

Too coarse → monthly smoothing. A monthly rollup averages a 150%-utilized week 2 with a 50%-utilized week 4 into a "100% utilized month." The month looks fine. Week 2 was the week three deliverables shipped late because the senior engineer was spread too thin.

Weekly is the right bucket. Smooth enough to hide normal daily variance; granular enough to surface the overloaded weeks. This is the granularity mature PMOs operate at for capacity planning. Anyone doing monthly capacity planning is hiding the problem from themselves.

Reading a heatmap

A resource utilization heatmap is a grid. Rows are resources, columns are weeks, each cell is color-coded by utilization percentage. A mature heatmap shows:

Reading the sample above:

Sarah is the immediate fire. Weeks 4-5 show utilization over 120% — she's working nights and weekends, or she's dropping balls silently. Either way, the schedule that requires those weeks is not going to ship as planned.

Priya is the slow burn. Consistent 100-120% over 10 of 12 weeks. No single week looks catastrophic, but nobody can sustain that for a quarter without quality or retention consequences. Priya is six weeks from either burning out, quitting, or shipping work with significant defects.

Mark is under-utilized then crushed. Weeks 2-3 green (under 80%), then leave, then three weeks red. This is often a testing bottleneck: the plan assumed test work would stretch across the whole project, but it actually concentrates post-dev. Fix: start testing earlier in parallel with dev, not after.

Ana is healthy. Consistent green-to-yellow, no sustained red. Don't touch Ana. Most PMO discussions over-optimize for Ana-shaped problems (because they're legible) and under-optimize for Sarah-shaped problems (because they require someone to make a call).

James is available capacity. All green. If you need to reassign work from Sarah or Priya, James is the first candidate — but only if the work matches their skill set. Don't assume all "dev" resources are interchangeable. Skill fit matters more than capacity availability.

What the heatmap doesn't tell you

The heatmap is a starting point, not a conclusion. Three things it can't capture:

Skill fit. Two developers at equal utilization aren't interchangeable — one may be the only person who knows the legacy auth code. Moving work to capacity that exists but doesn't have the right skills just moves the bottleneck.

Multi-project matrix. Single-file heatmaps can't see matrix resources in other projects. If Sarah is in three .mpp files and each shows her at 70% utilized, her real load is 210%. Portfolio-level capacity views are the only fix.

Capacity quality. 100% utilization on high-priority focused work is different from 100% utilization on interruption-driven maintenance work. The second burns people out faster. A heatmap can't distinguish the two; a PM who knows the team can.

From heatmap to action

Option 1: Push timeline. Cheapest financially, most expensive politically. A schedule that slips 2 weeks because the math says the capacity isn't there is an honest schedule. A schedule that holds its dates by burning the team is a dishonest schedule that slips later with compounded damage. Push timeline first.

Option 2: Reassign work. Second-best if there's available, skill-appropriate capacity elsewhere. Costs the reassignee ramp-up time, costs the original assignee context-switching cost, costs the PM a re-briefing session. Work well when the reassignment is whole tasks (not task-fragments) and matches real skill sets.

Option 3: Add capacity. Contract a resource for the specific overloaded weeks. Most expensive in dollars and weeks-to-onboard but sometimes the only option if timeline can't move and work can't be reassigned.

Option 4 (wrong): Tell the overloaded resource to work harder. This is the default option because nobody has to make a decision. It is also the option that produces every attrition-driven delivery crisis six months later. Don't pick option 4.

The pre-migration version of this problem

Organizations migrating off MS Project Online ahead of September 2026 have a specific resource-allocation concern: the new tool needs to preserve utilization math. Most destination tools do — assignments with work hours translate cleanly. Features that require more care:

Resource calendars with exceptions (vacation, part-time hours)
MaxUnits values other than 1.0 (team resources, part-time resources)
Multi-rate cost tables (overtime rates, shift differentials)
Cost resources (flat-cost resources that aren't person-based)

If any of these are present in your .mpp, our Migration Preview tool will flag them specifically so you can validate destination support before committing. Running a capacity heatmap pre- and post-migration and comparing the two is a fast way to catch fidelity loss that wouldn't otherwise surface until go-live.

Run the heatmap on your own file

The Resource Allocation Heatmap tool is free, takes a .mpp or MSPDI XML, and produces the weekly-bucket heatmap in about 30 seconds. No account, no email capture. Download a PDF of the result for your next portfolio-planning meeting.

The standard views in MS Project aren't bad — they're just not designed for the question "which weeks are going to break my team?" A heatmap answers that question directly. Once you've seen one, the Resource Sheet's "red name" indicator starts to feel like a smoke detector with the battery missing: it tells you something is wrong after the fire is already burning.