In the previous article we looked in detail at what an NEC programme should contain and why items such as logic, float, time risk allowance, Client obligations and realistic sequencing matter.

But producing a technically compliant programme is only part of the process.

The programme then has to be submitted to the Project Manager for acceptance.

This is where difficulties frequently arise.

On many NEC projects, programme submissions pass backwards and forwards for several reporting periods. The Project Manager raises comments, the Contractor revises the programme, further comments follow and the project gradually finds itself operating without a current Accepted Programme.

That is more than an administrative inconvenience.

The Accepted Programme plays a central role in the contractual management of time and, particularly, in the assessment of compensation events. A prolonged failure to obtain acceptance can therefore have significant commercial consequences for the Contractor.

The important question is not simply:

“How do we get the programme accepted?”

It is:

“What is the contractual test for acceptance, and how should the Contractor manage that process without compromising the integrity of its programme?”

Acceptance is not approval

One of the first distinctions to understand is that NEC deliberately uses the word acceptance, rather than approval.

The Contractor remains responsible for its programme and for Providing the Works.

The Project Manager accepting a programme does not transfer responsibility for the Contractor’s construction strategy to the Client.

Nor does acceptance mean that the Project Manager agrees with every commercial implication that might be inferred from the programme.

For example, suppose a revised programme shows planned Completion later than the contractual Completion Date.

Acceptance of that programme does not automatically mean:

• the Completion Date has changed;
• the Project Manager accepts that the Client caused the delay;
• the Contractor has established an entitlement to additional time; or
• compensation events shown within the programme have been agreed.

The Completion Date changes through the mechanisms provided by the contract, principally through the implementation of compensation events and, where applicable, agreed acceleration.

The programme records the Contractor’s current plan. It does not itself amend the contractual Completion Date.

This distinction is particularly important because Project Managers can sometimes become reluctant to accept a programme which shows an unfavourable completion forecast.

That is not, by itself, a contractual reason for withholding acceptance.

NEC itself describes acceptance essentially as a response of non-objection and confirms that there are four stated reasons for not accepting a programme.

The Project Manager does not have an unrestricted right to reject the programme

Under NEC4 ECC clause 31.3, the Project Manager normally has two weeks following submission to notify either:

• acceptance of the programme; or
• the reasons for not accepting it.

More importantly, the grounds for non-acceptance are defined.

Broadly, the Project Manager may withhold acceptance because:

1. the Contractor’s plans are not practicable;
2. the programme does not show the information which the contract requires;
3. the programme does not represent the Contractor’s plans realistically; or
4. the programme does not comply with the Scope.

These four tests are fundamental to understanding the acceptance process.

A Project Manager should therefore not be reviewing the programme simply on the basis of whether they personally like the sequence, whether the programme produces a convenient result or whether they would have planned the works differently.

There needs to be a contractual basis for withholding acceptance.

Equally, Contractors should not treat every PM comment as invalid merely because it is not written using the precise wording of clause 31.3.

The real question is whether the issue identified genuinely falls within one of the contractual acceptance tests.

1. Are the Contractor’s plans practicable?

A programme can be technically well constructed and still fail the acceptance test because the plan simply cannot realistically be delivered.

For example, a programme might show:

• output rates significantly greater than the available resources could achieve;
• several operations requiring the same specialist crew at the same time;
• work starting before access is available;
• construction beginning before essential design is complete;
• insufficient curing or testing periods;
• commissioning activities overlapping in a physically impossible sequence;
• multiple trades occupying the same restricted work area simultaneously; or
• reliance on plant or specialist resources which will not be available.

This is where the programme needs to be more than a mathematically functioning CPM network.

A programme can calculate correctly and still be impossible to build.

The Project Manager is entitled to test the programme against the methodology, quantities, available resources and physical constraints of the works.

Contractors should therefore carry out the same challenge internally before submission.

If an activity requires 1,000 units of production over five working days, the planning team should be able to explain what labour, Equipment and production rates support 200 units per day.

If four activities are planned concurrently using the same specialist team, the programme needs to demonstrate how that is achievable.

This is one reason why a good programme narrative can be valuable. It gives the Project Manager an explanation of the assumptions sitting behind the programme rather than leaving them to infer those assumptions from the scheduling software.

2. Does it show the information required by the contract?

The second acceptance test is whether the programme shows the information the contract requires.

The detailed requirements were covered in the previous article, so there is little value in repeating the full Clause 31.2 list here.

The more important point from an acceptance perspective is that Contractors should make compliance easy to verify.

