M2.4 — Progress Updating & Schedule Control

M2.4 — Progress Updating & Schedule Control

1. Practical outcome

By the end of this section, the learner should be able to take an approved schedule and turn it into a trustworthy current control model at each reporting cycle. They should be able to establish a clear data date, collect and validate actual progress, record actual starts and finishes, assess physical accomplishment, estimate realistic remaining durations, deal transparently with out-of-sequence work, recalculate the network, explain movement from both the baseline and the previous forecast, identify changes in the critical and near-critical paths, and convert the updated schedule into actions and management decisions.

The objective is not simply to “update the bars”. It is to create a defensible statement of three things at a defined point in time: what has actually happened, what remains to be done, and what the project now expects to happen if the current plan and assumptions continue.

A good schedule update therefore combines evidence, judgement and calculation. Actual history should be evidence-based; remaining work should be forecast realistically; and the resulting dates should emerge from credible logic rather than being manually moved to match the dates management would prefer to see.

2. Core concepts

Schedule updating is a control process, not an administrative cycle

A schedule update is one part of the wider project-control loop. The project observes actual performance, compares it with the authorised plan and previous forecast, understands why differences have occurred, tests what those differences mean for future outcomes, and decides whether action is required. Entering progress into scheduling software is only the mechanical middle of that process.

·       The update should preserve factual history and create a credible forecast of remaining work.

·       The update should expose change and deterioration rather than hiding them.

·       The update should support decisions: recovery, resequencing, escalation, resource change, risk response or formal change control.

·       A schedule that is technically recalculated but not challenged is not yet a controlled schedule.

The data date creates the boundary between actual history and forecast

The data date, sometimes called the status date, is the point in time at which the schedule is being assessed. Work before the data date is history or current status; work after it is forecast. The precise software treatment varies by product, but the professional principle is universal: the project needs one clearly understood reporting boundary.

For example, if the Reference Project monthly status date is close of business 30 June, an activity reported as actually finishing on 4 July does not belong in the 30 June update. It may be known information, but it is future to that reporting cut-off. Mixing knowledge from different cut-offs creates a schedule that cannot be reconciled with cost, risk and management reporting.

·       Use one agreed cut-off across the principal project-control disciplines wherever practical.

·       Make late information visible rather than silently backdating it.

·       Do not allow “future actuals” merely because the team already knows that work completed after the cut-off.

·       Preserve the prior reporting-cycle schedule so movement from one forecast to the next can be explained.

Actual dates are facts; forecast dates are current expectations

An actual start or finish records an event that has occurred. It should therefore be supported by credible evidence and should not be altered simply because the resulting variance is inconvenient. A forecast date represents the current expectation of when future work will occur. Forecasts can and should change when evidence changes, but the reason for movement should remain understandable.

This distinction is fundamental. If historical actual dates are repeatedly rewritten to make the schedule appear cleaner, the project loses the evidence required for trend analysis, root-cause analysis and later forensic review.

Progress percentage is not enough to update a schedule

M1.4 establishes the physical-accomplishment method and evidence rules. M2.4 applies them to schedule status at the reporting cut-off; it does not redesign the weights or denominator during an update. Actual dates must satisfy each activity’s defined start/finish criterion. Remaining quantities, productivity, resources, access, logic and uncertainty then inform a separate forecast of remaining work.

An activity may be 80% physically complete and still require 40% of its original duration to finish if the final work is more difficult, productivity has fallen or an approval remains outstanding. Conversely, an activity may be only 50% physically complete but be capable of completing rapidly if the remaining work is repetitive and resources have increased. The remaining duration should represent the best current estimate of the time still needed, not a mechanical calculation from percentage complete.

The remaining duration is a forecast judgement

Remaining duration is one of the most important schedule-forecast inputs. It should be informed by the amount and nature of work remaining, actual productivity to date, resource availability, work-front readiness, technical complexity, interfaces, known disruption and credible recovery measures.

·       Do not automatically preserve the original duration after actual performance demonstrates that the assumption was wrong.

·       Do not automatically derive remaining duration as original duration multiplied by the uncompleted percentage.

·       Do not shorten remaining duration merely to preserve a milestone date unless the recovery action that makes the shorter duration credible is also defined.

