Resource Optimization

Schedule technique · See it on the map

Runnable here

Adjusting the schedule to fit real resource limits, either by delaying work or shifting it within slack.

When to use it

Use leveling when a resource is genuinely over-allocated — assigned to more work than it can do in the available time — and the schedule has to accept a later finish to reflect reality. Use smoothing when the resource picture is merely lumpy (idle some weeks, overloaded others) but the total demand fits within capacity, and you want to flatten the peaks without touching the finish date.

When to avoid it

Don't reach for smoothing when the resource is actually over-allocated — smoothing has no slack to work with once every non-critical task is already fully used, and forcing it there just hides an over-allocation the schedule needs to show. And don't apply either technique without first confirming the resource conflict is real and not an artifact of an out-of-date assignment list.

Steps

1. Chart resource demand against resource availability across the schedule to see where allocation exceeds capacity and where it doesn't.
2. For a genuine over-allocation, apply leveling: delay or re-sequence the lower-priority task competing for the resource, accepting that this may push the project's finish date or consume float on tasks that had some.
3. For a lumpy-but-feasible demand curve, apply smoothing instead: shift non-critical tasks only within their existing float, flattening peaks without changing the finish date.
4. Re-check the critical path after leveling specifically — moving a task to resolve resource contention can create a new critical path that didn't exist in the logic-only network.

What it produces

• A resource-feasible schedule, with a record of which adjustments were leveling (finish date affected) versus smoothing (finish date untouched), so the impact on the commitment date is traceable rather than buried in a re-sequenced Gantt chart.

Common pitfalls

• Leveling and smoothing get used interchangeably in conversation, so a stakeholder is told "we smoothed the schedule" when what actually happened was leveling that pushed the finish date — a quiet, easily missed commitment change.
• Leveling resolves the over-allocation on paper by assigning the resource to impossible overlapping hours in practice, because the adjustment was made to the chart without checking the resource's actual calendar.
• Smoothing is applied repeatedly across many small adjustments without anyone re-checking the critical path, and one of those "just using slack" moves quietly eats float that another task needed.

Worked example

One structural engineer is assigned to both a bridge inspection report (due in three weeks, has two weeks of float) and a foundation redesign (due in three weeks, zero float) in the same week. Leveling delays the inspection report by one week, consuming its float and leaving the finish date for that deliverable unchanged but shifting when it's produced. Separately, the same engineer's workload on two other non-critical tasks is smoothed — moved a few days later within their existing slack — purely to avoid a workload spike, with no effect on either task's due date.

Source

• PMBOK-6 §6.5.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.