Schedule updates, progress measurement and recovery

A baseline schedule is a forecast made before the work starts. From the first day on site, reality begins to differ from it: some activities start late, some go faster, deliveries slip, changes add work. Updating the schedule is how the project keeps its forecast honest. A good update records what actually happened, re-forecasts what remains, shows whether the completion date is still achievable, and identifies where action is needed. This lesson covers the update process, the data date, methods of measuring progress, delay identification, time impact analysis and recovery schedules.

The update cycle

Most construction schedules are updated monthly, often timed to the progress payment cycle, and many projects also update look-ahead schedules weekly. A typical monthly update follows these steps.

• Set the data date, the date up to which progress is recorded and from which the remaining work is scheduled.
• Collect progress: actual start and finish dates, remaining durations and percent complete for activities in progress, from the superintendent, foremen and trade contractors.
• Record changes: add activities for new scope or changes, adjust logic where the plan has genuinely changed, and note delays and their causes.
• Recalculate the schedule from the data date.
• Compare the update with the baseline and the previous update: has the forecast completion moved? Has the critical path changed? Which activities slipped, and why?
• Write the narrative, explaining progress, the critical path, delays, logic changes and corrective actions.
• Submit and discuss the update with the owner and the team.

The narrative is as important as the schedule file. A reviewer looking at a forecast completion date that has moved two weeks needs to know why: weather, a late delivery, an owner change, or a productivity problem. Without the narrative, the update is a collection of numbers.

The data date

The data date, also called the status date or time-now, divides the past from the future. Everything to its left is history: actual starts, actual finishes, completed work. Everything to its right is forecast: remaining durations scheduled by logic from the data date forward. Two rules follow, and violating either is a common error that the DCMA assessment calls invalid dates.

• No actual date can fall after the data date: work cannot have finished in the future.
• No forecast date can fall before the data date: unfinished work cannot be scheduled in the past.

When an activity was supposed to start before the data date but has not, the update pushes it to start at the data date or later. This is how slippage appears: the forward pass from the data date shows the true remaining schedule.

Measuring percent complete

For activities in progress, the update needs a measure of how much work is done. Several methods are used, chosen according to the type of work.

Percent complete and remaining duration are related but not the same. An activity can be 50 % complete in quantity but need more than half its original duration to finish, because the remaining work is harder, the crew has shrunk or productivity has dropped. Good practice is to estimate the remaining duration directly, by asking how many more working days are needed, rather than calculating it from the percent complete.

Comparing updates with the baseline

Each update should be compared with the baseline and with the previous update. Useful comparisons include:

• Change in forecast completion date and in float on the critical path.
• Changes in the critical path itself: which activities joined or left it, and why.
• Activities that started or finished late compared with the baseline.
• Planned versus actual progress, by count of activities (as in the DCMA baseline execution index), by labour-hours or by earned value.
• Logic and duration changes made since the previous update, which should be listed and explained in the narrative.

A simple but revealing chart plots the forecast completion date at each update. A line that drifts later month after month, a few days at a time, tells a story that a single update does not.

Earned schedule at a glance

Earned value management, covered in the cost control course (CON-310), measures progress in money or labour-hours. A related technique called earned schedule expresses schedule performance in time units, which many schedulers find easier to interpret. Earned schedule finds the date at which the work actually done should have been done according to the baseline. Comparing that date with the actual time gives a schedule variance in days and a schedule performance index that stays meaningful to the end of the project.

Here ES is the earned schedule, the baseline time at which the current earned value should have been reached, and AT is the actual time elapsed. (In this formula ES means earned schedule, not early start.)

Identifying and analysing delays

Not every late activity is a delay to the project, and not every delay is the contractor's responsibility. Delays are usually classified in two ways.

• By effect: critical delays move the completion date; non-critical delays consume float but do not move completion.
• By responsibility: excusable delays, caused by events outside the contractor's control such as owner changes or unusually severe weather, may entitle the contractor to more time; excusable and compensable delays, typically caused by the owner, may also entitle it to money; non-excusable delays, caused by the contractor, entitle it to neither and may expose it to liquidated damages.
• Concurrent delays, where owner-caused and contractor-caused delays affect completion over the same period, are treated differently by different contracts and jurisdictions, and are a frequent subject of dispute.

CCDC 2-2020 Part 6 deals with delays: GC 6.5 provides for an extension of the Contract Time where the contractor is delayed by the owner, the consultant or their agents, by stop-work orders, or by causes beyond the contractor's control such as labour disputes, fire or unusual delay by common carriers, subject to timely written notice. The notice requirements are strictly applied in many cases, so the schedule narrative and correspondence must record delays as they happen.

Time impact analysis

When a change or delay event occurs, many contracts require a time impact analysis (TIA) to support any request for more time. The analysis is prospective: it uses the most recent accepted update, inserts a fragment network, or fragnet, representing the change or delay, recalculates, and measures the effect on completion.

Recovery schedules

When an update shows that the project will finish late through the contractor's own delays, or the owner directs acceleration, the contractor prepares a recovery schedule: a revised plan showing how the lost time will be made up. Recovery uses the tools of Lessons 7 to 9: compressing critical activities, resequencing, adding crews or shifts, overlapping work, and changing methods. A credible recovery schedule is specific: it names the activities that will be shortened, the extra resources, the cost, and the risks, and it is checked by the people who must carry it out.

Contracts distinguish between acceleration that the contractor undertakes at its own cost to recover its own delays, directed acceleration that the owner orders and pays for, and constructive acceleration, where the owner refuses a justified time extension and so effectively forces the contractor to accelerate. The last is a common source of claims, discussed in CON-420.