·       Where uncertainty is material, record the basis of the point forecast and connect it to risk analysis rather than hiding uncertainty inside an unexplained duration.

Three simple status states should remain conceptually clear

At the data date, a discrete activity is normally not started, in progress or complete. Scheduling systems may support additional states and progress methods, but these three concepts help expose inconsistent data.

·       Not started: no valid actual start exists. The activity remains wholly forecast.

·       In progress: a valid actual start exists, but no valid actual finish exists. Remaining duration and remaining logic matter.

·       Complete: both actual start and actual finish are recorded, and no remaining scheduled work exists within that activity.

A 100% physical-progress claim without an actual finish requires investigation against the activity definition. Installation can legitimately finish while separately modelled testing or acceptance remains. Where those requirements are part of the same activity, the activity cannot finish while they remain incomplete. Never mark the whole package complete because one stage has reached 100%.

Out-of-sequence progress requires interpretation

Out-of-sequence progress occurs when work proceeds in a different sequence from the logic represented in the schedule. This may happen for legitimate operational reasons, because the plan changed, because the original logic was weak, or because progress was reported inconsistently. It should never be treated purely as a software nuisance.

Suppose the Reference Project schedule says network configuration can begin only after all cabling installation is complete, but the team begins configuring completed rooms while cabling continues elsewhere. The project has learned something important: either the planned Finish-to-Start relationship was too restrictive, or the delivery strategy has genuinely changed. The remaining logic should be reviewed to represent how the unfinished work will now be delivered.

·       Identify why the out-of-sequence event occurred.

·       Determine whether the existing remaining logic still represents reality.

·       Change forecast logic only where there is an operational basis, and record the reason.

·       Do not rewrite actual history to make the sequence appear as originally planned.

Tool-specific choices such as retained logic, progress override or actual-date calculation settings belong in the Tool Implementation Guides. The Open Standard principle is independent of software: preserve factual history and ensure the remaining network represents the current delivery plan.

Before choosing a calculation setting, identify which unfinished prerequisites still constrain the remaining work. If two rooms can be configured while eight still await cabling, represent the valid hand-off for each part; do not assume the early start removes all cabling dependencies. Compare the resulting forecast with the intended remaining sequence and record the chosen treatment.

Baseline, prior forecast and current forecast answer different questions

The approved baseline tells the project what it committed to deliver. The prior forecast shows what the project expected at the previous reporting cycle. The current forecast shows what it now expects. A useful schedule-control review considers all three.

·       Baseline versus current forecast shows cumulative movement from the authorised plan.

·       Prior forecast versus current forecast shows what changed during the latest reporting period.

·       Actual versus baseline dates show realised performance on completed work.

·       Current forecast movement can reveal emerging deterioration before a contractual or public milestone is actually missed.

A milestone that is still inside its baseline date may nevertheless deserve escalation if it has slipped a few days in every reporting cycle. Trend matters as well as current variance.

Logic changes during an update are not automatically baseline changes

The future plan may need to change as the project learns. Remaining logic, sequencing, calendars, resource assumptions or durations may legitimately be revised to create the best current forecast. Those changes should be visible and explained. They do not automatically mean that the approved baseline should be changed.

The baseline remains the performance reference until an authorised baseline change is approved under M6.2 and M6.3. A forecast can move because performance is poor, assumptions have changed or recovery has been introduced. Rebaselining merely to remove variance destroys the information needed for control.

Schedule control depends on a repeatable reporting cycle

A mature update process defines who provides status, what evidence is required, the cut-off, validation responsibilities, when the schedule is recalculated, when challenge sessions occur, when interfaces are reconciled, and when the current schedule becomes the approved reporting position for that cycle. This reporting calendar should align with cost, risk and management reporting wherever practical.

Consistency does not mean rigidity. A high-risk project may use weekly or even daily short-horizon schedule controls while retaining a formal monthly integrated update. The principle is that the level and frequency of control should match the pace, complexity and consequence of the work.

The updated schedule should support action, not just explanation

The purpose of analysing variance is not to write commentary explaining why a date moved. The practitioner should identify what is controlling the outcome, whether the movement is recoverable, what intervention is possible, by when a decision is needed, and what cost or risk the intervention creates. M2.5 then develops the forecasting and scenario-analysis discipline further.

