Project Scheduling Techniques: CPM, Resource Levelling and Why Schedules Fail

A planning engineer I worked with on a large civils programme had a phrase he used every time someone handed him a schedule that looked optimistic: “Show me the logic.” Not the dates. Not the milestones. The dependency logic underneath. Because a schedule without solid logic isn’t a plan — it’s a list of dates someone has committed to without understanding what drives them. I’ve seen project scheduling techniques applied badly on enough projects to know that the failure mode is almost never the technique itself. It’s the shortcuts: activities without dependencies, durations plucked from thin air, baselines that never get set, resources that were assumed rather than confirmed. This article covers the techniques that actually work — and the points in each where projects typically go wrong.

What Project Schedule Management Actually Requires

Project schedule management is more than building a Gantt chart. It covers the full cycle: defining activities, sequencing them, estimating durations and resources, developing the schedule, and then controlling it as the project runs. PMBOK structures this as six processes — Plan Schedule Management, Define Activities, Sequence Activities, Estimate Activity Durations, Develop Schedule, and Control Schedule. In practice these aren’t linear. You sequence activities and discover you’re missing activities. You estimate durations and find the critical path is unacceptable. You develop the schedule and realise the resource assumptions were wrong. Iteration is normal. The mistake is treating schedule development as a one-time activity done at project initiation and then locked.

The schedule is a model of how the project will be delivered. Like any model, it’s wrong. The question is whether it’s wrong in ways that matter for the decisions being made. A schedule that correctly identifies the critical path, correctly reflects the key dependencies, and is built on durations that the people doing the work consider achievable — that schedule is useful even if individual activity durations are off by 20%. A schedule where the critical path is wrong, major dependencies are missing, and durations were set by a planner without input from the delivery team — that schedule is useless regardless of how many activities it contains.

Project Scheduling Steps in the Right Order

The project scheduling steps that most guides describe are correct in principle but routinely applied in the wrong sequence in practice. The most common mistake is building the Gantt chart before the work breakdown structure is complete. Activities that appear on the schedule but don’t trace back to a WBS deliverable are either redundant or represent scope that hasn’t been formally agreed. Either way, the schedule is unreliable before it’s been used.

The sequence that produces a reliable schedule: define the scope through the WBS first; decompose deliverables to work packages; convert work packages to schedule activities; sequence activities based on dependencies; estimate durations with input from the people doing the work; apply resources and check for conflicts; calculate the critical path; compress if the end date is unacceptable; baseline; then maintain.

Two steps are skipped more often than any others. First, getting duration estimates from the delivery team rather than from historical data or the planner’s judgment. Delivery teams have knowledge planners don’t — about access constraints, weather sensitivity, lead times for specific materials, the realistic productivity of the particular workforce on this type of work. A planner who builds a programme alone and hands it to the delivery team is building a schedule that the team will immediately work around rather than to. Second, baselining. Without a frozen baseline, there’s no reference point for measuring schedule performance. The schedule just becomes whatever the current plan says, which makes it impossible to determine whether the project is recovering or just re-planning.

Critical Path Method in Project Scheduling Techniques

The Critical Path Method is the foundation of most project scheduling techniques used on construction, infrastructure and engineering projects. It calculates the longest sequence of dependent activities from project start to finish — the critical path — which determines the earliest possible completion date. Any delay to a critical activity delays the end date. Activities off the critical path have float — they can be delayed without affecting the end date, up to the amount of their total float.

CPM is the backbone of most project scheduling techniques used on complex projects. The Critical Path Method was developed in the late 1950s, jointly by DuPont and Remington Rand and separately by the US Navy’s Polaris programme (which called their version PERT). It’s been the standard planning technique for complex projects ever since — not because it’s perfect, but because it makes the logic of the schedule explicit and calculable. The critical path can be calculated, compared, and updated. Without CPM, “which activities are most important to protect” is a judgment call. With it, it’s a calculation.

Forward Pass, Backward Pass and Float in Project Scheduling

The CPM calculation runs two passes through the network. The forward pass calculates the earliest start and finish for each activity, working from the project start forward. The backward pass calculates the latest start and finish for each activity without delaying the project end date, working backward from the project finish. Total float is the difference between earliest and latest start (or finish) — the amount of time an activity can slip without delaying the end date. Free float is how much an activity can slip without delaying its immediate successors.

