Resource loading: when it's worth it, when it isn't

Last reviewed 16 September 202611 min read

The one DCMA check where failing can be the right answer, and the labour-only middle path most projects need

🟩 In one line Resource loading attaches labour, plant or cost to activities so the schedule can produce a histogram and prove a plan is achievable. It is a maintenance commitment for the life of the project, not a one-off setup task — and a loaded programme that is never statused is worse than an unloaded one, because it produces an authoritative-looking histogram that is wrong.

👤 Who this is for Planners deciding at baseline stage whether to load, and how far. Anyone who has been told "the schedule fails DCMA check 10" and isn't sure whether that matters. Senior planners who have inherited a half-loaded file and need to decide whether to finish the job or strip it out.

e / c

First, let's be honest about why this page exists

Because resource loading is sold as a best practice and bought as a decision that has already been made.

Somebody reads DCMA check 10 — all remaining work should carry resource assignment — sees a fail, and starts loading. Nobody asks what the histogram is for, who will status the units every month, or whether the cost in the file will be reconciled against the cost in the commercial system. Four updates later the actual units column is all zeros on activities that are 60% complete, and the histogram in the monthly report shows a planned peak of 400 against an actual of nothing.

That is a worse position than never loading, and it is common.

The honest position is that an unloaded schedule is a legitimate design decision. Plenty of well-run projects run the programme unloaded and control cost and manpower in separate systems, deliberately, and say so in the basis memorandum. What is not legitimate is running unloaded by accident, or loading at baseline and never touching it again.

So this page is mostly a decision, not a how-to. Decide, write the decision down, and then either commit to the monthly discipline or don't start.

🟨 The standard — what "good" looks like

Resource loading is the assignment of labour, non-labour (plant) or material resources, and optionally cost, to schedule activities, such that the schedule can report resource demand over time (a histogram) and cumulative demand (an S-curve).

Resource levelling is a separate operation: adjusting dates so that demand does not exceed availability. Loading does not imply levelling, and most projects should do the first without the second.

Source	What it says
DCMA 14-point, Metric 10	All remaining activities with duration should carry a resource or cost assignment. Worded as a check; best read as a question about whether the approach was chosen deliberately.
GAO-16-89G, Best Practice 5	Assigning resources to activities — and, importantly, the conditions under which it adds value rather than overhead.
PMI Practice Standard for Scheduling, 3rd ed.	Resource assignment, levelling, and the effect of both on calculated dates.
AACE RP 25R-03	Why a loaded baseline is the only way the planned half of a future disruption comparison can exist.
Typical Gulf specifications	Frequently require a manpower histogram and an S-curve with every submission, which in practice requires labour loading whether or not the word is used.

🟢 Rule: load if the contract requires a histogram or S-curve, if manpower is the binding constraint on the programme, or if a disruption claim is a realistic prospect. If none of those is true and nobody has committed to statusing units monthly, do not load — and write the decision and its reasons into the schedule basis memorandum so the next reviewer sees a choice rather than an omission.

How it actually works

What loading actually buys you

Four things, worth naming separately because most projects need only two of them:

A defensible manpower histogram. The most commonly required deliverable in the Gulf. A histogram drawn in Excel alongside the programme drifts from it within two updates. One generated from the schedule cannot.
Proof that the plan is achievable. A duration built on a crew of 30 is only credible if the histogram shows 30 people on site on that date and the workface can hold them. Loading is what connects the duration build-up to the resource plan.
The planned half of a disruption argument. Planned man-hours against actual man-hours, by period and area, is the raw material of nearly every disruption claim. Without a loaded baseline the planned side does not exist and cannot be created afterwards.
Earned value. Only meaningful where the schedule and the cost model share the same breakdown structure — which is less common than it sounds.

What it costs you

The cost is not setup. It is every update, forever.