3. Step-by-step method

The following method is deliberately vendor-neutral. Primavera P6, Microsoft Project, Asta Powerproject, Spider Project and other tools implement status and calculation differently. Tool Implementation Guides can explain software settings; the professional control process should remain recognisable regardless of product.

Step 1 — Confirm the reporting cycle and data date

Establish the exact status cut-off and the timetable for collecting, validating and approving progress. Confirm that schedule, cost, risk and management reporting use compatible cut-offs or that any differences are explicitly understood.

Step 2 — Preserve the previous approved current schedule

Take a controlled snapshot of the schedule used for the previous reporting cycle. This provides the reference needed to explain forecast movement and prevents the project from losing its own recent history.

Step 3 — Issue clear update requirements

Tell workstream owners what information is required: actual starts and finishes, evidence of physical progress, remaining duration, revised expected dates, known interruptions, resource changes, changed interfaces, emerging constraints and explanation of material movement. Avoid update templates that ask only for a percentage complete.

Step 4 — Collect progress from accountable owners and authoritative evidence

Progress should come from the people accountable for the work and be supported by appropriate evidence: approved deliverables, site records, system completion records, inspection/acceptance evidence, procurement records, supplier confirmations or other verifiable sources. The amount of evidence should be proportionate to the importance of the work.

Step 5 — Validate actual starts and finishes

Check that reported actual dates are consistent with the defined start and finish criteria. Challenge future actuals, implausible dates, duplicate dates, dates outside the reporting period without explanation, and changes to previously reported history. Where a prior actual date must genuinely be corrected, preserve the reason and audit trail.

Step 6 — Validate physical progress using the agreed M1.4 rules

Check progress against the pre-defined measurement method and evidence. A schedule update should not invent a separate informal progress basis. Where schedule activity status and measured physical progress conflict, investigate the reason rather than choosing whichever number gives the preferred outcome.

Record the measurement-rule version, evidenced quantity, eligible completion state and actual-date basis with the update. If the source criterion changes, route it through measurement and change governance; do not substitute a software percentage for the approved rule. Validate the remaining schedule independently of the claimed percentage.

Step 7 — Re-estimate remaining duration and expected completion

For every in-progress activity, ask what work remains and how long that work is now expected to take. Use actual productivity, remaining quantities, available resources, access and technical information. For not-started activities, review whether the original duration assumptions remain credible in light of current knowledge.

Step 8 — Capture material interruption, rework and work-front conditions

If work has stopped, restarted, been reworked or materially changed, make sure the remaining schedule represents the real delivery situation. Depending on materiality, it may be better to create explicit remaining activities rather than forcing a single activity duration to represent a complex sequence of disruption and recovery.

Step 9 — Update external and cross-workstream interfaces

Confirm supplier dates, approvals, client inputs, access dates, information releases and handovers between workstreams. The integrated schedule is only as credible as its interfaces. A locally accurate update can still produce a false project forecast if a predecessor workstream has not updated the date it owes to another team.

Step 10 — Review calendars, constraints and resource assumptions

Reflect genuinely changed working calendars, access windows or secured resource arrangements where they affect the forecast. Do not use hard constraints to pin forecast dates to targets. If an important date can no longer be achieved, the schedule should show that result so management can decide what to do.

Step 11 — Review the remaining logic

Ask whether the network from the data date forward still represents how the unfinished work will be performed. Update remaining logic where the actual delivery strategy has legitimately changed, but distinguish forecast replanning from baseline change. Record material logic changes and why they were needed.

Step 12 — Identify and resolve out-of-sequence progress

Locate work that has started or finished contrary to the planned relationships. Determine whether the original logic was wrong, the delivery strategy changed or the status data is inconsistent. Adjust only the remaining network needed to represent reality; do not rewrite the historical event.

Step 13 — Recalculate the schedule

Run the network calculation using the agreed scheduling settings. Treat the calculated dates as the output of the current model, not as automatically correct. The next steps are validation and interpretation.

Step 14 — Perform technical quality checks

