Who this is for, and why inheriting is different
This guide assumes you are the client-side planner or independent reviewer who has been handed a contractor's programme mid-project. If you are a contractor's planner inheriting your own side's file, most of the checks still apply but the briefing section does not. The companion guide, challenging a contractor's schedule, covers the ten questions to put to a contractor once you have a view. This one covers the week-one read that gets you to that view.
You have no memory of the decisions behind the current programme and a few days, sometimes less, to form a defensible first read. Treat the file as the product of commercial negotiation and technical argument you did not witness. Its structure often records those conversations more clearly than its durations do. Reconstruct the reasoning before you judge the result, and ask why before you assume intent.
The first-hour checks
Before opening Primavera P6, Microsoft Project or Asta Powerproject, answer five questions. Which version is this, and is it the Accepted Programme or a working revision? What is the data date, and how old is the last progress update? What is the contractual Completion Date, and does planned Completion sit before it, on it or after it? How many revised programmes have been submitted since the contract was signed? Do you hold the native file, and not only a PDF? Those answers frame everything that follows. A PDF cannot be tested.
Then open the file and look at size and shape. SOMA rule of thumb, not a standard: if critical-path activities regularly run past 20 working days, or half the activities are one day long, the programme is either too coarse or too fine to be a control tool. There is no correct activity count; it depends on sector, contract form and how the work is packaged. DCMA test 8 flags durations over 44 working days, so a key activity running for twelve months with no breakdown will fail it and deserves a question regardless.
Check the calendars. Programmes often carry a five-day construction calendar, a six-day calendar for certain packages, a seven-day commissioning calendar and a milestone calendar. An activity on a six-day calendar linked to a successor on a five-day calendar can show float that does not exist, or hide float that does. Confirm that public holidays and planned shutdowns appear in the right calendars, and that the scheduler's setting for which calendar drives lag and float calculation is the one the planner intended. In P6 that is the relationship lag calendar option in the schedule settings.
Run DCMA 14 as a screen
DCMA 14 is the Defense Contract Management Agency's 14-point schedule assessment. Run it once, early, as an automated sweep. The table above sets out the tests and what each cannot show. Use it as a screen and not as a verdict. A programme can pass all 14 and still be an unrealistic plan, and one that fails two or three can be a sensible representation of the work.
Two cautions. First, most of the thresholds apply to incomplete activities, so a programme that is 70% complete is being tested mainly on the remaining 30%; missed tasks and BEI (tests 11 and 14) look at what should already have finished. Second, a hard constraint counts against test 5 even when it is legitimate. Key Dates, the Completion Date and fixed access dates are genuine constraints. Tie each hard constraint to a source in the contract, and ask about the rest.
Reading logic quality, not just logic count
A programme can score 99% on test 1 and still have links that are weak, fictitious or reversed. Read the network and not only the metric.
Follow the longest path end to end and ask whether it describes how the work will actually be done. On most projects it runs through a recognisable delivery narrative: design, procurement, long-lead items, enabling works, main construction, commissioning, handover. If it jumps between unrelated packages, runs through an administrative milestone that no physical work depends on, or passes round the obvious risk activities, ask why. The cause may be a drafting shortcut, a legacy link or a deliberate choice, and you cannot tell which from the file alone.
Look at finish-to-start links with large lags. A 40 working day lag is usually either missing work that should be explicit, or a device to push a successor to a preferred date. DCMA tests the proportion of relationships carrying lags (test 3, 5% or less). It does not set a size limit per lag. SOMA's own rule is to ask about every lag over 10 working days. Leads (negative lags) should be absent, and are the first thing test 2 flags.
Check start-to-start and finish-to-finish links for plausibility. Start-to-start is fine where two trades genuinely run in parallel. It is a concern where it compresses a sequence that should be finish-to-start, such as plastering and painting with no lag for drying. Finish-to-finish can force two activities to complete together when one must precede the other. Either pattern may indicate a programme shaped to a date. Ask the planner what physically governs the link.
Then run the what-if test, on a copy of the native file and never on the submitted one. Pick a mid-sequence activity and add four weeks to its duration. The delay should flow to completion. If it stops, look for what stopped it. Mandatory constraints (Must Start On, Must Finish On) stop the delay propagating. Finish No Later Than and similar late constraints behave differently by tool: Primavera P6 lets the early dates move and shows negative float, while Microsoft Project by default holds the constrained date. Check both the finish date and the float. A programme that absorbs a four-week delay without moving completion will not support credible compensation event assessment or delay analysis.
Mid-project traps
A new programme is easy to read. A live one carries history, and most of the traps sit in the history.
Compare against the baseline or the previous Accepted Programme. List every activity whose logic, duration, calendar or constraint changed, and every activity that moved more than a few weeks without a stated reason. Rebaselining count matters less than what changed in each revision. Under NEC4 the Contractor submits a revised programme, so use that term in your note.
Check the progress method. Retained logic keeps the original links when work starts out of sequence, so an out-of-sequence start can leave a successor waiting on an unfinished predecessor. Progress override ignores that link and lets the successor run. Neither is wrong, but the two produce different critical paths and different forecast dates. Confirm which the scheduler is set to and list the out-of-sequence activities.
Search for actual dates after the data date and forecast dates before it (test 9). Check that completed activities carry actual start and finish dates and that percent complete is consistent with remaining duration. Confirm the critical-path setting in the scheduler: longest path and lowest total float give the same answer only when no finish constraint is applied.
Write down which delay analysis method the programme would support. The AACE International Forensic Schedule Analysis recommended practice (29R-03) and the Society of Construction Law Delay and Disruption Protocol (2nd edition, 2017) both assume a reliable updated programme with sound logic. A file that fails the what-if test will not support either.
Float, the critical path and honest versus padded schedules
The critical path is the longest path to completion. It is not automatically the zero-float path. If planned Completion is earlier than a finish constraint or the Completion Date, the longest path carries positive float equal to the gap, and a project finish constraint changes float on every path. State in your note which setting the scheduler uses and how float is calculated, or your numbers will not reconcile with the contractor's.
Uniform float across many activities has several causes, and automatic resource levelling is a poor suspect because levelling moves dates and does not equalise float. More likely candidates: a late-finish constraint on a terminal milestone, hammock or summary logic tying many activities to one date, a single calendar applied everywhere, or open-ended activities all linked to completion. Check for these before you suspect anything else. Real programmes show a spread of float values because real work has uneven dependencies, so a very even distribution is a prompt to look, not proof of a problem.
For the honesty test, use one method. First compare planned Completion with the contractual Completion Date: earlier, equal or later. Then ask where schedule uncertainty is held: in visible time risk allowances, or buried in activity durations. The four sensible combinations read as follows.
Earlier than the Completion Date with visible time risk allowances: a normal and healthy position. Under NEC4, planned Completion ahead of the Completion Date is allowed and is not evidence of padding. Ask what the gap is for and who has agreed it. Earlier with no visible allowances: the gap may be doing the allowances' job, or the durations may be padded. Test the longest activities against the planner's own most likely and worst plausible durations.
Equal to the Completion Date with visible allowances: acceptable, with thin headroom beyond the allowances. Equal with no visible allowances: this is the case that needs a question, because every activity may be carrying a hidden buffer. Planned Completion later than the Completion Date: the programme already shows culpable or non-culpable delay, so ask which, and whether a compensation event notification or a revised Completion Date supports it.
Overoptimism is the opposite failure and is easy to spot. Look for no allowance for commissioning and snagging, design activities too short for client review cycles, procurement durations that assume the supply chain responds on the contractor's timescale, and no weather or access allowance on weather-sensitive work. SOMA rule of thumb: on a complex project, commissioning and handover rarely take less than a tenth of the construction duration. Treat that as a prompt to ask, not as a benchmark.
Float and time risk allowances under NEC4
Clause 31.2 of the NEC4 Engineering and Construction Contract (2017, amended January 2019 and October 2020) lists what each programme must show, including float and time risk allowances. The contract does not say who owns float. Our reading, which the contract wording and your Contract Data override, is this: time risk allowances are the Contractor's allowances for its own time risks, shown so that everyone can see them; float is a visible product of the programme logic and dates, and neither party is entitled to consume it by default.
This has practical consequences for a client-side reviewer. Under cl.31.3 the Project Manager replies within two weeks, and the grounds for not accepting a programme are limited. As we read them, they are that the Contractor's plans are not practicable, do not show the information the contract requires, do not represent the Contractor's plans realistically, or do not comply with the Scope. A TRA that looks generous is not itself a ground. A programme that omits the allowances cl.31.2 calls for may be. If the Project Manager neither accepts nor replies and the Contractor notifies, one further week runs before the programme is treated as accepted, so a review that is not finished in time can lose the point. A late reply is also a compensation event under cl.60.1(6).
Compensation events are assessed against the Accepted Programme (cl.62 and 63). The delay to the Completion Date is measured by how far a compensation event pushes planned Completion beyond planned Completion on the Accepted Programme. The allowances and float inside the Accepted Programme therefore matter commercially. A programme without visible allowances makes a later fight over what a delay consumed hard to resolve, so ask for them to be shown. Revised programmes follow cl.32: at the intervals in the Contract Data, when instructed, and when the Contractor chooses.
Early warning (cl.15) and the Early Warning Register are the contractual place where risks that justify an allowance should surface. If a TRA protects a risk that has never appeared on the register, ask why. NEC4 does not require schedule risk analysis or earned value management, so do not present either as a contractual obligation.
A flagged lag taken through to a recommendation
Illustrative example. The programme has a finish-to-start link with a 30 working day lag between completion of the roof deck and the start of internal fit-out, on a five-day calendar. That is six weeks with no work shown.
The planner explains it covers sealing the envelope, first-fix services and an inspection hold. That is a reasonable answer, and the lag is a missing fragnet and not a fudge. The three activities are 10, 15 and 5 working days, which total 30. Recommendation line: Contractor to replace the lag with the three explicit activities, logic-linked and resourced, in the next revised programme. Owner: Contractor's planner. Date: within two weeks of the review meeting. The review note then records that the lag was queried, explained and closed, which is exactly the trail a later dispute reader looks for.
Sizing a time risk allowance follows the same discipline. For each longest-path activity with real uncertainty, record the planner's most likely duration and a plausible worst case, and take the difference. Illustrative figures: three allowances of 4, 2 and 2 weeks sit inside planned Completion at week 100. The durations without allowances total 92 weeks, so the allowances add 8 weeks, about 9% of 92. The Completion Date is week 104, leaving 4 weeks of float. Total headroom over the most likely finish is 12 weeks. That is a visible, explainable position.
Talking to the planner
Spend 30 minutes with the person who built the schedule before you write anything. The aim is to understand the reasoning, and a competent programme should be explainable. Ask the planner to walk the longest path and say what physically has to happen at each step. Ask for the reason behind each hard constraint and its source in the contract. Ask how resource profiles were checked against labour, crane time or supply chain capacity. Ask where the time risk allowances are and how they were sized. Do not form a final view before this conversation. If the planner is unavailable, say so in the brief and mark the conclusions as provisional. The companion guide, challenging a contractor's schedule, gives the ten questions in full.
Briefing the client without starting a war
A report listing 40 DCMA failures without interpretation helps nobody. It makes the reviewer look pedantic and gives the contractor an easy reason to dismiss the findings. Cover three things: what the schedule tells you, what it does not tell you, and what should happen next.
Lead with the state of the project. For example: the programme is structurally sound and consistent with the works to date; planned Completion sits one week ahead of the Completion Date and the visible time risk allowance is small, so there is limited headroom for further delay. That gives the client a real picture and accuses nobody.
Be explicit about what the schedule does not show. If commissioning is not covered in adequate detail, if the risk register is not linked to the programme, or if there is no resource loading, say so. These are observations about the evidence available, not criticisms of the contractor.
Make recommendations specific and proportionate, each with an owner and a date. Asking for a complete rebuild is rarely right. Targeted requests work better: explain specific constraints, show how commissioning will be delivered, agree allowances for the most uncertain activities, provide resource profiles for critical trades. A revised programme under cl.32 is the contractual route. Present the review as an effort to strengthen the schedule for both parties. Contractors who feel attacked dig in, and the next meeting becomes about point-scoring.
The week, and the reader in two years
Monday: establish the version, data date and last accepted programme; run DCMA 14; check calendars. Tuesday: trace the longest path and the baseline comparison, and note anomalies. Wednesday: meet the planner. Thursday: examine float, critical-activity durations and the treatment of time risk allowances. Friday: write the brief, two pages plus a technical annex.
Keep a working note as you go, with screenshots, settings and questions. On a project of material value your review may be read in two years as evidence. Write for that reader.
Before a quantitative schedule risk analysis, SOMA's practice is to screen the native file and data date for logic health first. Risk results sit on top of the network, so weak links and unexplained constraints produce unreliable P-values however well the risk register is built.