Why inheriting a programme is different
Being handed a schedule you did not build is one of the most common situations in UK project controls, and one of the least written about. A new planner joining a live programme, a client appointing an independent reviewer halfway through construction, a contract changing hands mid-delivery — in each case the person doing the review has no memory of the decisions that produced the current programme, and a limited window in which to form a credible view. The usual advice — "understand the logic before you comment on the dates" — is correct but useless on its own, because nobody will give you four weeks to read the logic before they want an opinion.
The practical reality is that you have a few days, sometimes less, to form a defensible first read. That first read will shape how the client perceives the contractor, how the contractor perceives you, and what questions get asked in the next progress meeting. Get it wrong in either direction and you either look naive (if you accept a padded programme as credible) or obstructive (if you flag too many issues without being able to justify them). This guide is about how to do the first-read properly, in the time you actually have.
The instinct to treat the handover as a clean slate is a mistake. The programme you have been given is the product of commercial negotiations, technical arguments, and personal relationships you were not part of. The structure of the schedule often tells you more about those conversations than the activity durations do. Reading a contractor's schedule for the first time is partly a technical exercise and partly an archaeological one — you are trying to reconstruct the reasoning that led to the current artefact.
The first-hour checks
Before opening Primavera or Microsoft Project, answer four questions. Which version of the programme is this, and is it the current Accepted Programme or a working revision? What is the data date, and how recent is the last progress update? What is the contractual completion date, and does the programme show planned completion ahead of it, equal to it, or beyond it? What programme revision history exists, and how many times has the schedule been rebaselined since the contract was signed? These four answers tell you more about the state of the project than any DCMA metric will.
Open the file and look at the activity count, the level of detail at critical path activities, and the spread of durations. A programme with 300 activities on an £80m construction job is too light. A programme with 12,000 activities for the same job is too heavy and probably unmanageable. The right level is usually 1,500 to 4,000 activities for a project of that size, depending on sector and contract form. Durations should cluster around a reasonable working range — on most construction projects, 90% of activities should have durations between two days and forty days. A programme where half the activities have durations of one day, or where several key activities run for twelve months with no decomposition, is not yet a planning tool.
Run DCMA 14 — the Defense Contract Management Agency's 14-point schedule assessment, a rapid structural health check originally developed for US defence contractors — as a first automated sweep. The headline metrics are logic (the percentage of activities with both a predecessor and a successor, target above 95%), negative lag (target zero), hard constraints (target below 5%), and high float (target below 5% of activities with float greater than 44 working days). Do not over-interpret DCMA results. They identify structural weakness, not poor content. A programme can pass DCMA 14 comfortably and still be a fundamentally unrealistic plan, and a programme can fail two or three metrics and still be a sensible representation of the work. Use DCMA as a screening tool, not as a verdict.
Check the calendars. Most schedules use several — a standard five-day construction calendar, a six-day intensive calendar for certain packages, a seven-day commissioning calendar, and often a project-level calendar for milestones. Mismatched calendars are one of the most common sources of misleading critical paths. An activity on a six-day calendar tied to a successor on a five-day calendar can appear to consume float that does not exist, or vice versa. Check that the calendars assigned to activities are internally consistent, and that public holidays and planned shutdowns are reflected in the relevant calendars.
Reading logic quality, not just logic count
The DCMA logic metric tells you what percentage of activities have both predecessors and successors. It does not tell you whether those relationships make sense. A schedule can score 99% on the logic metric and still have logic that is structurally wrong — the activities are linked, but the links are soft, fictitious, or reversed. Reading logic quality requires looking at the network, not just the metric.
Start with the critical path. Follow it end to end and ask: does this sequence describe how the work will actually be done? On most real projects, the critical path runs through a recognisable delivery narrative — design, procurement, long-lead item, enabling works, main construction, commissioning, handover. If the critical path jumps between unrelated packages, runs through an administrative milestone that no physical work depends on, or skirts around the obvious risk activities, the logic has been gamed to move the critical path off something the contractor did not want to discuss.
Look for finish-to-start relationships with large lag values. A finish-to-start link with 40 days of lag is almost always either a missing activity (the 40 days of lag represents work that should be explicit on the programme) or a fudge (the lag has been inserted to push a successor out to a preferred date). Lags of more than 10 days deserve a question each. Lead lags — negative lag values — should not appear at all on a well-built schedule and are the first thing DCMA will flag.
Check start-to-start and finish-to-finish relationships for plausibility. Overlapping activities linked start-to-start are fine where two trades genuinely run in parallel. They become problematic when they are used to compress a sequence that should be in finish-to-start — plastering tied start-to-start with painting, for example, with no lag to represent drying time. Finish-to-finish relationships are often misused to force two activities to complete simultaneously when in reality one must precede the other. Both patterns indicate a programme that has been shaped to hit a date rather than to represent the work.
The test that catches most logic problems is the "what happens if" test. Pick an activity mid-sequence and add four weeks to its duration. Does the knock-on effect propagate sensibly through the network, or does it terminate against a hard constraint? If the delay stops at an artificial constraint rather than flowing through to completion, the programme is not responsive to reality and will not support credible impact analysis on compensation events or delay claims.
Honest schedules versus padded ones
There is no single test that distinguishes an honest schedule from a padded one, but there are patterns. A padded schedule typically shows planned completion comfortably ahead of the contractual completion date, with a large block of float at the end of the programme masquerading as contingency. An honest schedule shows planned completion close to the contractual date, with explicit time risk allowances — NEC4's term, now widely used even on JCT and FIDIC jobs — distributed through the programme at points where duration uncertainty is real.
Look at the total float distribution. On a well-structured programme, float is distributed unevenly — some activities have zero float (the critical path), some have moderate float, a minority have large float. A programme where most activities have similar float values has almost certainly been artificially levelled, either by automatic resource levelling or by a planner pushing activities around to achieve a tidy-looking bar chart. Tidy bar charts are a warning sign. Real projects have messy float distributions because real work has messy dependencies.
Check the duration assumptions on the critical activities. A contractor who has told the client the job will take 52 weeks, and has produced a programme showing exactly 52 weeks, has almost always absorbed their entire planning uncertainty into activity durations. This is the most common form of padding because it is invisible — each activity looks individually plausible, but the cumulative effect is that every activity carries a hidden buffer. The diagnostic is to look at the three or four longest activities on the critical path and ask: what is the most optimistic duration for this work, and how does it compare to what the programme shows? A programme where every critical activity is at the pessimistic end of a plausible range is a programme with embedded buffer.
The opposite failure — an overoptimistic schedule — is just as common and easier to spot. The tells are: no allowance for commissioning and snagging at the end; design activities compressed into windows that cannot accommodate client review cycles; procurement durations that assume the supply chain responds in the contractor's preferred timeframe rather than the realistic one; and no weather or access contingency on activities that are genuinely weather-sensitive. A schedule that ignores these realities will not survive its first serious disruption.
The honest version looks different. Planned completion matches the contractual date, with a handful of visible TRAs protecting the completion. Durations on critical activities sit in the middle of a plausible range. Procurement and design activities carry explicit client review durations. Commissioning and handover have a sensible allocation of time — typically 10-15% of the total construction duration on a complex project. There is no single number that confirms this; it is the overall texture of the schedule that tells you whether it was built by someone who expected to deliver it.
Questions to ask the contractor
Before writing a review note, sit down with the contractor's planner. A 30-minute conversation with the person who built the schedule will tell you more than another four hours of analysis. The aim is not to ambush them with gotchas but to understand the reasoning behind the structure — which, on a reasonably competent programme, they should be able to explain comfortably.
Start with the critical path. Ask the planner to walk through it and explain why each transition is necessary. A good planner will describe the delivery logic fluently — "this activity has to finish before that one starts because the scaffold has to come down before the facade can be installed." A weaker planner will explain the critical path as a sequence of predecessors and successors without reference to what physically has to happen. That difference tells you how well-understood the programme is by the team that built it.
Ask about constraints. Every hard constraint on the programme should have a reason — a client-imposed milestone, a physical access date, a regulatory approval that cannot move. If the planner cannot explain why a particular constraint is there, or explains it in terms of what the programme needed to show rather than what the project requires, the constraint is probably artificial and should be challenged. NEC4 programmes in particular should have very few hard constraints, because the NEC model expects the programme to respond to changes rather than hold fixed dates regardless.
Ask about resources. A schedule without resource loading is acceptable on some projects but not on major infrastructure or complex fit-out works. Ask how resource profiles have been built into the plan — have the critical activities been checked against available labour, crane time, or supply chain capacity? A programme that is feasible activity by activity but requires more concurrent concrete pours than the site can support, or peaks concurrent trades beyond what the welfare facilities can accommodate, will not deliver on time regardless of how tidy the logic looks on screen.
Ask about the risk register and time risk allowances. Where are the TRAs, and how were they calibrated? A planner who can point to specific TRAs and explain how they were sized — typically as a percentage uplift on activities with known duration uncertainty — has thought about risk. A planner who cannot find the TRAs on their own programme, or who describes them as "built into the durations," has a problem you will need to surface in the review.
Briefing the client without starting a war
The review output has to be usable. A report that lists 40 DCMA failures without interpretation is worse than no report at all, because it makes the reviewer look pedantic and gives the contractor an easy opening to dismiss the findings as box-ticking. The brief to the client should cover three things: what the schedule tells you about the state of the project, what it does not tell you that you would want to know, and what actions follow from the review.
Lead with the state of the project. "The programme is structurally sound and consistent with the current state of the works; however, planned completion sits only one week ahead of the contractual completion date, and the visible time risk allowance is limited, which suggests limited headroom to absorb further delays." That is a defensible opening statement that gives the client a real picture without accusing the contractor of anything. The client can then ask follow-up questions — what specifically is fragile, what would a delay of X weeks mean, what should we ask the contractor to do — and the conversation proceeds constructively.
Be explicit about what the schedule does not show. If the programme does not cover commissioning in adequate detail, say so. If the risk register is not integrated, say so. If there is no resource loading and the works cannot be verified as feasible without it, say so. These are not criticisms of the contractor; they are observations about the evidence available to the review. The client can then decide whether to request additional information from the contractor or to live with the gap.
Make the recommendations specific and proportionate. Recommending that the contractor "rebuild the programme from scratch" is almost never appropriate unless the programme is fundamentally broken. More commonly, the recommendations are targeted: request clarification on specific constraints, ask for a fragnet showing how commissioning will be delivered, propose that the parties agree on a set of TRAs for the most uncertain activities, ask for resource profiles for the critical trades. Each recommendation should have a named owner and a target date.
Avoid framing the review as an adversarial exercise. Contractors who feel attacked by a review will dig in defensively, and the next conversation will be about point-scoring rather than schedule improvement. The most productive reviews are delivered with genuine respect for the work the contractor has done — the programme may have flaws, but building a construction schedule is hard and the person who built it has engaged with problems you are only now starting to see. Positioning the review as a collaborative effort to strengthen the schedule for the benefit of both parties produces better outcomes than a confrontational one, and a stronger schedule protects the client just as much as it protects the contractor.
What to do on Monday morning
If you have just been handed a programme and need to produce a review by the end of the week, work in this order. Monday: run DCMA 14, check calendars, identify the data date and the last accepted programme. Tuesday: trace the critical path end to end and document any anomalies. Wednesday: sit down with the contractor's planner and ask the questions above. Thursday: analyse float distribution, duration plausibility on critical activities, and the treatment of TRAs. Friday: write the brief, keeping it to two pages plus a technical annex.
Do not try to form a final view before you have spoken to the planner. The programme on screen is one half of the evidence; the reasoning in the planner's head is the other half, and reviews that rely only on the former miss important context. If the planner is unavailable, note this in the brief and flag that the conclusions are provisional pending that conversation.
Do not recommend rebaselining unless the programme is genuinely unusable. Rebaselining is expensive, politically fraught, and often results in a new baseline that is no better than the old one. Most programmes that initially look troubling can be repaired through targeted improvements — tightening logic, removing unjustified constraints, adding explicit TRAs, decomposing overlong activities. Reserve the rebaselining conversation for programmes that have fundamentally lost touch with reality.
Finally, make a habit of documenting your findings as you go, even if the formal review is not due for days. A working note kept during the review — with screenshots, annotations, and questions as they occur — is the best defence against being challenged later on where a particular observation came from. On any project of material value, the review you are writing this week may be read in two years as evidence in a dispute. Write it with that future reader in mind.