Review open ends, constraints, lags, invalid actual/forecast date combinations, activities crossing the data date unexpectedly, negative float, unusually high float, very long remaining durations, calendar changes, disconnected logic and other exceptions. Automated schedule-health checks can locate symptoms; professional judgement determines whether they are genuine problems.

Step 15 — Compare current forecast with baseline and previous forecast

For key activities and milestones, identify cumulative variance from baseline and period movement from the previous forecast. Separate movement caused by actual performance from movement caused by changed assumptions, logic, resource decisions, approved change or risk response where possible.

Step 16 — Reanalyse critical and near-critical paths

Trace the current path or paths controlling the important project outcomes. Confirm that they make operational sense. Examine near-critical paths and changes in float. If the controlling path has changed since the previous update, explain why and what that means for management attention.

Step 17 — Challenge the forecast and identify actions

Discuss significant movement with delivery owners. Test whether recovery proposals are real, resourced and time-bound. Convert analysis into actions, decisions and risk responses. If the opening date is threatened, show the threat clearly rather than suppressing it through logic manipulation or unexplained duration compression.

Step 18 — Approve and preserve the current reporting position

Once validated, designate the updated schedule as the current approved forecast for the reporting cycle, retain a controlled snapshot, and use the same position consistently in schedule reporting, integrated forecasting and management information. Record material assumptions and unresolved exceptions so the next update begins from a known position.

4. Worked Reference Project example

Scenario — Month 15 update of Digital & Technology Systems

The Community & Learning Centre Project has a fixed public opening date. The integrated schedule includes a Digital & Technology Systems workstream feeding integrated testing and operational readiness. At the end of the previous reporting cycle, the technology path had 12 working days of total float to the Operational Readiness milestone.

The current status date is close of business 30 June. The planning team receives the following information:

·       Building Area B was baselined as ready for technology installation on 10 June. It was actually handed over on 17 June.

·       The technology supplier originally planned to deliver Area B equipment on 12 June. Delivery actually occurred on 24 June after a transport problem.

·       Installation started on 25 June. By the 30 June data date, 80 of 240 standard technology points have been installed and inspected.

·       The original installation duration was 12 working days at 20 points per crew-day using one crew.

·       The first four working days achieved 20 points per crew-day in total, which is consistent with the original assumption. However, the remaining rooms include more complex audiovisual equipment and the installation manager now forecasts 10 working days of remaining work, not the eight days that a simple percentage calculation might suggest.

·       Configuration was originally linked Finish-to-Start after all installation. The digital team has already begun configuration in completed rooms on 29 June.

·       Integrated testing cannot start until Area B installation and configuration are complete and a separate fire-system interface is available.

·       The fire-system interface, previously forecast for 18 July, is now forecast for 22 July by the Site & Building team.

First, establish what is factual

At 30 June, the schedule should show the actual Area B handover on 17 June, actual equipment delivery on 24 June and actual installation start on 25 June. The installation is in progress. The configuration start on 29 June is also an actual event if supported by evidence. None of those dates should be moved merely because they create variance from the baseline sequence.

The 80 installed and inspected points provide physical-progress evidence. With 240 points in total, the simple units-complete measure is 33.3%. That is useful evidence of accomplishment, but it does not by itself establish the remaining duration.

Physical progress = 80 / 240 = 33.3%

Second, forecast the remaining work rather than extrapolating blindly

If the learner mechanically used 33.3% progress against a 12-day original duration, they might infer roughly eight days remain. The installation manager has instead forecast ten working days because the remaining rooms contain more complex equipment. That forecast should be challenged for evidence, but if credible it is the better planning input because it represents the work actually remaining.

The planner should ask what drives the ten days: number of specialist devices, expected crew productivity, access restrictions, testing embedded within installation, or a conservative allowance. If the explanation is weak, the planner should not accept the number simply because it came from the workstream manager.

Third, interpret the out-of-sequence configuration start

Configuration starting on 29 June before all installation is complete is out of sequence against the original Finish-to-Start relationship. The learner should not delete the actual configuration start and should not blindly preserve the old relationship if it no longer represents the delivery strategy.

