NEC Accepted Programmes: a practical guide1

Claire King edits Insight, our newsletter which provides practical information on topical issues affecting the building, engineering and energy sectors. In June 2022, Claire wrote about the NEC Accepted Programme. Here is an extract from that article.2

The Accepted Programme sits right at the heart of the NEC form of contract. Its aim is to encourage good project management by not only ensuring that all parties to the project know what they have to do and when, but also by facilitating the prompt and prospective assessment of compensation events as and when they occur on the project. In order to achieve these aims, numerous prescriptive procedures governing Accepted Programmes are provided for. 

All too often, however, these procedures break down, sometimes right from the beginning of the project. This can be for a wide variety of reasons, but all too often it is because parties do not fully understand what an Accepted Programme should contain or the processes for updating it.

NEC objectives and the role of the Accepted Programme

The NEC’s objectives are to “facilitate and encourage good management of risks and uncertainties, using clear and simple language.” To achieve that goal, the NEC encourages the early identification of problems and a proactive approach to addressing those problems. The idea is firmly that issues are resolved as work progresses so that there is no final account process (or associated dispute) at the end of the job. These goals are supported by prescriptive contractual procedures. All parties also have a duty to act in a “spirit of mutual trust and cooperation”.

The Accepted Programme is a key project management tool in the NEC form and is crucial for achieving the NEC’s objectives. Broadly, it has two roles:

1. To ensure that all parties know what they have to do, and when; and
2. To provide a tool to enable the prompt and (hopefully) prospective assessment of compensation events and, specifically, the extensions of time claimed pursuant to them.

A tool for assessing compensation events contemporaneously

The Accepted Programme is intended to encourage collaborative working and dispute avoidance. In particular, it provides a tool to allow the assessment of extensions of time (via compensation events) contemporaneously and without the need for a complex and expensive delay analysis.

Under Clause 63.5, the Accepted Programme is the tool the Project Manager should use for assessing compensation events. The Accepted Programme used for assessing an extension of time (compensation event) is the one current at the dividing date. The dividing date is set out in Clause 63.1: 

“For a compensation event that arises from the Project Manager or the Supervisor giving an instruction or notification, issuing the certificate or changing an earlier decision, the dividing date is the date of that communication. 

For other compensation events, the dividing date is the date of the notification of the compensation event”. [Emphasis added.]

Sometimes amendments are made to the definition of the dividing date. For example, stating that the dividing date is the date a quotation is requested. In the author’s view, this is to be discouraged. The logic of the dividing date in the definitions is that this is as close as possible to when the event itself occurred (assuming there is prompt notification of a compensation event). If the date is anything else, assessment can become much more difficult and theoretical (i.e., removed from the reality of what is happening on the ground), thus building in more room for unnecessary disputes. 

Obviously, the closer the Accepted Programme is prepared to the dividing date, the easier it should be for the Project Manager to assess the impact of any compensation event (and for a Contractor to update the Accepted Programme to show the impact of any compensation event). 

A hook for compensation events

Incorporating crucial dates into the Accepted Programme is encouraged by the fact that there are a number of specific compensation events which cross reference to the Accepted Programme. These include:

• Clause 60.1 (2): Failure to allow access by the date shown in the Accepted Programme;
• Clause 60.1 (3): The Client does not provide something by the date shown in the Accepted Programme; and
• Clause 60.1 (5): The Client or others do not work within the times shown on the Accepted Programme.

Clause 60.1 (19), the NEC equivalent to a force majeure provision, also expressly cross references to the Accepted Programme and, more specifically, the date shown for planned Completion shown in the Accepted Programme, as part of the test as to whether there is a compensation event or not. Obviously, in order to claim these compensation events, the Accepted Programme must have been prepared properly and contain the relevant dates as hooks for any claim. 

Carrots and sticks to encourage the production of an Accepted Programme

Given the central importance of the Accepted Programme, the NEC4 also contains both carrots and sticks to encourage their production and updating. Clause 50.5, for example, provides that if there is no programme in the Contract Data, one quarter of the Price of Work Done to Date is retained in assessments of the amount due until the Contractor has submitted a first programme (showing the information which the contract requires) to the Project Manager for acceptance.

Clauses 64.1 and 60.2 also provide a strong incentive for the Contractor to submit their programmes. If the Contractor does not do so, they lose control of the compensation event assessment process. First of all, the Project Manager is required to assess all compensation events3 and, secondly, the Project Manager should use their own assessment of what the programme should be to assess the impact of the compensation event.4

Setting up an Accepted Programme