Activities with zero total float are critical — they’re on the critical path. Activities with near-zero float are near-critical and need monitoring almost as carefully as critical activities, because small delays can make them critical. On a large programme with hundreds of activities, there are usually several near-critical paths that could become the critical path if a few activities slip.

The planning engineer I mentioned at the outset had a specific test he ran on every schedule before signing it off: he’d look at the total float histogram — the distribution of float across all activities — and check whether any activity had suspiciously large float. Large float on an activity that should be constrained often means a missing dependency. An activity that appears to have six weeks of float because nobody modelled the constraint that actually ties it to another sequence. These missing dependencies are the most dangerous schedule errors because they make the critical path wrong — the programme shows contingency that doesn’t exist.

PERT and Three-Point Estimating in Project Scheduling Techniques

PERT — Programme Evaluation and Review Technique — was developed by the US Navy in the 1950s alongside CPM. Where CPM uses single-point duration estimates, PERT uses three: optimistic (O), most likely (M), and pessimistic (P). The PERT estimate combines them as (O + 4M + P) / 6, which weights the most likely estimate heavily while reflecting the range of possible outcomes.

Three-point estimating is the broader application of the same principle without the specific PERT formula. The triangular distribution uses a simple average: (O + M + P) / 3. The beta distribution (the PERT formula) weights the most likely estimate more heavily, which usually produces a more realistic result when the most likely scenario is genuinely more probable than the extremes. On a project where duration uncertainty is significant — new technology, unfamiliar site conditions, regulatory processes with unpredictable timelines — three-point estimating makes the uncertainty explicit rather than hiding it inside a single-point estimate that’s been padded to account for the uncertainty anyway.

The problem with PERT in practice: the three estimates are only as good as the estimation process. If the optimistic estimate is “if nothing goes wrong” and the pessimistic estimate is “if everything goes wrong,” and the most likely estimate is somewhere in the middle, the formula produces a weighted average that may have no relation to what the activity will actually take. The estimates need to reflect specific, identified scenarios rather than vague optimism and pessimism. “Optimistic: ground conditions match the survey report. Pessimistic: ground conditions match what happened on the adjacent plot last year.” That’s a useful range. “Best case: fast. Worst case: slow.” It’s not.

Resource Levelling and Smoothing: Critical Project Scheduling Techniques

A schedule that’s logically correct and has an acceptable end date can still be undeliverable if the resource demand it implies is impossible to meet. Resource levelling and resource smoothing are the two techniques for resolving resource conflicts — situations where the schedule requires more of a resource than is available.

Resource levelling

Resource levelling resolves over-allocation by delaying activities until the resource is available. It often extends the project end date. The algorithm works by pushing non-critical activities into their float to reduce peak resource demand, then — if that’s insufficient — delaying critical activities and accepting schedule extension. Resource levelling is the correct approach when the resource constraint is hard — when there genuinely isn’t more resource available and the schedule has to flex around it.

On a civils programme in the East Midlands I was involved with — groundworks subcontract, about a £4m package — the original programme had three excavation activities running in parallel during weeks six through nine. The resource histogram showed peak demand of four excavators simultaneously. The subcontractor had two. When I pointed this out during a schedule review, the response was that they planned to hire additional plant. When I asked whether the hire had been confirmed, it hadn’t. The schedule had been built assuming resource that didn’t exist yet. Resource levelling the schedule against confirmed plant showed the three parallel activities needed to run sequentially, extending the package by three weeks. That three-week extension was always going to happen — the schedule just hadn’t shown it.

Resource smoothing

Resource smoothing adjusts activity timing within available float to reduce resource peaks without extending the end date. It doesn’t resolve over-allocation — it only works when the float is sufficient to absorb the smoothing. It’s appropriate when the schedule end date is fixed and resource peaks need to be managed within that constraint. The distinction matters: levelling extends the schedule, smoothing doesn’t. On a project with a contractual completion date, smoothing is usually the only option — the question is whether the float available is sufficient to achieve an acceptable resource profile.

Baselining and Schedule Control in Project Schedule Management

The baseline is the approved version of the schedule — frozen at a point in time — against which actual performance is measured. Without a baseline, project schedule management becomes reactive rather than analytical. You can see the current plan but not whether the project has slipped from the original. Every schedule update looks like a schedule, but none of them tells you whether the project is performing or just re-planning.