The delivery team explains that configuration can proceed room by room once each room passes installation inspection. The future network should therefore be revised to represent this staged interface, perhaps by splitting Area B into meaningful installation/configuration zones or by using a defensible relationship between remaining installation and configuration work. The exact modelling approach belongs to M2.2 principles and the relevant Tool Implementation Guide; the control requirement is that the remaining network now reflects reality.

Fourth, recalculate and identify the controlling interface

After the update, the technology activities no longer consume all of the available float because overlapping configuration recovers part of the installation delay. However, the fire-system interface has moved four working days later and is now close to controlling the start of integrated testing. The project has therefore learned something more important than “technology is late”: the controlling threat is shifting towards an interface between Site & Building and Operational Readiness.

This is precisely why critical-path analysis must be repeated after every material update. The path that management worried about last month may not be the path controlling the outcome this month.

Fifth, compare three views of performance

·       Against baseline: Area B handover and technology delivery are late, and the installation start is materially later than planned.

·       Against the previous forecast: the technology path deteriorated, but staged configuration recovered part of the forecast impact.

·       Current forecast: the fire-system interface now has reduced float and requires management attention because further movement could control integrated testing.

A useful schedule-control narrative would therefore explain both the realised delay and the new forward-looking driver. It would not simply report the number of late activities.

Sixth, convert the update into management action

The planning team might recommend confirming the fire-system completion plan, protecting access for the remaining technology installation, monitoring actual daily installation productivity, and agreeing a staged configuration/testing sequence. If the fire-system date deteriorates further, a recovery or resequencing decision may be needed. The actions are tied directly to what the updated schedule says is becoming important.

Illustrative management statement

Area B technology installation started 15 calendar days later than the baseline following late area handover and equipment delivery. Room-by-room configuration has partially recovered the effect, and the technology path is not currently forecast to delay Operational Readiness. The fire-system interface has moved four working days since last month and is now near-critical to integrated testing. Confirmed recovery/assurance of that interface is required this period; otherwise the fixed opening-date contingency will reduce further.

This is much more useful than a status statement such as “Technology amber — 33% complete”. It explains what happened, what is now controlling, and what management needs to do.

5. Interpretation and professional judgement

Protect actual history

The most important discipline in schedule updating is to separate what has happened from what people wish had happened. Actual dates should be corrected when genuinely wrong, but never polished simply to improve apparent performance. Historical integrity supports trend analysis, lessons, assurance and forensic analysis later in the project.

Challenge remaining duration more than percentage complete

For forecasting, the remaining duration is often more important than the reported percentage complete. The planner should ask what work remains, what rate is currently being achieved, what resources will perform it, what interfaces must be satisfied, and what evidence supports the forecast completion. A schedule can carry mathematically precise progress percentages while still producing a weak forecast.

Differentiate delay from change

Not every movement is poor performance. A date may move because authorised scope changed, because a risk materialised, because an external assumption changed, or because the delivery strategy was deliberately revised. The schedule-control process should preserve enough information to distinguish these causes. Formal changes to the authorised baseline remain governed through M6.2 and M6.3.

Do not confuse target dates with forecast dates

Management may still require a milestone to occur on a fixed date even after the current forecast shows it will be missed. The correct response is not to force the schedule back to the target. Keep the requirement visible, allow the calculated forecast to show the current outcome, and separately model the recovery actions needed to restore the target if that is feasible.

A small amount of movement can matter more than a large amount

Ten days of delay on an activity with 30 days of genuine float may be less important than two days of deterioration on a near-critical interface feeding the opening date. The practitioner should interpret movement in the context of network position, downstream consequences and trend, not rank issues by days late alone.

Repeated forecast movement is a signal

A milestone that slips by three days each month may remain nominally inside its baseline date for several cycles, but repeated deterioration indicates that assumptions or controls are weak. Comparing the current forecast with the previous forecast reveals this behaviour earlier than a baseline-only report.

Out-of-sequence progress can reveal learning

Out-of-sequence work is sometimes poor discipline; at other times it shows that the team has found a better way to deliver. The practitioner should diagnose it. If the new sequence is valid, the future logic should be improved. If it reflects uncontrolled work starting before prerequisites were genuinely satisfied, the underlying governance or quality risk needs attention.

Schedule health metrics are diagnostic, not verdicts

