When two Primavera P6 schedule files differ, the important question is not simply how many activities changed. Reviewers need to establish which version is the reference, identify material changes, and understand whether each change reflects progress, an approved plan adjustment, a data or configuration difference, or an unexplained edit.
This checklist is for a controlled comparison of two programme versions. It is not a substitute for the project’s schedule procedure, contract requirements, or a full monthly update review. Use those documents to determine which file is authoritative, what status date applies, and which changes require formal approval.
1. Define the comparison before opening the files
Record the identity and purpose of both files before interpreting any differences. A meaningful comparison depends on knowing what each version represents.
- Reference version: identify the accepted baseline, previously reviewed update, or other agreed reference. Do not assume the older file is the correct comparison point.
- New version: record the file name, project or EPS context, export date, and the sender’s stated purpose.
- Status context: note each file’s data date, project dates, and whether it represents a baseline, an update, a recovery proposal, or a revised plan.
- Scope: state whether the comparison covers the whole project, selected WBS branches, a contract package, or a specific set of activities.
- Comparison basis: agree which fields and schedule properties matter for the review. A presentation-only change may be immaterial; a changed relationship or calendar may affect forecast dates.
Keep untouched copies of both source files. If the review requires importing, assigning a baseline, or changing layouts, work in copies and document the actions taken. A comparison report is only useful if another reviewer can tell what was compared and reproduce the result.
2. Confirm the files are comparable
Before assessing changes, check that the two versions represent compatible project data. A missing activity or shifted date can be a real programme change, but it can also result from different scope, different filters, or a mismatched project context.
- Confirm project and WBS identity, activity count, and the intended scope.
- Check whether activities were added, deleted, renamed, or moved between WBS branches.
- Check the data date and the schedule’s status context. Oracle’s P6 guidance describes updating a project as of a new data date, with progress handled through the selected update settings. Therefore, a different data date may be expected between an update and its predecessor; it is not, by itself, proof of an error.
- Check whether both files use the same project calendars, activity codes, user-defined fields, and other relevant configuration.
- Identify whether one file is a native P6 project or a transfer/export. If information may have been omitted or transformed in transfer, verify the affected data in the source project before drawing conclusions.
Where versions are not directly comparable, record the limitation and narrow the conclusion. For example, report that dates differ but the calendar setup could not be verified, rather than attributing the date movement to a logic change.
3. Compare dates and progress fields
Review dates in context rather than treating every movement as a forecast deterioration or improvement. For each significant activity or milestone, compare the relevant dates in both versions and note the direction and apparent driver of change.
- Start and finish: compare planned, actual, and remaining dates where applicable. Separate actual progress from forecast movement.
- Data date: record the date in each file. A change in data date can alter the status context and the interpretation of in-progress work.
- Actual dates and remaining duration: inspect changes to actual start, actual finish, and remaining duration. Oracle’s Update Progress guidance explains that actual dates and remaining durations are applied according to the selected data date and settings. The project’s approved progress rules should govern whether those entries are appropriate.
- Milestones: compare contractual, interface, access, testing, handover, and other project-defined milestones. Confirm that a moved milestone is not simply the result of a changed label or activity identity.
- Constraints: look for added, removed, or changed constraints that may affect dates. Record the specific activity and constraint rather than describing the result only as “dates changed.”
For each material movement, capture the old value, new value, activity ID, and an explanation or open question. If a date moved but its apparent cause is not evident, label the cause as unverified. Do not infer a delay cause from a date difference alone.
4. Compare logic and relationships
Logic changes can alter how work is sequenced and how dates are calculated. Review relationships as data, not merely as a visual impression of bars on a Gantt chart.
- Identify added and removed predecessor or successor relationships.
- Compare relationship type and any lag or lead values where used.
- Check for changes to activity status or scheduling treatment that affect whether an activity drives successors.
- Review open ends, unusual relationship changes, and links that appear to bypass an expected interface or handover. Treat these as review prompts, not automatic proof of defective logic.
- Check whether changed logic corresponds to a documented scope, sequence, access, procurement, or construction-method change.
For a relationship change, report both ends of the link, the relationship type, and any lag difference. Explain the likely schedule effect only when the comparison supports it; otherwise state what needs confirmation. A narrative such as “logic revised” is too vague to help a planner or site team investigate.
5. Compare calendars and working-time assumptions
Calendar differences can influence calculated dates and durations, so verify them before assigning cause to logic or progress. Compare the calendars assigned to changed activities and note changes to the project or resource calendar where relevant.
- Check whether an activity’s assigned calendar changed, including a switch between a project, resource, or activity calendar where the project setup uses those options.
- Compare working days, work periods, and exceptions such as holidays or shutdowns in the affected calendar definitions.
- Check whether calendar changes apply broadly or only to selected activities.
- Review whether a changed calendar is supported by the project’s approved working arrangements or a documented site constraint.
Do not assume that a moved finish is caused by a calendar change just because the calendar differs. Trace the activity’s dates and relationships, and verify the schedule calculation context. If the calendar definition itself is not available in the comparison package, record that evidence gap.
6. Compare activity fields and scope
Activity fields help explain what changed and why. Their significance depends on how the project uses them, so prioritize fields that drive planning, reporting, responsibility, or scope control.
- Identity and description: compare activity IDs and names. A renamed activity may be the same work; a reused ID may not be. Verify identity before treating a deletion and addition as equivalent.
- WBS and codes: check WBS assignment, activity codes, responsible parties, areas, systems, and other classifications used by the project.
- Durations and units: review original, actual, and remaining duration fields that are relevant to the activity’s status and schedule role.
- Resources and roles: note changes where resource assignments or roles are used for planning or reporting. A field change does not, by itself, establish that resources were mobilized or work was performed.
- Progress and notes: compare percent complete, status, and narrative fields used by the project. Check how the selected percent-complete type and update settings relate to the recorded values.
- User-defined fields: include project-specific fields when they carry approval, procurement, interface, or construction information.
For additions and deletions, determine whether the scope has genuinely changed, an activity was split or combined, or identifiers were reorganized. Where the WBS changed, review the mapping between old and new branches; a structural change can make a simple row-by-row comparison misleading.
7. Build a review log that explains the change
A useful comparison log connects the difference to its consequence and its evidence. A recommended format is:
| Item | What to record |
|---|---|
| Reference and new version | File names, version labels, and data dates |
| Changed object | Activity ID/name, milestone, relationship, calendar, or project setting |
| Previous and new values | Exact field values or relationship details |
| Change category | Progress, logic, calendar, scope, coding, constraint, or unexplained |
| Schedule significance | Observed date or logic effect, if established |
| Evidence and action | Supporting record, responsible reviewer, question, or follow-up |
Separate observed facts from interpretation. “Activity A-120 finish moved from 12 May to 19 May” is an observation. “The move is due to late access” is an explanation that needs supporting project evidence. If no evidence was supplied, list the cause as unresolved.
8. Close out the comparison
Before issuing findings, confirm that the review covers the agreed scope and that exceptions are visible. Summarize material changes by category, identify unresolved questions, and state which version is being treated as the reference. Include the comparison date, reviewer, files, and any limitations that affect confidence in the result.
- Can another reviewer identify exactly which two versions were compared?
- Are changes to dates linked to checked progress, logic, calendars, or constraints where evidence allows?
- Are additions, deletions, and WBS reorganizations explained or flagged?
- Are project-specific assumptions and approvals distinguished from general observations?
- Are unresolved differences assigned for confirmation rather than silently accepted?
A controlled comparison does not decide whether a revised plan is contractually acceptable. That decision depends on the applicable contract, project procedure, approval route, and supporting records. The comparison gives the team a traceable basis for asking the right questions.
