Resource levelling vs smoothing: one engineer, two tasks
Both tasks can start on day zero. Both need the same engineer. Compare moving work within float with a plan that actually fits the available person.
The schedule shows two configuration tasks running together. Neither needs the other to finish first. There is no dependency error, but both have been assigned to the same engineer for a full working day.
The work is allowed to overlap. The person cannot do both assignments at once.
Resource levelling adjusts dates to fit resource availability and may move the project finish. Resource smoothing uses float to spread resource demand while keeping the scheduled finish. Float is how far a task can move without delaying the relevant finish under the current dependencies.
PMI's project-management lexicon distinguishes the two techniques. The Association for Project Management describes the practical choice: whether the finish date or the resource limit takes priority.
Neither technique makes an unavailable person appear. The schedule needs to show the consequence of the choice.
Start with the work and the shared person
Our fictional project must configure two independent interfaces before a readiness milestone. A takes four working days and B takes two. Each needs one qualified engineer for eight hours per day, throughout its duration.
Both can start at elapsed working day 0. The milestone occurs when both are complete. There are no other tasks, weekends or waits in this small example.
| Activity | Duration | Daily assignment | Earliest interval without checking resources |
|---|---|---|---|
| Interface A | Four working days | One engineer, eight hours | Day 0 to day 4 |
| Interface B | Two working days | One engineer, eight hours | Day 0 to day 2 |
| Configuration ready | Zero-duration milestone | Both interfaces complete | Day 4 |
The dependency-only calculation finishes at day 4. B can move to days 2–4 without delaying that milestone, giving it two days of float in this network.
There is only one engineer available. The first two days of the earliest plan require 16 engineer-hours per day against eight available. A valid set of links has produced an infeasible assignment.
The project dependencies note explains why overlapping bars don't establish that the people or equipment are available. This example follows that resource check through to the dates.
Moving B within float leaves the conflict
Move B from days 0–2 to days 2–4. The milestone still lands at day 4. This stays within B's float, so it respects the timing boundary used for smoothing.
A is still running during days 2–4. Those two days now contain the same 16-hour requirement that previously appeared at the start.
The conflict has moved. Peak resource demand is still two engineers. Calling the plan “smoothed” doesn't make it feasible for one.
Levelling around one engineer moves the milestone
Keep A first, then schedule B after it. A occupies days 0–4 and B days 4–6. The readiness milestone moves to day 6.
There is no overload: each working day requires eight engineer-hours, matching the available person. Both tasks retain their original duration and scope.
Check the effort against the available time
A: 4 days × 8 hours = 32 engineer-hours
B: 2 days × 8 hours = 16 engineer-hours
Total: 48 engineer-hours
One engineer for four days: 4 × 8 = 32 available hours
One engineer for six days: 6 × 8 = 48 available hours
Within these assumptions, four days cannot contain 48 hours of work from a person providing eight hours per day. Moving the bars inside that window won't close the 16-hour gap.
The day-6 plan changes the forecast. It doesn't approve a later commitment. If day 4 is required, the team needs a decision about capacity, scope, method or the date.
Compare the dates and daily load together
All three plans remain visible below. Changing the available capacity tests whether a second suitably qualified engineer would remove the conflict. It doesn't shorten either task.
Same work and links, different daily assignments
Can the assigned people do the work?
A needs four full engineer-days; B needs two. Both must finish for the milestone. Eight working hours per engineer-day.
Available each working day8 hours1 qualified person, eight hours each
Shown plans within that capacity1 / 3All require the same 48 engineer-hours
Scroll sideways to compare all three schedules and their daily loads.
The within-float move shifts the overload
Moving B to days 2–4 keeps the day-4 finish but still needs 16 hours per day during the overlap. Sequencing A then B fits one person and moves the milestone to day 6.
| Plan | A interval | B interval | Finish | Overload days |
|---|---|---|---|---|
| Earliest dates | 0–4 | 0–2 | Day 4 | 2 |
| Move within float | 0–4 | 2–4 | Day 4 | 2 |
| One-person sequence | 0–4 | 4–6 | Day 6 | 0 |
Resource and float assumptions
The milestone requires both tasks. Each has a constant full-day assignment and cannot be split or shortened by adding people. Under dependency-only dates, A has no float and B has two days before the day-4 finish. The within-float alternative uses all of B’s float. The serial plan deliberately keeps A first.
The axis uses working time with no weekends or other tasks. The result is a small feasibility comparison, not approval for an extended deadline or an optimised full-project schedule.
With two qualified engineers available for these tasks, the original four-day plan fits this resource model. The serial six-day plan also fits, but takes longer. With one engineer, only the serial option shown avoids overload.
This doesn't mean levelling always extends a project. Some networks have enough float and alternative assignments to remove a conflict without moving the finish. It also doesn't mean smoothing always removes every overload. The available timing flexibility may be too small.
Choose which constraint can change
| Situation | What to investigate |
|---|---|
| Resource availability is fixed | A feasible sequence and the resulting finish date |
| Finish date is fixed | Movements within float, eligible capacity or a revised work approach |
| Both are fixed and the work doesn't fit | An explicit decision about the unresolved gap |
Check qualifications, calendars and other assignments before assuming a second person is usable. A two-day task doesn't necessarily become a one-day task when two people join it. In this example, the extra person works on the other independent interface instead.
Vrolen's production scheduling guide applies the same availability check to factory schedules, where people, machines, materials and tooling must be ready together. Its production example is separate from these project tasks.
The critical path worked example explains the dependency calculation behind the original finish. After changing resource assignments, review that network and the affected milestones again. Don't keep quoting float from an old plan as if the resource decision changed nothing.
When the forecast conflicts with an approved commitment, use the change-control process to present the alternatives and their consequences.
Bring the task bars and daily resource load to the same review. Our engineer's availability changes the answer from four days to six. The calendar should show that before the team is asked to deliver it.
Sources
- Project Management Institute. PMI Lexicon of Project Management Terms, version 5.0, printed page 24. Resource levelling and smoothing definitions.
- Association for Project Management. Resource smoothing and resource levelling. Time-limited and resource-limited scheduling.
All tasks and assignments are fictional. The comparison covers only these two activities, rather than a full project.