The planning team may know that access requirements, Key Dates, float, time risk allowances, Client information requirements and other contractual items are included somewhere within a 3,000-activity programme.

The Project Manager should not have to search for them.

A simple programme compliance matrix can be extremely effective.

For each contractual requirement, identify where it is demonstrated:

Requirement	Where demonstrated
Completion Date	Programme milestone
Planned Completion	Programme milestone
Key Dates	Programme / milestone schedule
Time risk allowances	Dedicated programme field
Client information requirements	Interface milestones
Work by Others	Identified activities
Resource assumptions	Narrative / resource report
Scope-specific requirements	Relevant submission document

This changes the acceptance discussion from:

“We think everything is in there.”

to:

“Here is precisely where every contractual requirement is demonstrated.”

It also helps distinguish genuine contractual defects from general programme-review comments.

3. Does the programme represent the Contractor’s plans realistically?

Practicability and realism are closely related, but they are not quite the same issue.

A sequence may theoretically be achievable but still fail to represent what the Contractor actually intends to do.

This often becomes apparent on revised programmes.

Examples include:

• activities shown as started when they have not started;
• incorrect actual dates;
• remaining durations inconsistent with the site position;
• logic retained from an earlier construction methodology which is no longer being followed;
• subcontractor sequences that have changed but have not been incorporated;
• procurement dates which everyone knows are no longer achievable;
• large numbers of constraints introduced merely to maintain a particular Completion forecast; or
• unexplained critical-path movement between reporting periods.

A particularly dangerous situation arises when commercial pressure begins to influence programme status.

Suppose everyone on the project knows that a work package is several weeks behind, but the programme continues to show the original dates because updating them would push planned Completion beyond the Completion Date.

That may create a more attractive report.

It does not create a better NEC programme.

In fact, it potentially damages the Contractor’s own position because the contemporaneous programme record no longer represents what is actually happening.

A realistic programme does not necessarily tell a favourable story.

It tells a credible one.

4. Does the programme comply with the Scope?

This fourth ground is particularly important because NEC programme requirements do not stop with the standard clauses.

The Scope may contain extensive project-specific planning requirements.

These might prescribe matters such as:

• activity coding;
• work breakdown structures;
• maximum activity durations;
• calendars;
• progress-measurement rules;
• schedule-health requirements;
• Primavera P6 settings;
• resource or cost loading;
• narratives;
• procurement schedules;
• design programmes;
• reporting formats; or
• particular electronic deliverables.

A Contractor can therefore produce a programme which contains the core contractual information but which is still capable of non-acceptance because it does not comply with a specific requirement contained in the Scope.

This is why the programme team should establish a contract compliance register at the start of the project rather than discovering requirements individually after each rejected submission.

The register should identify requirements from the:

• conditions of contract;
• Contract Data;
• Scope;
• amendments; and
• relevant secondary options.

Once established, it can be checked before every submission.

A PM comment is not necessarily a reason for non-acceptance

This distinction is extremely useful on live projects.

A Project Manager may have dozens of observations about a programme.

Some may identify genuine contractual defects.

Others may simply be:

• requests for clarification;
• planning preferences;
• suggestions for improvement;
• reporting comments;
• questions about assumptions; or
• issues that can be addressed in the narrative without changing the programme.

Contractors should therefore avoid treating a schedule of 30 PM comments as automatically meaning there are 30 reasons why the programme cannot be accepted.

The response should categorise them.

For each material comment, ask:

Which of the four clause 31.3 acceptance tests does this engage?

If there is a genuine defect, correct it.

If clarification is required, provide it.

If the PM is requesting a change that falls outside the contractual acceptance test, the Contractor should explain why the programme remains capable of acceptance.

That is far more effective than exchanging repeated versions of the programme without identifying the actual contractual disagreement.

What if the Project Manager refuses acceptance because of the Completion forecast?

This deserves particular attention because it is a common source of disagreement.

Imagine the Completion Date is 30 September.

The latest programme now forecasts planned Completion on 31 October.

The Project Manager may understandably be concerned.

But that does not mean the programme should be changed simply so that planned Completion returns to 30 September.

The correct questions are:

• Is the forecast realistic?
• Does it accurately reflect current progress?
• Is the remaining logic practicable?
• Are outstanding compensation events properly represented?
• Does the programme contain the required information?
• Does it comply with the Scope?

If it does, the fact that planned Completion is later than the Completion Date does not itself create an additional ground for non-acceptance.

Equally, acceptance does not concede that the Contractor is entitled to the additional month.