Section 3 of the NEC4 contains all of the key provisions governing what the first Accepted Programme is and what it should contain. 

The first Accepted Programme is either the programme identified in the Contract Data or the programme to be submitted to the Project Manager for acceptance.5 It is important to note that the Accepted Programme and the Activity Schedule (for Options A or C) are not the same documents but are required to be correlated. Clause 31.4 (Option A) requires that “the Contractor provides information which shows how each activity on the Activity Schedule relates to the operations on each programme submitted for acceptance”. This is an ongoing duty and does not just relate to the first Accepted Programme. 

What must an Accepted Programme contain?

Assuming the first Accepted Programme is not already attached to the contract, then the contractor needs to note the very detailed and prescriptive information listed in Clause 31.2. This includes:  

• The starting date, access dates, Key Dates and Completion Date;
• Planned Completion;
• The order and timing of the operations which the Contractor plans to do in order to Provide the Works;
• The order and timing of work of the Client and Others as last agreed with them by the Contractor, or if not so agreed, as stated in the Scope;
• The dates when the Contractor plans to meet each Condition stated for the Key Dates and to complete other work needed to allow the Client and Others to do their work;
• Provision for float, time risk allowances, health and safety requirements, and the procedures set out in the Contract;
• The dates when the Contractor will need: access to a part of the Site if later than its access date, acceptances, Plant and Materials and other things to be provided by the Client, and information from Others;
• For each operation, a statement of how the Contractor plans to do the work identifying the principal Equipment and other resources which will be used; and
• Other information which the Scope requires.

An example of a programme showing key information is set out below:

Statement of how the Contractor plans to do the work

Along with each Accepted Programme, there is also a requirement for a statement of how the Contractor plans to do the work (sometimes called a programme narrative).6 This should include details of the:

1. Sequence of planned works;
2. Resources required (types and numbers);
3. Key equipment required;
4. Critical path;
5. Time risk allowances, assumptions used;
6. Key dates such as access dates or information from others; and
7. Description of working calendars and interfaces.

This is an important document and should be issued with every programme submitted for acceptance. Practically, it provides the Project Manager with visibility of what the programme is really showing. It also shows what has changed, and why, since the last Accepted Programme. As such, it is a vital project tool and, when done well, can help to prevent a breakdown of the Accepted Programme process. 

Reviewing the Accepted Programme

Once the Accepted Programme has been submitted, the Project Manager has two weeks to notify his acceptance or reasons for rejecting it. The reasons for rejecting the programme are limited to the following:

1. The Contractor’s plans are not practicable; 
2. It does not show the information required by the Contract;
3. It does not represent the Contractor’s plans realistically; or 
4. It does not comply with the Scope.7

When considering assessing the Accepted Programme, the Project Manager should act as they do when they are a certifier, i.e., impartially and take their duties under Clause 10 seriously.8

What happens if the Project Manager does not respond?

If the Project Manager does not respond within two weeks, then there is a useful deeming provision provided within the NEC4 which, unfortunately, is not present in the NEC3. After two weeks, the Contractor can submit a notice of failure to accept or reject the Accepted Programme under Clause 31.3. If the Project Manager remains silent after one week, then there is deemed acceptance of the programme. 

How do I deal with delays to the project?

Where you need to submit a quotation for a compensation event, this should include the assessment of (prospective) delay impact by the Contractor. As set out above, it is important to get the dividing date right and also to use the Accepted Programme that was “current at the dividing date”.9

Time impact is usually shown on the programme by adding new activities to model the delay event which will include new or extra time risk allowance (TRA) if appropriate. An example of how to show such a delay is set out below:

Common Problems

Unfortunately, too often we see issues building up right from the beginning of the project. For example, these problems include, but are in no way limited to:

