A programme update is the project team’s controlled record of what was actually achieved up to a defined data date and what the schedule now forecasts. It is more than changing a few activity percentages. The update should connect site records, schedule status, logic, calculated dates, variance analysis, and the narrative issued with the programme.
This workflow is written for planning engineers and project controls teams using Primavera P6. It does not replace the project’s contract, approved measurement rules, or reporting procedure. Those project-specific requirements govern where they differ.
What a programme update is—and what it is not
An update carries the current status of the approved working programme forward to a new data date. It normally preserves the approved baseline as a reference and records changes to actual dates, progress, remaining work, logic, calendars, constraints, resources, and forecasts. A baseline is the approved reference plan; an update is a time-phased status record; a revised baseline changes the approved reference under the project’s governance; and a recovery or mitigation programme is a response to a forecast or actual problem. They should not be used as interchangeable labels.
1. Fix the reporting period and collect the evidence
Start by recording the previous data date, the new data date, and the reporting cut-off agreed by the project team. Do not enter progress simply because a site report arrived in the inbox. First assemble the source set that supports the status: approved inspection records, delivery records, approved drawings or submittals, quantities, daily reports, test results, labour or equipment records, and the progress measurement sheet.
Make a short status register before opening P6. For each affected activity, record the proposed actual start or finish, the measured progress basis, the remaining duration or quantity, the evidence reference, and the person who verified it. If the evidence is late or contradictory, keep the activity in an exception list rather than silently filling the gap.
2. Validate the update basis before changing activities
Confirm that the working file is the correct project, WBS, calendar set, and approved update copy. Preserve a read-only copy of the prior update and record the file name, data date, version, and export time. Check that the primary baseline is still the baseline the team is required to compare against; attaching a new baseline merely to make a variance look smaller undermines the report.
Review open ends, unexpected constraints, out-of-sequence progress, and changed relationships before interpreting the forecast. A logic edit may be valid, but it must be explainable. A schedule that recalculates cleanly can still be a poor update if its inputs are not supported by project records.
3. Enter actual dates and remaining work deliberately
For completed activities, verify both the actual start and actual finish. For in-progress activities, verify the actual start, the measured progress basis, and the remaining duration or remaining quantity. For not-started activities, do not manufacture an actual date from a planned date. If an activity is progressing out of sequence, record the reason and review the relationship logic instead of hiding the condition with a constraint.
Primavera P6 provides an automatic update route for work that is progressing as planned, and it also supports updating activities and resources individually when the work has deviated from plan. Oracle’s Updating the Schedule guide describes the estimate-progress route, while its separate Update Progress documentation describes applying actual dates and updating actual and remaining durations according to the selected data date and settings. Use that convenience only for activities whose records support the assumption; status that is not on plan needs an explicit review.
Keep the progress type, activity calendar, units, and cost assumptions visible during the review. A duration-based percentage can be misleading for a physically measured installation, while a physical percentage without the supporting quantity record is equally weak. The schedule should show the approved measurement basis, not just a number that produces a convenient forecast.
4. Move the data date, reschedule, and inspect the network
After the verified status is entered, advance the data date to the agreed cut-off and reschedule the project using the approved scheduling options. Record the scheduling log or export used for the report. The purpose of rescheduling is to let the network calculate the effect of the actuals, remaining work, relationships, calendars, and constraints; it is not a substitute for reviewing whether those inputs are correct.
Review the resulting critical and near-critical paths, total float, free float, remaining early dates, forecast completion, and any newly negative float. Compare the result with the prior update. When the completion date moves, identify which status, logic, constraint, calendar, or remaining-duration change caused the movement. A narrative that only says “the forecast moved” is not enough for a reviewer to reproduce the conclusion.
5. Reconcile the update against the baseline and prior update
Prepare a compact variance table. At minimum, consider:
| Review item | Question to answer | Evidence to retain |
|---|---|---|
| Data date | Does the update cut-off match the reporting period? | Update register and schedule header |
| Actual status | Can the actual start, finish, or progress be traced to a record? | Inspection, quantity, delivery, or daily record |
| Remaining work | Is the remaining duration or quantity realistic for the current conditions? | Planner/site verification and calculation |
| Logic and constraints | Were relationships, lags, calendars, or constraints changed and explained? | Change log and schedule comparison |
| Forecast | What moved the completion date or float, and is the cause visible? | Before/after dates and driving-path review |
| Baseline variance | Is the comparison made against the approved baseline and prior update? | Baseline identifier and variance export |
6. Use a calculation check without confusing it with the measurement rule
For a simple illustrative check, suppose an activity has 12 planned workdays, 7 verified actual workdays, and 5 workdays remaining. The arithmetic check is:
Illustrative duration progress = 7 ÷ (7 + 5) × 100 = 58.3%
This is not a universal rule for physical progress, earned value, or contractual entitlement. A project may require installed quantities, weighted milestones, resource units, or another approved basis. The check is useful because it exposes an inconsistent pair of actual and remaining durations; it is not permission to replace the project’s approved progress method.
7. Write the programme narrative from the schedule evidence
The narrative should explain the reporting period, work completed, work planned next, key variances, critical or driving path changes, major constraints, and the actions being taken. Each important statement should point to a schedule field, a project record, or a clearly identified assumption. Separate observed facts from forecast judgments.
When a delay or change is mentioned, describe the event and schedule effect without automatically declaring contractual entitlement. Notice requirements, causation, criticality, concurrency, mitigation, and entitlement depend on the governing contract and project records. A programme update can provide useful evidence, but it is not by itself a complete extension-of-time analysis.
Pre-submission review checklist
- The project, WBS, calendar, update file, and reporting period are identified.
- The new data date is agreed and is later than the previous update date unless an approved correction explains otherwise.
- Actual dates and progress are supported by contemporaneous records.
- Completed activities have zero remaining work; in-progress activities have a reasoned remaining duration or quantity.
- Out-of-sequence progress, open ends, constraints, lags, and relationship changes are reviewed and explained.
- Critical path, near-critical path, float, forecast completion, and baseline variances are compared with the prior update.
- The narrative describes the same status and causes visible in the schedule.
- The native file, PDF or XER export, layouts, logs, evidence register, and approval trail are stored under document control.
Common mistakes that weaken a programme update
- Advancing the data date without entering or checking actual status.
- Using planned dates as actual dates when work records are unavailable.
- Changing logic or constraints to recover a date without recording the reason.
- Using a duration percentage for work that is governed by measured quantities.
- Comparing against an unapproved or newly created baseline.
- Reporting a new forecast without tracing the driving change.
- Calling an update a recovery programme or revised baseline without the separate approval and purpose those instruments require.
Related EngineersBlog reading
- Method statement for what does it mean by data date in
- Method statement for retained logic in primavera p6
- Method statement for progress override in primavera p6
- Method statement for how calculate duration in primavera p6.
References
Conclusion
A reliable P6 programme update is a controlled chain: agree the data date, verify the records, enter status deliberately, reschedule, investigate the network movement, reconcile against the baseline and prior update, and write a narrative that a reviewer can reproduce. The value is not the percentage of activities updated; it is the traceability between what happened on the project and what the schedule now forecasts.