The programme may be showing Contractor delay, Client delay, unresolved compensation events or a mixture of all three.

Those matters must be dealt with through the appropriate contractual mechanisms.

Acceptance should not be used to rewrite that position.

Do not manipulate an accurate programme merely to obtain acceptance

This is where Contractors need to exercise some discipline.

There can be significant pressure on a planning team to make changes because:

• the critical path is politically inconvenient;
• a Client activity appears critical;
• planned Completion has moved;
• an unimplemented compensation event appears to be delaying the works; or
• management wants the programme to maintain the contractual date.

Not every requested change should be resisted.

If the PM identifies defective logic, inaccurate progress or an unrealistic duration, it should be corrected.

But changing an otherwise accurate programme purely to produce a more convenient result creates a different problem.

Clause 31.3 requires the programme to represent the Contractor’s plans realistically.

Manipulating logic or progress merely to force the programme back to a preferred Completion date may therefore make the programme less compliant rather than more compliant.

A programme workshop is often the best way to resolve these disagreements.

Rather than exchanging comments remotely, the Contractor and Project Manager can review:

• progress;
• remaining durations;
• methodology;
• critical-path movement;
• logic changes;
• resource assumptions;
• Client interfaces;
• compensation events; and
• the basis of the Completion forecast.

The objective should be to understand the programme, not negotiate the answer produced by it.

What should a Contractor do following non-acceptance?

Non-acceptance should be dealt with quickly.

Waiting until the next four-week reporting cycle can be a serious mistake.

If the next submission then generates another round of comments, the project may operate for several months without a current Accepted Programme.

A better process is:

1. Review the PM’s response immediately

Identify each substantive reason for non-acceptance.

2. Map each reason to clause 31.3

Determine whether the issue relates to practicability, missing information, realism or Scope compliance.

3. Separate defects from comments

Not every observation requires modification of the programme.

4. Correct genuine defects

There is little commercial benefit in defending an obvious scheduling error.

5. Understand the effect of each correction

Before altering logic or durations, determine whether the change affects:

• planned Completion;
• Key Dates;
• float;
• the critical path;
• Client obligations; or
• compensation-event assessments.

6. Resolve technical disagreements directly

A programme workshop can often resolve issues faster than formal correspondence.

7. Resubmit promptly

Do not automatically wait for the next routine programme submission date.

8. Maintain a clear audit trail

Keep the original submission, PM comments, Contractor responses and revised files.

That audit trail can become extremely important if the programme history is later examined during a delay or compensation-event dispute.

Continue submitting programmes even where acceptance remains disputed

Another mistake is for the Contractor to stop making meaningful revised submissions because the previous programme was not accepted.

That normally makes the situation worse.

The project continues to evolve:

• activities start and finish;
• progress changes;
• compensation events occur;
• procurement develops;
• designs are issued;
• subcontractors change;
• mitigation measures are introduced; and
• the critical path moves.

If the Contractor stops maintaining and submitting its programme, the contemporaneous record deteriorates.

The planning team should therefore continue producing accurate programme updates while separately addressing the acceptance dispute.

A sequence of well-prepared programmes showing the actual development of the works may later be considerably more valuable than a programme history containing large unexplained gaps.

Why operating without an Accepted Programme is dangerous

The commercial consequences become particularly important when compensation events arise.

NEC4 uses the Accepted Programme current at the relevant dividing date as the contractual basis for assessing the time consequences of a compensation event.

This is deliberately prospective.

The intention is to forecast the effect of the event using the programme position applicable at that time rather than waiting until the project has finished and retrospectively reconstructing the delay. NEC guidance confirms the importance of the Accepted Programme current at the relevant dividing date.

That mechanism works best where there is a current and credible Accepted Programme.

If the Contractor’s latest programme has not been accepted for a contractual reason, the position becomes materially less attractive.

NEC guidance explains that in relevant circumstances the Project Manager is required to make their own compensation-event assessment and their own assessment of the programme for the remaining works.

From the Contractor’s perspective, this represents a significant loss of control.

Instead of demonstrating the forecast effect of the event against its own current Accepted Programme, the Contractor may find the Project Manager developing an alternative view of:

• remaining logic;
• durations;
• sequencing;
• float;
• mitigation; and
• the effect on planned Completion.

That alone should make maintaining an up-to-date Accepted Programme a major commercial priority.

The 25% retention is often misunderstood

Another point worth separating from general programme non-acceptance is the NEC payment mechanism relating to the first programme.

It is sometimes suggested that the Project Manager can simply withhold 25% of every assessment whenever a revised programme is not accepted.

