Why the first hour is audit, not update
Primavera P6 carries a large number of settings, and the previous user will have made choices on most of them without writing any down. The schedule you have been handed gives the dates it gives because of those settings as well as the logic. Pressing Schedule on an unfamiliar project can move dates, and the new dates then become the reference for your next update.
So export first, audit second and update third. This guide sets out a practical audit for a planner, project manager or controls lead who needs a reliable update or a credible review within days. The menu paths are for P6 Professional, the desktop client. Labels move slightly between releases and the EPPM web client places some of these settings elsewhere, so check each path against the version you are running. For a project of a few thousand activities, allow about two hours. A larger programme takes longer, particularly the calendar and logic checks.
Open the Schedule dialog and read it, then cancel
Press F9 (or Tools > Schedule) to open the Schedule dialog. Nothing recalculates until you press Schedule, so you can read every option and then cancel. Write each one down before changing anything. If you alter an option, activity dates can move on the next calculation, sometimes by a lot.
The options that most often explain dates moving are these. When scheduling progressed activities use: Retained Logic, Progress Override or Actual Dates. Calculate start-to-start lag from: Early Start or Actual Start. Define critical activities as: Total Float less than or equal to a value you set, or Longest Path. Make open-ended activities critical: on or off. Compute Total Float as: Start Float, Finish Float, or the smaller of the two. Calendar for scheduling relationship lag: the predecessor's calendar, the successor's calendar, a 24-hour calendar or the project default calendar. Use Expected Finish dates: on or off. Ignore relationships to and from other projects: on or off. Level resources during scheduling: on or off. Where your release shows Calculate float based on finish date of, record that too.
The contract or the programme specification may state the required settings, and National Highways and NEC4 programme requirements often do. Compare what you find with that document and record any mismatch. Retained logic is the common default for progressed schedules, but the test is whether the setting matches the specification and the previous planner's last update.
A worked example shows why the progress setting matters. Activity A has 5 working days remaining and Activity B, which follows A finish to start, has already started out of sequence with 10 working days remaining. With retained logic, B's remaining work waits until A finishes, so B completes 15 working days after the data date. With progress override, B's remaining work runs from the data date and completes 10 working days after it. The same data gives a 5-day difference on that path.
The critical-activity definition matters as much. Total Float of zero or less and Longest Path can give different critical sets, especially with several calendars, constraints or negative float. Record which one is set before you quote a critical path to anyone. The lag calendar matters because a 5-day lag is 5 working days on whichever calendar is chosen, so a seven-day and a five-day calendar give different dates.
Data date
The data date is the point up to which progress has been recorded. Actual dates and actual durations sit before it, and remaining work is scheduled from it. An activity can be in progress across the data date, so it is not a divider between progressed and future activities.
Check it matches the reporting period. Changing the data date does not apply any actuals. Progress still has to be entered or updated for the period, and until it is, remaining durations and logic are calculated from a date that no longer reflects what has happened on site.
Calendars
Three different things get called the default calendar, and each is set in a different place. The global default calendar is the one used for new projects. The project default calendar is set in Project Details, on the Defaults tab, and is used for new activities in that project. Each activity then carries its own calendar assignment, which is what the scheduling engine uses. Check all three. Exact labels vary by release.
List every calendar in use on the project and count how many activities sit on each. Check the working week, the hours per day, and the holidays. The UK is not one holiday calendar: England and Wales, Scotland and Northern Ireland differ, so confirm the calendar matches the site and the contract. Do not assume a standard working day. A typical starting point is a five-day week, but check it against the contract calendar and any working-hours restrictions.
Check the time-period conversion settings (hours per day, week, month and year) too. A common diagnosis case is a project with five-day, six-day and seven-day calendars where two of them carry different holidays. Activities spanning them show float differences that have nothing to do with the work.
Baselines
Open Project > Maintain Baselines to see what baselines exist, their names and creation dates. Then open Project > Assign Baselines to see which baseline sits in each slot: the Project Baseline and the Primary, Secondary and Tertiary user baselines.
Variance columns and baseline bars read from whichever slot they are set to, and layouts differ by user. The Project Baseline is therefore not automatically the one a given variance column shows. Check which slot each reporting layout's variance columns and bars point to, and record it. Whether earned value calculations use a particular slot depends on the project and release settings, so check that separately if you report earned value from P6.
Do not delete any baseline during the audit. List what exists and ask the project sponsor which is the approved reference. Compare creation dates with the contract's programme acceptance date, not with the award date, because an accepted programme can legitimately post-date award. A baseline that has been refreshed informally and repeatedly has lost its value as a reference, and that is an issue to flag rather than fix in the audit.
Levelling and resources
With levelling on during scheduling, activity dates depend on the resource model as well as the logic. A small logic change can then move several activities as levelling redistributes them. Check whether Level resources during scheduling is ticked in the Schedule dialog, and open the levelling options through Tools > Level Resources. If levelling is on and you do not know why, leave it as found, find out what it is doing, and record it. Scheduling with levelling off when the baseline was produced with it on will move dates.
Cross-project effects come from a specific option: Consider assignments in other projects with priority equal to or higher than a set value. If it is ticked, projects you can open, and their priorities, affect your dates. Check the project priority and which other projects are open. A stand-alone project with no shared resources is not affected.
Then check whether activities are resource-loaded and, if so, whether the resource dictionary is usable: populated rates, realistic availability, and no placeholders such as "TBD".
Logic, constraints and activity types
P6 does not include a DCMA 14 report. DCMA checks are widely used in UK practice, but they are an assessment you build yourself or run with a third-party tool. For the main ones: missing logic (no predecessor or successor) should be 5% or less, leads 0%, lags 5% or less, hard constraints 5% or less, and activities over 44 working days 5% or less. Level-of-effort proportion is not one of the 14 points. Treat it as an additional check.
For dangling activities, use the activity filters, the schedule log after a calculation, or export to a spreadsheet and count. For example, on a project of 2,400 activities, the 5% limit is 120 activities. If 150 have no predecessor or successor, that is 6.25%, which fails. Check whether each is a real omission or an intended start or finish. An activity with no successor does not drive completion, so a real deliverable left open-ended drops out of the critical path. An activity with no predecessor can start as early as the project start.
The P6 constraint names are Start On, Start On or Before, Start On or After, Finish On, Finish On or Before, Finish On or After, As Late As Possible, Mandatory Start and Mandatory Finish. Mandatory Start and Mandatory Finish override logic. Start On and Finish On pin dates. The "or Before" constraints cap late dates and produce negative float when logic pushes past them, and DCMA-style checks count them as hard. Start On or After and Finish On or After are the usual softer options. As Late As Possible consumes float, so record it. Every constraint should have a documented reason, such as a client access date or a regulatory milestone. Without one, it is a candidate for removal.
Check activity type, duration type and percent-complete type on a sample of activities, because they determine how progress and remaining duration are calculated. Task Dependent, Resource Dependent, Level of Effort, Start Milestone, Finish Milestone and WBS Summary behave differently. Level-of-effort activities take their dates from their predecessors and successors. Check that each is genuine ongoing support work and not discrete work coded as level of effort. Record it; do not fix it in the audit. Also check out-of-sequence progress and negative float after a calculation, because both indicate the logic and the status no longer agree.
Mistakes that cost the most time
The first is recalculating before reading the settings. The second is importing a project into another database without checking the globals. Calendars, resources, codes and the EPS structure may not exist or may differ in the target, so the project can behave differently. Import into a test environment and compare.
The third is renumbering Activity IDs. Cost reports, progress claims, risk registers and earned value data all refer to them, so leave them as inherited unless you are rebuilding the reporting around them. The fourth is trusting the view you were given. Layouts carry filters and groupings that can hide completed, out-of-sequence or unassigned activities. Remove filters and groupings while you audit.
The fifth is not exporting first. Before touching anything, export the project as .xer or .xml with a clear filename and date. An export is the fallback you control.
Audit sequence and the audit note
A workable order: export the project and record the opening state, including the data date, warnings and assigned baselines; read the Schedule dialog; review calendars at the three levels; run the logic and constraint checks; review levelling, resources and activity settings; check Activity ID, WBS and codes against the reporting that depends on them; then write the audit note.
The audit note is two pages at most. It states what the schedule is, the settings found and how they compare with the contract's programme requirements, the baselines and their status, the DCMA-style results, the top issues, what to fix before the next update and what to flag to the sponsor. It justifies later changes and protects you if the schedule is challenged.
If the schedule will go into a QSRA, add a readiness check. The model needs complete logic with no open ends, few constraints that stop risk durations moving dates, durations that do not hold hidden contingency, a critical and near-critical path that matches the project narrative, remaining durations that reflect the status, and a schedule that calculates without errors. On a QSRA we run these checks before any risk is added, because a Monte Carlo built on a distorted network gives confident answers to the wrong question.