Metrics such as number of open ends, hard constraints, high float, negative float, long durations, invalid progress or logic changes help direct attention. They should not become a compliance game in which the team edits the schedule merely to improve a health score. The ultimate test is whether the schedule represents the project accurately enough to support decisions.

Questions the practitioner should be able to answer

·       What is the exact data date and what information is valid at that cut-off?

·       Which actual dates were newly recorded this period, and what evidence supports them?

·       Which previously reported actual dates changed, and why?

·       Which in-progress activities have materially changed remaining duration?

·       What actual productivity evidence supports the remaining-work forecast?

·       Where has work occurred out of sequence, and what does that tell us about the remaining logic?

·       Which milestone moved most against baseline, and which moved most since the previous forecast?

·       What is currently controlling the important project outcome?

·       Which near-critical path could become controlling next?

·       What movement is caused by performance, changed assumptions, risk, resource decisions or approved change?

·       Which recovery actions are genuinely funded, resourced and agreed, rather than merely assumed?

·       What decision is required now, by whom, and by when?

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Use the Community & Learning Centre Reference Project and the schedule developed in M2.1–M2.3. Assume the project is now at the end of Month 15. The approved baseline and the previous month’s forecast have been preserved.

Exercise data

·       Reporting data date: close of business 30 June.

·       Area B handover baseline: 10 June; previous forecast: 14 June; actual: 17 June.

·       Technology equipment delivery baseline: 12 June; previous forecast: 18 June; actual: 24 June.

·       Technology installation baseline start: 13 June; actual start: 25 June.

·       Technology installation scope: 240 standard points. At the data date, 80 points have been installed and inspected.

·       Original installation duration: 12 working days. Current workstream forecast: 10 working days remain because the remaining rooms contain more complex audiovisual equipment.

·       Configuration was planned Finish-to-Start after installation. Configuration actually began in completed rooms on 29 June.

·       Fire-system interface previous forecast: 18 July; current forecast from Site & Building: 22 July.

·       Integrated testing requires both technology readiness and the fire-system interface.

·       Operational Readiness had 12 working days of total float at the previous update.

·       The project manager has asked whether the fixed public opening date is still credible and what action is needed this month.

Tasks

1. Identify which data items are actual history and which remain forecast at the 30 June data date.

2. Calculate the physical progress of the installation using units complete and explain why that percentage does not automatically determine remaining duration.

3. List the evidence you would require before accepting the reported actual dates and the 10-day remaining-duration forecast.

4. Explain how you would treat the configuration activity that started before the planned predecessor finished. State what questions you would ask before changing the remaining logic.

5. Describe the schedule recalculation and quality checks you would perform after status has been entered.

6. Compare the key dates against both the baseline and the previous forecast. Identify which movements represent cumulative variance and which reveal new deterioration this period.

7. Determine which interface now deserves the greatest management attention and explain why days-late alone is not sufficient to make that judgement.

8. Draft a concise management statement covering cause, consequence, current forecast and required action.

9. Identify at least three potential recovery or protection actions and state what evidence would be needed before incorporating them into the forecast.

10. Define the information that should be preserved with the approved Month 15 schedule snapshot so that Month 16 movement can be explained.

What good performance looks like

A strong learner will preserve factual actual history, refuse to infer the forecast mechanically from percentage complete, recognise the significance of out-of-sequence configuration, update the remaining plan rather than rewriting the past, compare current dates with both baseline and prior forecast, identify the changing controlling interface, and convert the analysis into a clear management action.

An especially strong learner will also recognise that the project does not yet need a baseline change merely because the forecast moved, that repeated forecast movement is itself a control signal, and that a recovery commitment should not enter the schedule unless the resources, access, decisions and productivity assumptions that make it credible are understood.

8. Bridge to capability

The How-to teaches how to establish a trustworthy current schedule. At APPLIED and above, capability assessment should test whether the practitioner can status realistic records, preserve factual history, forecast remaining work and explain material movement. A controlled update, evidence checks and a baseline-to-current comparison should demonstrate the reasoning. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how evidence becomes a credible current schedule?

Capability question for APPLIED and above: Can you demonstrate a reliable update, defend remaining-work judgements and explain the resulting forecast movement?