That is not the position.

NEC’s published guidance explains that the mechanism relates specifically to the required first programme where no programme was identified in the Contract Data and that programme has not been provided showing the information required by the contract.

It is therefore not a general penalty which can be applied every time a subsequent programme is not accepted for any reason.

This distinction is important because programme acceptance and programme payment sanctions are sometimes incorrectly treated as the same issue.

What if the Project Manager simply does not respond?

NEC4 also provides a mechanism to prevent a submitted programme remaining indefinitely unanswered.

The Project Manager normally has two weeks to respond.

If no response is provided, the Contractor may notify the Project Manager of that failure.

If the Project Manager then fails to respond within a further week, NEC4 provides for the programme to be treated as accepted.

NEC has confirmed that a programme which becomes treated as accepted has the same contractual status as one positively accepted by the Project Manager.

This can be an important protection for Contractors.

However, it should not become the normal programme-management strategy.

A technically difficult project where programmes repeatedly become accepted simply because the PM fails to respond is unlikely to have achieved the collaborative understanding NEC is intended to create.

Positive acceptance after a proper review is preferable.

But where the contractual response periods expire, Contractors should understand and use the mechanisms available to them rather than allowing programme submissions to remain unanswered indefinitely.

The objective should be a current Accepted Programme

There is another important distinction here.

Having an Accepted Programme is not enough.

A project could technically have an Accepted Programme which is six months old.

Its contractual status may remain important, but as a management tool it may now be almost useless.

During those six months:

• actual progress may have diverged significantly from plan;
• compensation events may have occurred;
• the construction sequence may have changed;
• different subcontractors may have been appointed;
• design may have developed;
• mitigation may have been introduced; and
• an entirely different critical path may have emerged.

The real objective is therefore:

a current, realistic and contractually compliant Accepted Programme.

That is a much higher standard than simply being able to point to an old programme carrying an acceptance notification.

A practical acceptance strategy for Contractors

A disciplined acceptance process can significantly reduce repeated programme rejection.

Before each submission:

Check the contractual acceptance tests

Ask whether the plan is practicable, complete, realistic and compliant with the Scope.

Run a schedule-quality review

Check open ends, constraints, unusual lags, calendar changes, negative float and unexplained critical-path changes.

Reconcile the programme with the site

Actual dates and remaining durations should reflect what is genuinely happening.

Check the methodology and resources

Make sure that the programme can actually be delivered using the proposed labour, plant and working arrangements.

Review the change from the previous programme

Understand exactly why planned Completion and the critical path have moved.

Provide a concise narrative

Explain the key changes instead of expecting the PM to identify them by comparing thousands of activities.

Identify unresolved compensation events

Their status and programme effect should be transparent.

Make Client interfaces visible

The PM should be able to identify exactly when access, information, acceptance or work by Others is required.

Discuss major issues before formal submission

If the critical path has changed substantially or Completion has moved materially, a programme workshop before submission may avoid an unnecessary rejection cycle.

Acceptance and programme integrity need to coexist

Contractors are sometimes presented with what appears to be a choice:

Do we maintain the programme we believe is correct, or change it so that the Project Manager will accept it?

That is usually the wrong way to frame the issue.

The objective should be both:

an accurate programme and an Accepted Programme.

If the programme contains genuine defects, correct them.

If the Project Manager has misunderstood the Contractor’s methodology, explain it.

If information is missing, provide it.

If the Scope has not been complied with, rectify the submission.

But if the programme accurately records an uncomfortable project position, it should not be rewritten simply to make that position disappear.

The Accepted Programme is too important to become a negotiated version of reality.

Conclusion

Programme acceptance under NEC is not simply an administrative process attached to monthly reporting.

It determines which programme has contractual status and can have a major influence on how the time consequences of compensation events are assessed.

For Contractors, the key is to understand that the Project Manager’s acceptance test is not unlimited.

The programme must:

• be practicable;
• contain the information required by the contract;
• represent the Contractor’s plans realistically; and
• comply with the Scope.

Where genuine defects are identified, they should be corrected quickly.

Where non-acceptance is based on something outside those tests, the Contractor should understand the contractual position and respond accordingly.

Most importantly, the pursuit of acceptance should never result in the programme becoming less accurate.

The strongest position is not merely to possess an Accepted Programme.

It is to maintain a current, realistic, properly evidenced and Accepted Programme which genuinely reflects how the Contractor intends to complete the works.

That is what allows the programme to perform its real NEC function: managing the remaining works, recording the developing project position and providing a credible contractual basis for assessing change.