Statusing roughly doubles. Every update now needs actual units as well as actual dates, from a source that is usually a different department with a different deadline.
Wrong assignments corrupt the histogram silently. Units-per-time entered at the wrong rate produces a peak nobody can explain, and a reviewer will find it before you do.
Cost in the schedule conflicts with cost in the commercial system. Two numbers for the same thing, diverging monthly. That reaches senior people quickly and never reflects well on the programme.
Duration changes don't recalculate units the way people expect. Depending on the duration type, changing a duration changes either the units or the units-per-time — and it is always the one you weren't thinking about.

The middle path most projects should take

Load labour only. No plant, no materials, no cost.

Create one resource per trade — steel fixer, carpenter, mason, electrician, pipe fitter — as labour resources with no cost rate attached. Assign them to construction activities at the crew sizes used in the duration build-up. Leave engineering, procurement and approval activities unloaded, or loaded only where a real named team is committed.

What this gets you:

	Unloaded	Labour only	Fully loaded
Manpower histogram	No	Yes	Yes
Achievability proof	No	Yes	Yes
Disruption baseline	No	Yes	Yes
Cost S-curve from the schedule	No	No	Yes
Earned value in P6	No	No	Yes
Cost reconciliation risk	None	None	High
Monthly statusing burden	Baseline	~1.5×	~2×

Labour-only is also, in practice, what most Gulf consultants actually want when they ask for resource loading. Confirm what the specification requires before building anything more elaborate — the answer is often "a manpower histogram", which labour-only delivers at half the cost of full loading.

Should you level?

Usually not. And if you do, keep a copy of the file from before you did.

Levelling changes dates according to resource availability rather than logic. Three consequences follow, all difficult to manage on a live project:

The dates move for a reason that isn't visible on the bar chart. An activity has slipped three weeks and no relationship explains it. Anyone reviewing the file — including you, in four months — cannot reconstruct why.
The critical path becomes resource-driven. The longest path stops describing a chain of physical dependencies, the critical path test behaves unpredictably, and the driving path narrative becomes very hard to write.
Results are sensitive to undocumented settings. Priorities, availability curves and levelling options are rarely recorded. Re-running the same file next month with the same data can produce different dates.

The better alternative is to use the histogram diagnostically rather than mechanically: load, look at the peaks, and fix the peaks by changing logic, splitting activities or re-sequencing areas — decisions a person makes and records. The dates then move for reasons visible in the file.

🟥 Where people go wrong

1. Loading and then never statusing units. The one that matters most. It passes check 10 mechanically while failing it entirely in spirit, and it produces an actuals histogram of zero against a planned peak of 400. That has been spotted in a monthly meeting more than once, and it is not a good meeting.

2. Loading level-of-effort activities. Supervision, site management and LOE bars carry resources too, and the histogram double-counts them against production. Load production activities only, and keep LOE resources — if you need them at all — on a separate resource so they can be filtered out.

3. Loading after baseline approval. Now the baseline histogram doesn't match the current one, and every variance report has an explanation nobody can follow. Load before baseline, or issue a formal revision — see baseline approval and control.

4. Putting cost in the schedule when the commercial team already has it. Two systems, two numbers, monthly divergence, and a conversation at director level about which one is right. If cost loading is genuinely required, agree in writing which system is authoritative before loading anything.

5. Wrong units-per-time. Eight masons at 8 h/day is 64 units/day, not 8. Get this wrong on a few hundred activities and the histogram is wrong in a way that looks plausible. Spot-check the total man-hours against the estimate before the first submission.

6. Letting remaining units drift after duration changes. Change a duration on a fixed-units activity and the units-per-time moves; on a fixed-units/time activity the total units move. Either way, the man-hour total quietly diverges from the build-up it came from. Reconcile monthly, not at the end.

7. Treating check 10 as a defect to be cured. It is the one metric in the fourteen where a considered "no" is a valid answer. Failing it with a written rationale is fine. Failing it because nobody thought about it is not.

⚖️ When you're challenged

"Your schedule fails DCMA check 10." "It does, deliberately. Manpower is controlled in the labour system and cost in the commercial system, and the approach is set out in section 6 of the schedule basis memorandum. If the specification requires a schedule-generated histogram I'll load labour — it's about a week's work — but I'd want the statusing route agreed first, because a loaded schedule nobody statuses is worse than this one."

