A resource histogram is a bar chart that shows how much of a resource, usually people, is scheduled to work in each period of a project. Time runs along the bottom, hours or headcount up the side, and each bar shows the total demand for that period. Draw a line across it for the capacity you actually have, and the picture tells you instantly where the plan asks for more than the team can give. That single view, demand against capacity over time, is why the histogram has outlived most of the hand tools it grew up with.
Key takeaways
- A resource histogram plots resource demand per period as bars, with a capacity line drawn across the top, so over-allocation shows up as bars that punch above the line.
- Resource loading is the underlying data (how many hours each resource is booked for each period); the histogram is the chart that displays it.
- You build one by summing the assigned hours for a resource across every task in each period, then comparing the total to that resource's available hours.
- When a bar exceeds capacity, you fix it with resource leveling or resource smoothing, not by ignoring the overshoot and hoping.
- Modern PPM and scheduling tools draw the histogram automatically, but reading one correctly is still a core resource-planning skill and a common PMP exam topic.
Last updated September 2026.
What is a resource histogram in project management?
A resource histogram is a graphical bar chart that shows the amount of a resource scheduled to work over each unit of time in a project. The horizontal axis is time, split into days, weeks, or months. The vertical axis is the quantity of the resource, measured in hours, days, or headcount. Each bar is the total demand for that period, and a horizontal line marks the capacity available, so any bar rising above the line is an over-allocation you need to resolve.
The reason it matters is that a task list or a Gantt chart tells you when work happens, but it hides how much simultaneous demand lands on any one person. A histogram makes that demand visible. If three tasks all need the same senior engineer in the second week of March, the schedule looks fine, but the histogram shows a bar at 150 percent of that engineer's capacity and tells you the plan is not real. It is the difference between a plan that looks achievable and one that is.
Resource histogram vs resource loading chart
People use the two terms almost interchangeably, and the difference is small but worth knowing. Resource loading is the data: the number of hours each resource is booked to work in each period, produced by adding up every task assignment for that resource. A resource loading chart or resource histogram is the visual that displays that data as bars. In practice, when someone asks for a resource loading chart and someone else asks for a resource histogram, they usually want the same picture.
The loading numbers come from combining two things. First, the assignments: which named people are on which tasks and for how many hours. Second, the schedule: when those tasks are calculated to run, which comes out of critical path analysis. Overlay the two and you can aggregate demand for each resource across time. That aggregated demand is the loading, and the histogram is how you look at it. Getting the underlying assignments right is the job covered in resource allocation in project management; the histogram is how you check that the assignments add up to something the team can survive.
What a resource histogram shows
Read left to right, a well-built histogram tells you three things at once: total demand per period, how that demand compares to capacity, and how the load rises and falls across the life of the project. The bars are the demand. The capacity line is the ceiling. The shape is the story. A histogram that spikes hard in the middle and sits near empty at the ends is a classic sign of a plan that front-loads dependencies and leaves people idle before and after.
Here is a simple loading table for one engineer across six weeks, the kind of data a histogram draws. Assume the engineer has 40 available hours per week.
| Week | Assigned hours | Capacity | Load | Status |
|---|---|---|---|---|
| 1 | 24 | 40 | 60% | Under |
| 2 | 40 | 40 | 100% | Full |
| 3 | 58 | 40 | 145% | Over-allocated |
| 4 | 52 | 40 | 130% | Over-allocated |
| 5 | 16 | 40 | 40% | Under |
| 6 | 8 | 40 | 20% | Under |
Swipe to see more →
Plotted as bars, weeks 3 and 4 punch above the 40-hour line while weeks 5 and 6 sit half empty. The fix is almost always to move some of the week 3 and 4 work into weeks 5 and 6, which is exactly what resource leveling and smoothing do. Utilization, the ratio of booked to available hours, is the metric that summarizes this row by row, and it is covered in resource utilization.
How to build a resource histogram
You can build one in a spreadsheet in an afternoon, and it is worth doing by hand once so you understand what your tool is drawing for you.
- Pick the resource and the time unit. Choose a single resource (one person or one role) and decide whether you are charting by day, week, or month. Weeks are the usual default for a multi-month project.
- List the tasks that use the resource. Pull every task the resource is assigned to, with the hours assigned and the scheduled start and finish for each.
- Spread each task's hours across its periods. If a task is 40 hours over two weeks, that is 20 hours in each week. Do this for every task.
- Sum the hours per period. Add up all the tasks' hours in each week to get the total demand for that week. This is the loading.
- Add the capacity line. Enter the resource's available hours per period (40 for a full-time person, less if they carry other duties) and draw it as a line across the bars.
- Read the overshoots. Any bar above the line is an over-allocation. Note which weeks and by how much.
Repeat per resource, or stack the roles into one chart to see team-wide demand. For a whole portfolio rather than one project, the same logic scales up into the capacity view described in the capacity planning template, where supply and demand are compared across every project at once.
How to fix an over-allocated histogram
A histogram is a diagnosis, not a cure. Once it shows a bar above the capacity line, you have three honest options and one dishonest one. The dishonest option is to leave it and assume people will absorb the overload, which is how projects quietly slip and people quietly burn out. The three real options are to move work, add capacity, or cut scope.
Moving work is the most common. If a task has slack, you delay it into a period where the resource has room, which flattens the peak without pushing the end date. That is resource smoothing. If there is not enough slack and the overload cannot be absorbed inside the existing finish date, you extend the schedule to resolve it, which is resource leveling. The distinction between the two, and when each is the right call, is the subject of resource leveling vs smoothing. Adding capacity (bringing in another person) and cutting scope (removing lower-value work) are the levers you reach for when neither leveling nor smoothing can close the gap. Deciding which lever to pull across many projects at once is a portfolio-level judgment, covered in resource capacity planning for project portfolios.
Resource histogram vs Gantt chart
A Gantt chart and a resource histogram answer different questions, and mature plans use both. A Gantt chart shows when each task runs and how tasks depend on each other, laid out as bars along a timeline. It is the map of the work. A resource histogram shows how much demand all that work places on a given resource in each period. It is the map of the load. The Gantt tells you the sequence; the histogram tells you whether the sequence is staffable.
This is why a schedule can look perfectly reasonable on a Gantt chart and still be impossible. The Gantt happily shows six tasks running in parallel in the same week, because it does not care who does them. The histogram cares, and it will show that those six tasks all land on two people who cannot do the hours. Build the schedule on the Gantt, then check it on the histogram, then commit. The commitments the histogram validates are the ones you record in the resource management plan.
The capacity line is usually wrong
Most histograms are drawn against a capacity line of 40 hours, and that line is close to fiction. Forty hours is what someone is employed for, not what they can give a project. Once you subtract meetings, support duties, leave, and the administrative tail every job carries, the honest project capacity for a full-time person is usually somewhere between 26 and 30 hours a week.
That gap matters more than any other input on the chart. If you draw the ceiling at 40 when the real number is 28, you understate demand by roughly a third, and every histogram you produce will look healthier than the team feels. People will report being underwater while the chart insists they have room, and the chart will win the argument because it is on a slide.
| Deduction | Typical hours per week | Why it is not project time |
|---|---|---|
| Standing meetings and ceremonies | 3 to 6 | Stand-ups, planning, reviews, one to ones |
| Support and interrupt work | 2 to 6 | Production issues, questions from other teams |
| Leave, public holidays, sickness | 3 to 4 | Averaged across the year, not zero in any month |
| Administration and training | 1 to 3 | Timesheets, appraisals, mandatory training |
| Realistic project capacity | 26 to 30 | What is genuinely available to assigned tasks |
Swipe to see more →
Set the line from your own timesheet history rather than these bands, which are a starting point and not a measured constant. The single most useful improvement you can make to a histogram is not a better chart. It is an honest ceiling.
Peak demand, average demand, and the ratio that matters
Divide the tallest bar on the histogram by the average bar height and you get the peak to average ratio. It tells you something the raw bars do not: whether you have a staffing problem or a sequencing problem. A ratio near 1.0 means demand is level. A high ratio means the same total work has been crammed into a few periods and left the rest half empty.
This distinction decides what you should do next, and it is where a lot of money gets wasted. Teams look at a bar at 160 percent and start recruiting. But if the average across the project is 70 percent, the work does not need more people. It needs to be spread out. Hiring against a peak buys capacity that sits idle for the rest of the project and adds a person who has to be kept busy afterwards.
| Peak to average ratio | What the shape means | The right response |
|---|---|---|
| Under 1.2 | Demand is level and predictable | Nothing. If bars still exceed the line, you are genuinely short of people |
| 1.2 to 1.6 | Normal lumpiness from dependencies | Smooth within float; the plan is broadly sound |
| 1.6 to 2.5 | A sequencing problem wearing a staffing costume | Re-sequence before you recruit; look for artificial parallelism |
| Above 2.5 | Usually an artifact of the plan, not the work | Check the estimates and the dependencies before believing the chart |
Swipe to see more →
Run the ratio before any conversation about headcount. A team that cannot state its peak to average ratio is not yet in a position to argue that it is understaffed, because it has not separated how much work there is from when the plan asked for it.
Four histogram shapes and what each one is telling you
After you have built a few dozen of these, the outline of the bars becomes more informative than the numbers. Four shapes come up again and again.
| Shape | What you see | Usual cause | What to do |
|---|---|---|---|
| The spike | One or two bars far above the line, the rest low | Several tasks scheduled to start on the same date, often the start of a quarter | Stagger the starts; most of them have float nobody checked |
| The plateau at 100 percent | A long run of bars sitting exactly on the line | Numbers fitted to the ceiling rather than estimated | Treat as unverified; real work is never this tidy |
| The sawtooth | Alternating high and low bars week to week | Tasks sized to whole weeks against a schedule that runs in days | Usually harmless, but it hides real peaks; shorten the time unit |
| The late ramp | Load climbing steeply toward the end date | Optimistic early phases with the hard work deferred | The most dangerous shape; there is no float left to absorb a surprise |
Swipe to see more →
The plateau deserves the most suspicion. When a resource sits at exactly 100 percent for eight straight weeks, somebody has usually worked backward from the capacity line and filled in hours that make the chart pass review. Real assignments produce ragged bars. A histogram that is too neat has usually been negotiated rather than calculated.
The late ramp is the one that actually hurts. Every plan carries surprises, and surprises are absorbed by whatever slack remains when they arrive. A project that back-loads its demand has spent that slack in advance, so the first genuine problem in the final third has nowhere to go except the end date.
What a resource histogram cannot tell you
The chart aggregates hours, and hours are a lossy summary of people. Four assumptions are baked into every histogram, and each one fails in a way that makes the picture look better than reality.
| Built-in assumption | Where it breaks | What to check instead |
|---|---|---|
| Hours are interchangeable | Two people at 50 percent do not replace one specialist at 100 percent when only one of them holds the skill | Chart the scarce skill separately, not the role |
| A part-time person scales proportionally | Someone at 50 percent on two projects loses time to switching that neither project sees | Discount split assignments; treat 50 and 50 as nearer 40 and 40 |
| The estimates are right | A bar under the line built on optimistic estimates is still an overload | Compare estimated against actual hours on finished tasks |
| Availability is flat | Notice periods, ramp-up for new joiners, and phased returns are invisible | Drive capacity from the resource calendar, not a standing number |
Swipe to see more →
None of this makes the histogram less useful. It means the chart is a prompt for a conversation with the person whose name is on the bars, not a substitute for it. The most common failure is not a badly drawn histogram; it is a well-drawn one nobody discussed with the team it describes.
How often should you rebuild the histogram?
Rebuild it whenever the schedule changes materially, and at minimum once a fortnight during execution. A histogram built at planning and never refreshed describes a project that no longer exists, because every accepted change request, every slipped task, and every reassignment moves demand into a different period. Monthly is enough in slow-moving portfolios; weekly is right when a scarce specialist is the binding constraint.
The practical trigger is simpler than a cadence. If someone has changed a date, added scope, or moved a person, the histogram is stale. Most tools regenerate it in seconds, so the cost is not the chart. The cost is the ten minutes of reading it properly and acting on what it shows, which is the step teams skip.
Frequently asked questions
What is a resource histogram used for?
A resource histogram is used to check whether a schedule is actually staffable. By plotting the demand on a resource in each period against the capacity available, it shows where a plan asks for more hours than a person or team can supply. Project managers use it to spot over-allocation, balance workloads, and decide where to level or smooth the schedule before committing to dates.
What is the difference between a resource histogram and a resource loading chart?
There is almost no practical difference; the terms are used interchangeably. Strictly, resource loading is the underlying data, the number of hours each resource is booked for in each period, while the resource histogram or loading chart is the bar chart that displays that data. When someone asks for either, they usually want the same picture of demand over time against capacity.
How do you create a resource histogram?
List every task a resource is assigned to with its hours and dates, spread each task's hours across the periods it runs, then sum the hours per period to get total demand. Add the resource's available hours as a capacity line and plot the totals as bars. Any bar above the line is an over-allocation. A spreadsheet handles this in an afternoon, and scheduling tools generate it automatically.
Is a resource histogram the same as a Gantt chart?
No. A Gantt chart shows when tasks run and how they depend on each other along a timeline. A resource histogram shows how much demand those tasks place on a given resource in each period, against capacity. A schedule can look fine on a Gantt chart and still be unstaffable, which the histogram reveals. The two are complementary, not interchangeable.
Why is a resource histogram important for the PMP exam?
The resource histogram appears on the PMP exam because it is the standard tool for visualizing resource demand and identifying over-allocation, and it connects directly to resource leveling and smoothing. Candidates are expected to know that bars above the capacity line signal over-allocation and that leveling extends the schedule while smoothing uses slack. Understanding the chart is a prerequisite for the resource optimization questions.
The histogram is one piece of the wider job of putting real people against funded work. For the assignment mechanics that produce the loading in the first place, see resource allocation in project management, and for the two techniques that flatten the peaks it exposes, see resource leveling vs smoothing.