Why inheriting P6 is different from inheriting any other tool
Primavera P6 is the dominant scheduling tool on UK infrastructure and major construction programmes for a reason — it handles multi-project logic, large activity counts, and complex resource loading better than anything else in the market. It is also substantially more configurable than it needs to be for any one project, which means that the P6 database you have inherited carries with it dozens of settings choices made by the previous user, many of which affect how the schedule behaves and most of which will not be documented.
The instinct to open P6 and start updating progress is understandable and almost always a mistake. Until you have audited the configuration, you do not know what the scheduling engine will do when you recalculate the schedule. A setting that treats activities as retained logic versus progress override will produce different answers on the same data. A default calendar that is wrong will silently misallocate working days. A leveling configuration that was left on from the previous planner will shift activities based on resource constraints that may no longer apply. None of this is obvious from looking at the activity view.
This guide is about the practical audit of an inherited P6 database. It is aimed at the planner, project manager, or controls lead who has been given access to a P6 file and needs to produce a reliable update or a credible review within days rather than weeks. The audit can be done in about two hours if you know what to look for, which is what the rest of this guide covers.
The default calendar and the scheduling options
Open the global calendars view and check the default project calendar. On a UK construction project this is usually a five-day working calendar with UK public holidays and a defined working day of 8 to 10 hours. Verify that the public holidays are actually in the calendar — P6 does not populate them automatically, and a UK calendar that shows Christmas Day as a working day is one of the most common errors on inherited databases. Check that the calendar used as the default is the one you want; P6 allows multiple calendars, and the "default" is whichever one has been marked default in the Enterprise > Calendars view, not necessarily the one most activities are assigned to.
Check the project-level calendars. Projects can have their own calendars that inherit from or override the global calendars. Run a report listing every calendar in use on the active project and check that each is defined correctly. Mismatched calendars between activities are one of the hardest-to-diagnose causes of unexpected float behaviour. A common finding is that the project has three calendars — a five-day construction calendar, a six-day intensive calendar, and a seven-day commissioning calendar — and two of the three have different public holidays from each other, producing apparent float inconsistencies when activities span them.
Now open the scheduling options (F9, then Options, or via Tools > Schedule > Options). The critical settings are: "When scheduling progressed activities use" — this should almost always be "Retained Logic" for most UK construction work (progress override is appropriate in specific circumstances but produces unexpected results on general scheduling); "Calculate start-to-start lag from" — this is usually "Early Start" and should match the previous planner's approach to avoid shifting activity dates on recalculation; "Calculate float based on finish date of" — usually "Each project"; and the level of effort and milestone settings, which affect how these activity types are treated during scheduling. If you change any scheduling option from the setting used by the previous planner, you will see activity dates move on recalculation, sometimes significantly, and the team may lose trust in the schedule. Note the inherited settings before changing anything.
The "Data Date" is the other setting that matters. The data date is the cutoff point between past and future — activities before the data date are considered progressed, activities after are considered future work. An incorrect data date produces nonsense schedule calculations. Check that the data date on the open project matches the reporting period you intend to update against. If the previous planner left the data date at an old value, all your updates will be applied relative to that old date, producing wrong results.
The baseline situation
Baselines in P6 are a frequent source of confusion because P6 allows multiple baselines per project and uses them for different purposes. There is the "Project Baseline" (the approved baseline used for variance reporting), the "Primary User Baseline" (the user's personal reference), and optional "Secondary" and "Tertiary" user baselines. Views that show baseline bars can be configured to show any of these, and the current user's configuration may be showing a different baseline from what the project is supposed to be reporting against.
Open Project > Maintain Baselines and check what baselines exist on the project. Note the dates they were created and the names. Ideally there is a single clearly named baseline — "Contract Baseline", or "Approved Baseline 2024-10-15" — which is the authoritative reference. Commonly there are several: "Contract Baseline", "Client Submission", "Internal Target", "Monthly Update Baseline 2024-11", and it is unclear which is the authoritative one. Do not delete any baselines during audit; document what exists and flag to the project sponsor which one is the approved reference.
Check which baseline is assigned as the Project Baseline (used for variance reports) and which as the Primary User Baseline (used for your own bar display). If they differ, the variance reports and your visual comparison will show different things, which is a common source of misunderstanding in review meetings. Align them unless there is a specific reason to keep them different, and document the decision.
The other baseline question is whether the baseline programme has been updated over time. A baseline that has been "refreshed" every few months — essentially rebaselined quietly — loses its value as a variance reference. Check the baseline creation date and compare it to the contract award date. If the baseline is six months younger than the contract, either there was a legitimate rebaselining event (find the documentation) or the baseline has been overwritten informally (which is a bigger problem than you are likely to fix in the audit).
Leveling, resource loading, and what they might be doing to your schedule
Resource leveling in P6 is the process of rescheduling activities based on resource availability, moving activities where resource demand exceeds resource capacity. If leveling is enabled and is being applied automatically on schedule recalculation, your activity dates are a function of the resource model, not just the logic. This produces non-obvious behaviour — a small logic change can produce a large schedule change because leveling has redistributed resource-constrained activities across the newly available windows.
Check whether leveling is enabled on the project. Tools > Level Resources, or check the scheduling options. On most UK construction schedules, leveling is not enabled — the schedule is run on logic alone, and resource constraints are managed separately. If the inherited project has leveling enabled and you do not know why, leave it enabled for the moment but make sure you understand what it is doing before you recalculate. Running the schedule without leveling when the baseline was produced with leveling will shift dates.
Check the resource assignments. Are activities resource-loaded? Some UK schedules are heavily resource-loaded (common on major infrastructure where the client requires it); many are not (common on smaller construction where the schedule is essentially a logic model). If resources are loaded, check that the resource dictionary is sensible — unit costs are populated, availability curves are realistic, and the resource types correspond to real categories of labour and plant. Resource dictionaries that have accumulated cruft from previous projects — resources called "TBD" or "Labour_Temp" — suggest the resource loading has not been maintained and may be noise rather than useful data.
On multi-project databases (common in P6), check whether the project you have inherited shares resources with other projects in the database. If it does, resource-leveled calculations pull from the combined resource pool, which can produce unexpected behaviour if the other projects have changed since the baseline was set. On single-project EPS, this is not an issue, but on enterprise deployments it is worth checking explicitly.
Dangling activities, hard constraints, and level-of-effort abuse
Run a DCMA 14 check or equivalent on the inherited project. The metrics that matter most on a P6 audit are: the percentage of activities with missing predecessors or successors (target above 95% with both), the number of hard constraints (target below 5% of activities), the use of negative lag (target zero), and the proportion of level-of-effort activities (if excessive, a sign of abuse).
Dangling activities — those without a predecessor or without a successor — are one of the two most common structural problems in inherited P6 schedules. Activities with no successor do not drive the completion date, which may or may not be intentional; if the dangling activity is a real deliverable that is needed for project completion, its finish is not being represented in the critical path. Activities with no predecessor can start at any time within the project window, which typically means they start at the project start date (if early start is being calculated from there) and appear to happen immediately. Use the DCMA report to identify dangling activities and assess which are genuine omissions versus intentional structural choices.
Hard constraints — "Start On", "Finish On", "Must Finish By", and the "Mandatory Start" and "Mandatory Finish" variants — force activities to specific dates regardless of their logic. A few hard constraints on externally imposed dates (client access dates, regulatory milestones) are legitimate. A programme with dozens of hard constraints has been shaped to produce specific dates and will not respond realistically to changes. Identify every hard constraint and check that each has a documented external reason. Constraints without documentation are candidates for removal or conversion to soft constraints (start no earlier than, finish no later than, which still influence dates but do not override the logic).
Level-of-effort activities — P6's mechanism for representing ongoing work such as management, supervision, or monitoring — have specific scheduling behaviour. They are bounded by their predecessor start and successor finish, and their duration adjusts automatically. Overuse of level-of-effort activities is a common abuse: real discrete work is coded as level-of-effort to avoid committing to specific durations. Identify all level-of-effort activities and check that each represents genuine ongoing work rather than hidden task activities. Converting level-of-effort to task activities usually requires breaking the activity into components and re-linking, which is a significant change — flag it in the audit rather than fix it in the same session.
Long-duration activities — those over 44 working days — are another DCMA flag. The concern is that long activities mask sub-activities that should be explicit. A 200-day "foundation works" activity hides the sequence of piling, excavation, blinding, reinforcement, and concrete pours that make it up, and delay impact analysis cannot propagate through an opaque block of time. Identify long activities and assess whether decomposition would add value. Decomposition is not a two-hour audit task; it may need to be added to the improvement backlog.
Common mistakes on inherited P6 databases
The most common mistake is recalculating the schedule before understanding the configuration. Pressing F9 on an inherited project commits you to the settings the previous planner left in place, and the new dates become the reference for the next update. If those dates are wrong because the scheduling options were non-standard, you will be chasing variances that are artefacts of your own recalculation rather than real events.
The second common mistake is importing the project into a new P6 database without checking the global settings. P6 projects can have project-specific calendars, resources, codes, and custom fields, but they also inherit from the global database. A project imported from one database into another may behave differently because the globals differ — global calendars may not exist in the new database, resource dictionaries may not match, EPS structures may be different. Always import into a controlled environment and verify the project behaves identically to the source before relying on it.
The third common mistake is treating the Activity ID and WBS structure as disposable. The Activity IDs in an inherited project are the reference that every external system — cost reports, progress claims, risk registers, earned value data — uses to tie back to the schedule. Renumbering activities to match your preferred convention breaks every external reference. Leave the Activity IDs as inherited unless you are rebuilding the entire reporting ecosystem around them.
The fourth common mistake is assuming the summary view (or the bar chart) is giving you the whole picture. P6 defaults to showing a filtered view of activities, and the filter may be excluding activities the previous planner did not want visible — out-of-sequence progress, completed activities, or activities assigned to resources not currently displayed. Remove filters temporarily during audit to see the full activity set. Remove groupings that might hide activity count issues. The view presented to you at file opening is not necessarily a complete view.
The fifth common mistake is not exporting the current state before making any change. Before you do anything to an inherited schedule, export the project as a .xer or a .xml file and save it with a clear filename and date. If anything goes wrong during your audit or subsequent work, the exported file is your fallback. P6 has limited undo capabilities and no version control, and an unrecoverable configuration change can lose hours of inherited work.
A two-hour audit checklist
The practical audit, in order. Fifteen minutes: export the project to .xer as a backup. Note the project open settings (project ID, data date, any warnings on opening). Check the active baselines (Project Baseline and Primary User Baseline) and document what they are.
Thirty minutes: review the global and project calendars. Verify the default calendar is correct, UK public holidays are populated, and the calendars assigned to activities are consistent. Open the scheduling options (F9 > Options) and document every non-default setting. Note the retained logic vs progress override setting in particular.
Thirty minutes: run a DCMA 14 or equivalent check. Review the results for logic density, hard constraints, negative lag, long durations, and dangling activities. Identify the top five structural issues to investigate further. Check the critical path — does it make sense against the project narrative?
Fifteen minutes: review resource and leveling configuration. Is leveling enabled? Is the project resource-loaded? Is the resource dictionary clean? Are there multi-project resource dependencies?
Fifteen minutes: review Activity ID structure, WBS, and activity codes. Confirm the structure matches the reporting ecosystem (cost reports, progress claims). Check for orphan activities that are not in the main WBS structure.
Fifteen minutes: write the audit note. Two pages maximum: what the schedule is, what state it is in, what the priority issues are, what should be fixed before the next update, and what should be flagged to the project sponsor. This note is the handover artefact that justifies any changes you make to the schedule in the subsequent updates, and it is also the reference that protects you if the schedule is later challenged.
On Monday morning: do not update the schedule before completing this audit. The time investment of two hours up front prevents the larger investment of unpicking confused update data later. Planners who skip the audit step and go straight to updating inherited schedules tend to produce inherited problems compounded by their own new ones; planners who invest in the audit produce schedules that other people trust.