"Can you level the programme so the peak comes down?" "I can, and the dates will move for reasons that won't be visible in the file. I'd rather fix the peak by re-sequencing — same result, and next month I can still explain why every date is what it is. Let me show you the histogram with the two options side by side."

"The histogram shows 400 planned and zero actual." "Correct, and that's a statusing gap, not a progress problem. Units haven't been fed back since update 3. Either we start collecting actual hours against activity codes, or we strip the resources out and report manpower from the labour system. Both are defensible; the current position isn't."

"The cost curve in the programme doesn't match the commercial forecast." "They're built from different structures and updated on different cycles, so they will always diverge. I'd suggest we remove cost from the schedule and generate the cash flow from the commercial model instead — one number, one owner."

"Why aren't the engineering activities loaded?" "Because the design team isn't committed by name and the hours would be invented. Loading them would make the histogram look more complete and be less true. If you want them in, I'll need the resource plan from the design manager first."

📄 Related pages

Resource loading and histograms — the mechanics, once you've decided to load
Resource levelling — what levelling does to dates, in full
Manhour budget and productivity tracking — where the actual units have to come from
Justify a duration — the crew sizes that should drive the assignments
P6 duration types explained — why a duration change moves the units you weren't watching
Cost loading and cash flow — the case for and against cost in the file
Schedule basis memorandum — where the loading decision gets written down

✏️ Worked example

Structure package, 24-storey residential tower. Six-day calendar, 8 h/day. The planner is deciding what to load.

What the specification actually asks for: a monthly manpower histogram by trade and a cumulative S-curve of planned versus actual progress. Nothing about cost.

The decision: labour only, five resources, production activities only.

Resource	Assigned to	Crew	Units/day	Not assigned to
Steel fixer	Rebar activities	12	96	Rebar material delivery
Carpenter	Formwork activities	16	128	Formwork design approval
Concrete gang	Pour activities	8	64	Concrete mix approval
Mason	Blockwork activities	10	80	—
General labour	Cleaning, access, edge protection	6	48	Site supervision (LOE)

The check before submission. Total labour man-hours in the schedule against the estimate:

Trade	Estimate (mh)	Schedule (mh)	Variance
Steel fixer	41,200	40,320	−2.1%
Carpenter	58,000	57,344	−1.1%
Concrete gang	14,500	16,128	+11.2%
Mason	33,000	32,640	−1.1%
General labour	19,000	18,816	−1.0%

Four trades within 2%. One at +11%. That row is the whole reason for doing this check. Investigating it finds that the concrete gang has been assigned to the cure activities as well as the pours — eight men standing next to a slab for three days. Remove the assignment from cure and the variance falls to −0.4%.

If that check had not been run, the histogram would have shown a concrete peak roughly 11% too high for the life of the project, every month, on every submission — and the first person to notice would have been the reviewer.

The line in the basis memorandum:

The programme is labour-loaded only. Five labour resources are assigned to production activities at the crew sizes used in the duration build-up (Appendix B). No cost or material resources are assigned; cash flow is produced from the commercial cost model. Level-of-effort and approval activities are unloaded. Total assigned man-hours reconcile to the labour estimate within 2% by trade. The programme is not levelled; peaks are managed by re-sequencing and are recorded in the monthly narrative.

Five sentences, and it answers every question a reviewer would otherwise raise about check 10.

📖 References

DCMA, 14-Point Schedule Assessment — Metric 10 (Resources)
US GAO, Schedule Assessment Guide (GAO-16-89G, 2015) — Best Practice 5, assigning resources to activities
PMI, Practice Standard for Scheduling, 3rd ed. (2019) — resource assignment, levelling, and their effect on dates
AACE International RP 25R-03, Estimating Lost Labor Productivity in Construction Claims — why planned-versus-actual labour records underpin disruption analysis

From the field

Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.

Loading notes…

Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.