1. Delays to the submission of the initial Accepted Programme meaning you are constantly trying to catch up and nobody can use the Accepted Programme as a project tool in the way intended;
2. Subcontractors providing Accepted Programmes which are not realistic and, therefore, extremely difficult to feed into the main contractor’s programme. This can be for a variety of reasons including the subcontractors’ own failure or lack of resources perhaps. However, equally, subcontractors quite often have to work from an incomplete picture provided by a main contractor and, accordingly, are shooting at an invisible target. Providing the necessary level of information to allow a subcontractor to properly programme their works is essential. Often, there is a circular process required with information exchanged on an interactive basis before the optimum level is reached;
3. While not catastrophic, working on different programming software can cause very real difficulties and make the timetable for flowing up a subcontractor’s Accepted Programme into the main contractor’s Accepted Programme more difficult;  
4. Quite often subcontractors are working on different contract forms meaning they have no obligation to provide regular updates, or if they do, they are in a slightly different format to that required by the NEC. This is something to avoid if at possible. Equally, if subcontractors are unfamiliar with the NEC form, they will need an education process so that they understand what is required from them;  
5. Constant rejection by Project Managers is not unheard of. Quite often this is because there is one issue in the original, or an early, Accepted Programme which is never quite resolved because the relevant people do not sit around the table to discuss it and understand the thought processes which underpin it. This initial rejection can be for a sensible reason but quite often snowballs as the Accepted Programme gets further and further behind the work being carried out on the project on the ground;
6. Occasionally, we also see deliberate rejection of Accepted Programmes by Project Managers (or contractors in relation to subcontractor programmes) so that they can assess the compensation events. This is not conduct we would recommend, not least because it leads to problems down the line and serves to harden people’s attitudes meaning that the collaborative ‘working together’ ethos of the NEC can be fatally undermined;10
7. Other issues include failure to show key information (such as dates when the client was to provide information or access to various parts of the site) on the Accepted Programme meaning there is no entitlement to compensation events. What should be an easy hit for a contractor or subcontractor then gives no entitlement; and
8. Accepted Programmes are submitted but do not show the potential impact of compensation events, which are disputed or not accepted at that time, “just in case”. This then makes assessing them very difficult for all involved.  

How can I get around these problems?

It is, of course, much easier to list the problems than to find solutions to them. However, practical advice to resolve these issues includes:

1. Sticking to the contractual deadlines right from the start. This means sufficient programming resource needs to be allocated. Getting the Accepted Programme right needs to be prioritised and put higher up the list of things to do. Main contractors need to get around the table with their subcontractors to discuss any issues and ensure the subcontractors can provide the information the main contractor needs to feed up the line;
2. Getting around the table and explaining what you have done (helped by a detailed programming statement) is also essential if issues are starting to build up. It may be that it is just not clear what the Accepted Programme is showing and why, but that once explained the problem can be resolved;
3. If problems continue and Accepted Programmes continue to be rejected (for what you consider to be invalid reasons), then it is even more important to continue the process. Continue to submit accurate updated programmes. They will save you both time and money if there is a dispute at the end of the project, and they are good contemporaneous evidence of delays if they are accurate. They are also intended to be a project management tool and, sticking to that, discipline should hopefully encourage good project management even when others are failing to perform their role;
4. Do not forget the Clause 31.3 notification process set out in the flow diagram below. That may be a way of getting deemed acceptance under the NEC4 programme (it does not apply to the NEC3 form) if a Project Manager is being particularly slow; and
5. Finally, it may be worth thinking about escalating the issue of the Accepted Programme further up the command chain. Getting an Accepted Programme agreed at the beginning of the job is important and if this is proving very difficult then it can be a recipe for problems later on in the project.  Clause W2 of the NEC4 provides for escalation to senior representatives, and parties should not be afraid to use this tool if necessary. One other tactic to consider (albeit an aggressive one) is to adjudicate and ask for a declaration that a programme should be accepted. This would undoubtedly be a bold step to take, particularly at the start of a project, and it may damage relationships going forwards. That said, if the Accepted Programme submitted is being rejected for minor or inconsequential issues (or, indeed, just so the Project Manger can assess compensation events), then this is the sort of behaviour that may be worth considering nipping in the bud. Otherwise, problems can rapidly snowball, and this is a recipe for a final account dispute down the line. 

Overview

Unfortunately, carrying out a delay analysis at the end of the job will take time and can be expensive. Furthermore, memories are not as fresh, staff leave, and records are lost, meaning that being in this position is always unattractive. For this reason, it is incumbent on all parties involved in NEC projects to try to understand, and fully buy into, the Accepted Programme process. In particular, to resolve issues as and when they occur so that they do not snowball. This is much easier if the programmes are accurate (both in terms of as-built data and logic) and supported by a detailed narrative explaining the thinking that lies behind it, and a transparent approach to showing delays and TRA is adopted.

Previous article [1] | Next article [2]

• 1. With thanks to Scott Jardine of Ankura for his excellent graphics.
• 2. The full version can be found here [3].
• 3. See Clause 31.1.
• 4. Ibid.
• 5. Ibid.
• 6. See Clause 31.2.
• 7. See Clause 31.3.
• 8. See Scheldebouw BV v St James Homes (Grosvenor Dock) Limited [2006] EWHC 89 (TCC).
• 9. See Clauses 10.1 and 10.2.
• 10. Ibid.