5 signs your project programme has lost integrity

By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control

Founder, NEC Planning Solutions Ltd

A programme that has lost integrity does not announce itself. It does not crash. It does not produce error messages. It does not refuse to open. It looks exactly like a programme that works. It has activities, logic links, a critical path, a data date, and a completion milestone. It opens in Primavera P6 or Asta Powerproject or MS Project and produces a Gantt chart that fills a screen and appears to show a credible plan for delivering the remaining works.

The problems only surface when the programme is tested. A compensation event arises and the programme cannot demonstrate the time impact. The project manager asks why an activity is on the critical path and nobody can explain the logic chain. A delay appears in the progress but planned completion has not moved. The programme was accepted months ago and nothing about it has changed, even though the project has changed significantly. A quotation is produced for a compensation event and the project manager rejects it because the programme it relies on does not represent reality.

These are the moments when programme integrity matters, and they are the moments when most contractors discover they do not have it.

Project programme integrity is not a technical concept. It is a commercial one. A programme with integrity is a programme that can answer, at any moment, the question the NEC contract keeps asking: if something changes now, what is the effect on planned completion and how do we know? A programme that cannot answer that question honestly, quickly, and from its own internal logic has lost integrity, regardless of how professional it looks on screen.

This article describes five signs that a programme has lost integrity. None of them require specialist planning knowledge to identify. A project director, a commercial manager, or a contracts manager can check for each of them in a single meeting. The value of checking is not academic. Each sign corresponds to a specific commercial exposure that grows quietly until it surfaces in a compensation event assessment, a delay dispute, or an adjudication.

Sign 1: the critical path has not moved since mobilisation

The critical path is the longest chain of dependent activities through the programme from the data date to planned completion. It determines the earliest possible completion date and identifies which activities, if delayed, will delay the whole project. On a live construction project, the critical path moves. Progress on some activities is faster or slower than planned. Compensation events change the sequence. Design information arrives late or early. Weather affects certain trades and not others. Subcontractors mobilise at different rates. The critical path responds to all of this.

A programme where the critical path has not changed since the first accepted programme is a programme that is not being updated honestly.

This is one of the easiest signs to check and one of the most reliable. Ask the planner to show the critical path today and compare it to the critical path from the first accepted programme. If the chain of critical activities is identical, despite months of progress, compensation events, and the inevitable disruption of a live construction project, the programme has not been recalculated to reflect reality. It is showing the original plan, not the current forecast.

The commercial consequence is direct. When a compensation event arises and the contractor needs to demonstrate a time impact, the impact is measured through the critical path. If the critical path is stale, the impact analysis is built on a fiction. The project manager will challenge it. An adjudicator will question it. The contractor's time entitlement is weakened because the programme cannot credibly show the chain of cause and effect that the contract requires.

A live, properly maintained programme will show a critical path that shifts over time as the project progresses. That movement is not a sign of poor planning. It is a sign of honest planning. The article on NEC delay analysis and extension of time explains why the critical path at the dividing date determines the strength of the contractor's time entitlement.

Sign 2: compensation events have disappeared from the programme

On any NEC project of reasonable size, compensation events accumulate throughout the life of the job. Design changes, late information, physical conditions, employer access failures, weather events meeting the threshold. A project that has been running for twelve months will typically have between fifteen and forty notified compensation events, some implemented, some pending, some still in quotation.

The programme should show all of them. Not as a separate register or a spreadsheet sitting alongside the programme, but as visible elements within the schedule itself. Implemented compensation events should be incorporated into the programme as accepted changes. Pending compensation events should be shown as proposed changes, clearly coded so the project manager can distinguish them from baseline activities.

A programme where compensation events are invisible, where the planner cannot point to CE-07 or CE-15 in the schedule and show the activities, the logic, and the impact, is a programme that has lost its connection to the commercial reality of the project. The compensation events are real. They are affecting the work. They are the basis of the contractor's time and cost entitlement. A programme that does not show them cannot demonstrate that entitlement.