Baselining should happen once the schedule has been reviewed and approved by all parties who need to agree to it — sponsor, client (if applicable), key subcontractors, and the delivery team. Baselining before that agreement means the baseline doesn’t represent the authorised plan. Baselining after significant work has started means the baseline is already wrong.

Once baselined, the schedule should only be re-baselined when the project scope changes through the formal change control process. Programme updates — adjustments to the current plan to reflect revised activity sequences or durations — are normal and expected. Re-baselining to hide slippage is a governance failure. I’ve reviewed programmes where the baseline had been re-set three times in six months, each time absorbing the accumulated delay into the new “approved” baseline. By the time anyone external looked at the schedule, it showed green performance against a baseline that had been moved repeatedly to stay ahead of the actuals. Schedule variance was zero not because the project was on track but because the baseline was chasing the current plan.

Schedule performance measurement

Schedule performance in earned value management is measured through Schedule Variance (SV = Earned Value − Planned Value) and Schedule Performance Index (SPI = EV / PV). SPI below 1.0 means the project is behind schedule — it has earned less value than was planned for this point. SPI above 1.0 means ahead. These metrics are only meaningful against a stable baseline. Against a moving baseline they tell you nothing.

Project Scheduling Techniques in Agile Environments

Agile environments handle project scheduling differently — not because scheduling doesn’t matter, but because the nature of the work makes detailed long-range activity planning unreliable. In a Scrum framework, the sprint is the scheduling unit. The sprint backlog is planned at the start of each sprint based on the team’s velocity. The release plan shows the expected delivery of features across sprints, but is updated at each sprint review rather than fixed at project initiation.

The tension between agile scheduling and traditional project scheduling techniques surfaces on hybrid projects — programmes with a fixed delivery date, a fixed budget, and a client expecting milestones, but using agile development methods internally. The delivery team works in sprints; the client reports against milestones. Reconciling these requires a planning layer between the sprint level and the programme level — typically a release roadmap showing which features will be delivered by which milestone, updated regularly based on actual sprint velocity. Getting this wrong produces a programme that looks agile to the team and waterfall to the client, and satisfies neither.

Why Project Scheduling Fails

The failure modes are consistent enough that they’re worth naming explicitly.

Missing Dependencies: The Most Dangerous Project Scheduling Error

The most dangerous schedule error. An activity with a missing dependency appears to have float it doesn’t have. The critical path is wrong. The project delivers against a schedule that was never achievable, and the slippage emerges late — when there’s little time to recover and the remaining float has already been consumed by earlier delays.

Durations estimated without the delivery team

A planner who estimates durations alone is estimating without the knowledge that the delivery team holds about access constraints, productivity rates, lead times, and site-specific conditions. The resulting schedule will be wrong. The delivery team will know it’s wrong. They will work to their own informal plan rather than the official schedule, and the schedule will stop being updated because nobody believes it.

No baseline

Without a frozen baseline, schedule performance can’t be measured. Updates look like plans. Slippage is invisible until the end date is breached.

Schedule Compression: A Risky Project Scheduling Technique

When the initial schedule end date is unacceptable, the instinct is to compress durations across the board — shorten everything by 10%, add more resources. This often produces a schedule that looks acceptable but isn’t achievable. The right approach is to review the logic first: are there missing fast-track opportunities? Parallel sequences that were modelled sequentially because that’s how they were done last time? Duration assumptions that haven’t been challenged? Compression applied to correct logic is legitimate. Compression applied to an already optimistic schedule just makes the eventual slippage larger.

Tool	Best for	Limitations
Microsoft Project	Mid-to-large projects; resource loading; baseline comparison; EVM	Steep learning curve; expensive licences; overkill for simple projects
Oracle Primavera P6	Major capital programmes; enterprise resource management; multi-project	Complex; requires specialist knowledge; significant implementation cost
Microsoft Excel	Simple projects up to ~50 activities; communicating schedule to non-planners	No automatic dependency calculation; manual update required; errors compound
Asta Powerproject	UK construction and infrastructure; NEC contract management	Less common outside UK; limited agile support
Jira / Linear	Software development; sprint planning; backlog management	Not suitable for CPM or resource-loaded schedules; limited milestone tracking

For more on how scheduling connects to the broader project planning toolkit, see the articles on the critical path method, total float and free float, schedule compression, and the lead and lag times article. The PMI PMBOK Guide covers all six schedule management processes in the schedule management knowledge area.