Preserve the baseline while updating the construction schedule

The approved baseline provides the agreed comparison point for the scope and assumptions it covers. A current update records actual progress, remaining work and the forecast at a stated data date. A recovery scenario explores proposed actions. A revised baseline, where authorised, establishes a new comparison basis.

Do not use these labels interchangeably. A submitted programme may not yet be approved. A recovery plan may be an internal proposal rather than an accepted contractual commitment. The register should show the status, version, data date, preparation owner and applicable approval evidence.

Oracle P6 documentation describes baselines as project snapshots for comparison with the current schedule. The software's ability to create or update a baseline does not itself authorise a project to replace its approved contractual or management baseline.

For each reporting cycle, retain the schedule file or controlled export, data date, progress basis and update narrative. Record material changes to logic, durations, calendars, constraints and remaining quantities where relevant.

Actual dates should have a defensible source. A reported activity start may mean mobilisation, physical work or completion of a prerequisite, depending on the activity definition. Agree those definitions so progress updates do not become inconsistent interpretations across packages.

Check out-of-sequence progress, open-ended activities and other schedule-quality issues using the project's planning procedure. A forecast movement may arise from a data error as well as from an operating event. Correcting the model should preserve the reason for correction rather than silently rewriting the reporting history.

Consider a synthetic baseline completion date of 30 November. The latest current schedule forecasts 12 December, a twelve-calendar-day movement under this simplified date comparison. The baseline remains 30 November while the project investigates and responds.

The planner should explain which changes drove the movement and which activities currently govern completion. The existence of a twelve-day variance does not establish responsibility, entitlement or an extension of time. Those questions require the relevant contractual and schedule analysis.

If an authorised revised baseline is later adopted, retain the original baseline and the approval record. Reports may need to show performance against both the original and revised bases, depending on the governance requirements. The revision should improve clarity rather than erase the project's history.

A calendar assigned incorrectly may require a correction. A new scope item may require schedule development and a change assessment. A late activity may require a forecast update. These actions can all alter dates, but they have different approval and evidence needs.

Define a change classification before configuring the workflow. Record the reason, affected activities, proposed treatment and reviewer. Material corrections to an approved comparison basis may still need formal review even if they are described as fixing an error.

Avoid a rule that every date movement requires baseline approval. That would make routine forecasting impractical. Equally, avoid allowing any edit labelled “update” to overwrite baseline dates. The controlled object is the approved comparison version, while the current programme must remain responsive to actual conditions.

A recovery scenario may add crews, resequence work, change shifts or alter procurement dates. Record the prerequisites, resource assumptions, cost implications and safety or access constraints. A shorter bar on the programme is not evidence that the proposed acceleration is feasible.

Have the relevant package owners review the plan. Procurement should confirm delivery assumptions; execution should assess work-front and resource constraints; quality and safety owners should review applicable requirements. The planner integrates those decisions into the scenario.

Preserve rejected scenarios and the reasons where they materially explain the selected response. This helps later reviewers understand why an apparently simple option was not available. Keep the approved current forecast distinct from an optimistic scenario still awaiting commitments.

Limit who can create, replace or designate the reporting baseline. Record the approving authority, decision date, scope covered and any reservations. A file named “approved baseline final” is insufficient without the associated decision record.

Where client or engineer approval is required, preserve the formal communication and its conditions. An internal project manager's approval may serve a management purpose without satisfying an external contractual requirement. The schedule register should make that difference visible.

If approval is pending, label the version accordingly and continue reporting against the applicable approved basis. Explain the pending change separately so readers can understand both the established comparison and the proposed future position.

Take a closed reporting period and reproduce its completion forecast and variance. Then load a later update and confirm that the earlier report remains reproducible. Check that a baseline replacement requires the defined authority and records the previous version.

Test a corrected actual date, an added scope activity and an approved rebaseline. Each should produce a different, explainable trail. Also check exported dashboards: a controlled planning file offers little protection if a reporting script automatically uses whichever baseline was modified most recently.

The project needs a current programme it can act on and a comparison basis it can trust. Maintaining both makes recovery discussions more useful and change assessments more defensible.

1. Label baseline, current update, scenario and revised-baseline versions clearly.
2. Preserve each update's data date and material change evidence.
3. Explain forecast variance before considering a baseline revision.
4. Obtain the required authority for any new comparison basis.
5. Test that historical reports can still be reproduced after changes.