The check is straightforward. Ask the planner to filter the programme by compensation event number and show you CE-07. If the filter returns nothing, or if the planner has to search manually through hundreds of activities to find something that might be related, the programme has no structured approach to tracking compensation events. The article on Primavera P6 for NEC programmes explains how activity codes and a dedicated WBS node for compensation events solve this problem at the point of schedule design.

The commercial consequence of invisible compensation events is that the contractor cannot produce clean quotations. Each quotation under clause 62.2 must show changes to the accepted programme caused by the compensation event. If the programme has no structured record of which activities belong to which event, every quotation becomes a reconstruction exercise rather than a filter-and-present exercise. That costs time, costs credibility, and costs entitlement.

Sign 3: planned completion and the completion date are the same

This is the quietest sign of lost project programme integrity and potentially the most expensive.

Under NEC4, planned completion is the contractor's forecast of when the works will actually finish. The completion date is the contractual obligation. The gap between them is terminal float, which belongs to the contractor under clause 63.5. When a compensation event delays planned completion, the completion date moves by the same amount, preserving the terminal float. This mechanism protects the contractor's risk margin against employer-caused delay.

A programme where planned completion sits exactly on the completion date has zero terminal float. This means either the contractor has planned with no risk margin at all, which is almost never realistic, or the planner has set planned completion to match the completion date because it looked cleaner or because they did not understand the commercial significance of the distinction.

The consequence is immediate and measurable. When a compensation event delays the critical path by two weeks, a programme with two weeks of terminal float would move the completion date by two weeks. A programme with zero terminal float absorbs those two weeks into the contractor's own time before the completion date moves at all. The contractor has given away the mechanism the contract provides to protect their position.

The check takes thirty seconds. Open the programme and compare the planned completion date to the completion date. If they are the same, ask the planner why. If the answer is "that is when we plan to finish," ask whether the contractor genuinely believes, on this specific project, that there is zero risk of any activity taking longer than the base estimate. The answer will be no, because on every construction project some things take longer than planned. That risk should be visible as terminal float. The article on time risk allowance and terminal float in NEC covers this distinction in detail.

Sign 4: progress shows delay but the end date has not moved

This is the sign that project managers spot fastest, because it is the one that looks most obviously dishonest.

The programme is updated with progress. Several activities on or near the critical path show actual durations longer than planned. The data date has moved forward by four weeks. The project is clearly behind the previous accepted programme. But planned completion has not changed. The end date is exactly where it was before.

There are only three explanations for this. The first is that the contractor has implemented genuine mitigation: additional resources, re-sequenced work, acceleration measures that have recovered the time. If this is the case, those measures should be visible in the programme as changed logic, additional activities, or revised resource loading, and the programme narrative should explain them.

The second is that the critical path has shifted. The activities that were delayed were not actually on the critical path, and the path through other activities still reaches planned completion on time. If this is the case, the critical path report should show a different chain from the previous revision, and the planner should be able to explain why the delayed activities did not affect completion.

The third explanation is that the planner has manipulated the programme to hide the delay. Constraints have been added to force downstream activities to earlier dates. Logic links have been changed to create false parallelism. Durations have been shortened without justification. The programme shows the date the contractor wants to present rather than the date the schedule calculates.

The first two explanations are legitimate. The third destroys programme integrity and creates a specific commercial risk. A programme that hides delay cannot demonstrate the time impact of a compensation event, because the baseline it presents is false. When the project manager or an adjudicator tests the programme, the manipulation becomes visible and the contractor's credibility is damaged along with their entitlement.

The check is simple. If progress shows delay but the end date has not moved, ask for the explanation. If the explanation is mitigation, ask to see it in the programme. If the explanation is a critical path shift, ask to see the current critical path compared to the previous one. If neither explanation is offered, or if the explanation does not match what is visible in the programme, the integrity has gone.

Sign 5: nobody can explain how a specific activity connects to planned completion

This is the test that reveals programme integrity more reliably than any technical check, and it requires no scheduling expertise to apply.

Pick any activity at random from the programme. It can be a design approval, a concrete pour, a procurement item, a commissioning activity, anything. Ask the planner: if this activity is delayed by two weeks, what happens to planned completion?

On a programme with integrity, the planner can answer that question by tracing the logic chain from the selected activity through its successors to planned completion. They can show whether the activity is on the critical path or near it, how much float it has, and what the downstream effect of a two-week delay would be. The schedule demonstrates the answer mechanically, without the planner needing to assert it from memory or judgement.

On a programme that has lost integrity, the planner cannot answer the question. Either the activity has no successor links (an open end), which means the schedule cannot calculate the downstream effect at all. Or the activity has logic links but they do not reflect reality, so the calculated effect is wrong. Or the planner simply does not know, because the programme has grown to a point where nobody understands the relationships between activities and the logic has not been maintained.

This test works because NEC compensation event assessment depends on exactly this capability. Every compensation event is assessed by asking: what is the effect of this event on planned completion, as shown on the accepted programme at the dividing date? If the programme cannot trace a logical chain from the affected activity to planned completion, it cannot answer the question. The contractor's quotation then relies on narrative assertion rather than schedule demonstration, which is weaker, slower, and more likely to be challenged.

Running this test on three or four random activities takes ten minutes and tells you more about the state of the programme than any number of health check reports or schedule quality metrics. If the planner can trace the logic confidently every time, the programme has integrity. If they cannot, it does not.

Why programmes lose integrity and how to prevent it

Programmes do not lose integrity through a single catastrophic failure. They lose it gradually, through the accumulation of small compromises.

A planner under time pressure skips the logic review before submitting a revision. A constraint is added to force a date for a client presentation and never removed. Progress is updated using percentage complete rather than actual start, actual finish, and remaining duration. A compensation event is incorporated by adjusting a few durations rather than building a proper fragnet. A baseline comparison is not run because the previous accepted programme is so old that the comparison would be embarrassing. A narrative is not written because nobody reads it anyway.

Each of these compromises is small. Each is understandable in context. And each degrades the programme's ability to do the one thing the NEC contract requires it to do: demonstrate the effect of change on planned completion from a credible, current, internally consistent baseline.

Prevention is a discipline, not a technology. The article on NEC clause 31 programme acceptance covers the initial acceptance requirements. The article on clause 32 programme revision covers the revision discipline. The article on Primavera P6 for NEC programmes covers the schedule design choices that either support or undermine integrity over time. Together, those three disciplines, acceptance, revision, and design, are the framework that keeps a programme honest throughout the project.

For contractors who do not have a dedicated planning function to maintain this discipline, specialist programme support provides it as a managed service. The cost is small relative to the commercial exposure a single integrity failure creates when a compensation event, a delay dispute, or an adjudication tests the programme and finds it wanting.

Summary

A programme that has lost integrity looks exactly like one that has not. It opens in the same software, produces the same Gantt chart, and fills the same screen with bars and links and dates. The difference is invisible until the programme is tested, and by then the commercial damage is done.

The five signs described in this article are simple checks that any project director, commercial manager, or contracts manager can apply without specialist planning knowledge. A critical path that has not moved. Compensation events that have disappeared. Planned completion sitting on the completion date. Progress showing delay without the end date moving. Nobody being able to explain how a specific activity connects to planned completion.

Any one of these signs means the programme's ability to demonstrate compensation event entitlement is compromised. Two or more means the programme has lost the commercial protection the NEC contract was designed to provide. All five together means the contractor is operating without a functioning baseline and will discover that fact at the worst possible moment. This is not unusual on projects where the programme is treated as an administrative output rather than a commercial tool.

The checks take ten minutes. The discipline to fix what they reveal takes a decision. The commercial protection that discipline provides is the difference between a contractor who can demonstrate entitlement cleanly and one who arrives at adjudication with a programme that cannot support the claim it is supposed to prove.

FAQ

About the author

Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BSc in Mechanical Engineering and postgraduate training in Planning and Control.

NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.

Discuss your project | LinkedIn | About NEC Planning Solutions

Concerned about the state of your project programme?

If any of the five signs in this article are present on your project, the programme is not providing the commercial protection the NEC contract was designed to deliver. Specialist NEC programme support can assess the current state, identify what needs to change, and restore the revision discipline that keeps the baseline honest.