ECC Clause 31.2 is indeed one of the longest in the whole Contract, which provides a comprehensive list of what should be included within each programme issued for acceptance.
It includes:
- starting date, access dates, Key Dates and Completion Date
- planned Completion
- order and timing of the operations which Contractor plans to do
- provisions for float
- provisions for time risk allowances
- dates when in order to provide the works the Contractor will need access to any part of the site, acceptances, Plant and Materials provided by the Client, Information from others
- any other information that is requested within Scope
- statement of how the Contractor plans to do the work identifying principal equipment and resources which will be used
Further detail on some of these specific elements listed within ECC Clause 31.2:
Key Dates: An aspect of the suite of NEC contracts is that there is no mechanism for the Client to nominate single subcontractors or suppliers; otherwise it could lead to uncertainty as to who would be accountable for any delay or additional cost for underperformance by that subcontractor. The Contractor would probably feel it is the Client liability as they told them to use them, whilst the Client may blame the Contractor for not managing them properly. The contract therefore does not allow for this and the only place to put any such requirement would be within the Scope, but the Client would have to consider carefully about how they include this and how much choice they are giving the Contractor in terms of approved subcontractors or suppliers.
Key Dates were introduced with NEC3 in 2005. NEC2 only had sectional completions(if secondary option X5 chosen) and Completion Date as contractual milestones. These did not really help the Client to add constraints without having to take over that section of works. The use of Key Dates now requires a Contractor to meet certain conditions by a certain date. This might be completing some construction work, before letting an electrical company in to install a panel, whilst allowing the Contractor to complete the remainder of works in that building. These Key Dates would be identified at tender stage within contract data 1, and is not something that can be added mid-contract (unless by agreement under clause 12.3).
The main aspect of Key Dates is that if a Contractor fails to meet the condition stated by the agreed date, then any cost resulting from this failure that the Client incurs will be payable by the Contractor. Unlike delay damages, which are defined in contract data part 1, these costs will not be defined in advance. For this reason it is very important that these Key Dates are managed on the programme and that the Contractor nearer the time is aware of any implications that would result from not meeting the date. They should be managed in accordance with the early warning and compensation event processes, in as much as if there could be a delay in meeting a Key Date then an early warning should be notified, and if an event will be delayed by something not under the Contractor’s control or liability then a compensation event notified.
Completion Date and planned Completion: The very fact that these two requirements feature as separate items should make it clear that they are distinctly different and need to be treated as such on the programme. There should always be a “planned Completion” milestone and a “Completion Date” milestone on every programme. Completion Date is a fixed milestone and is the trigger point for which delay damages would be applicable. It will only move in or out in time due to one of two contractual mechanisms. It will only move out (i.e. later in time) as and when compensation events (CE’s) are agreed (implemented) that has affected the Contractors ability to complete by the current planned Completion date. Equally there is only one mechanism that will bring a completion date back (earlier), which interestingly is not due “negative compensation events”. Negative compensation events whilst almost certain to bring a direct cost saving will not move this contractual milestone. The only thing that can bring it forward in time under the contract is acceleration (clause 36).
Planned Completion is simply when the contractor “plans” to finish and in simple terms is linked to the contractor’s last planned site activity (activities required to meet the Completion). This can be moving in or out in time depending on whether the Contractor is ahead or behind in terms of progress. In simple terms planned Completion can move due to “anything”, but will not necessarily have a direct effect on the Completion Date.
Consider planned Completion as reflecting reality, with Completion Date intimating liability. If a Contractor is showing on a programme issued for acceptance planned Completion beyond Completion Date, it would either be the Contractors liability, or the delay would need to be due to a notified compensation event yet to be agreed(implemented), which is why planned Completion has moved out.
Order and timing of Contractors operations: “Order and timing of activities” can most easily be demonstrated by the traditional logic linked bar chart programme to show the activities planned and the dependencies between them. These programmes are normally created on one of the various programme software packages (e.g. Privavera, Asta Powerproject), which then allows the programme to be instantly updated when durations or logic changes. Whilst the programme software is very clever – it is created from the manual information fed into it by the operator, and like in most procedures or systems “rubbish in = rubbish out”. Having the full work scope on the programme to a good level of detail and fully logic linked will make the programme a real management tool to measure progress and change on the project.
Float and time risk allowances: these are two of the main considerations in terms of “float” on a project, the other being the difference between planned Completion and Completion Date which is commonly known as (and as referred to in the NEC guidance notes) as terminal float. This section will consider in detail these three types of float, how they should be shown/managed and most importantly who owns which float under the contract:
Float: This is what is commonly known as “total float” and it demonstrates which activities can slip in time without affecting the planned Completion, and those that can not. Float is something that is generated by default within the programme software, not something that has to be created or thought about manually. Once the logic has been created in the planning software by the use of links, this will determine the planned Completion, which will in very simple terms follow on from your last planned activity. This by default will create your “critical path” which sets the overall duration of your project at that point in time and hence the earliest date that you believe you can complete the project by. It has been questioned why the programme requirements in the contract do not ask for critical path. It is actually there by default, in as much as the critical path is simply where float equals zero and the contract asks you to demonstrate float.
The ownership of this type of float is actually shared under the contract. To put it another way, it is also whoever gets there first, although it is important either party do not “have a race” to see who can use it up first! It is shared in as much as it is available to accommodate either the effects of a compensation event or lack of progress/re-sequence by the Contractor. It is in both Parties interest to have activities with as much float as possible i.e. complete them as early in the project as possible, as this limits the risk of the overall project over-running. Contractors might also question why they can not show a contract programme with no float i.e. every activity is critical and any will affect planned Completion if they slip by even a day. In most cases if everything on a programme is critical then it is likely by default not to be achievable or realistic. This would be a reason not to accept a programme (see reference to clause 31.3, reason for non-acceptance of a programme) issued to the Project Manager for acceptance. Whether acceptable or not would also be dependant on any elements of time risk allowance included, which leads to the next form of float that the contract requires to be shown:
Time Risk Allowance: This is actually quite a simple element of float but is often much misunderstood and mismanaged. The contract is requiring the Contractor to demonstrate what elements of risk they have applied to a given activity when ascertaining its duration. In truth, this in the past would have been considered during the estimating phase, but just not necessarily formally recorded and named as “time risk allowance”. The Project Manager on a project would particularly be interested to see that the critical path items have some elements of time risk allowance, which would give a stronger degree of comfort that the Completion Date is achievable. This type of float is owned by the Contractor, and is retained when considering the effects of a compensation event.
This has always been considered by Contractors when building up a tender but just not labelled “time risk” before. During a tender period, it might say have been considered that an activity will take thirteen days to complete based on the resources being used and the optimum output that can be expected of that size gang in the particular site conditions. However, those thirteen days is probably the best that can ever be achieved. Therefore, a consideration as to the likely risk for that activity in terms of say weather, down time, inefficiencies etc. would be made which might result in a duration of fifteen days for the estimate and programme purposes. Fifteen days will be carried forward to the programme, and the contract requires the Contractor to show how much of that period is time risk allowance (TRA). The most simple and effective way to show this in terms of the programme is to add an extra column on the programme entitled “TRA”. The programme would then show this activity as being a fifteen day bar on the programme, but with a TRA figure of two days.
Terminal Float (difference between planned Completion and Completion Date): This final different form of float that is also owned by the Contractor. This view is made clear in NEC4 clause 63.5 (previously 63.3 under NEC3) of the contract, where it reinforces the fact that Completion Date moves out the amount that planned Completion moves out on the last accepted programme due to the effects of a compensation event. This does seem logical as it may well be that the Contractor has expended additional cost to actually finish early for their own benefit, and it would then not be right if a Compensation event ate into that period preventing the Contractor to remove their resources from the site earlier like they had planned.
In simple terms, let’s consider a scenario where planned Completion is two weeks earlier than Completion Date on the Accepted Programme. If a subsequent Compensation Event affects the critical path by two weeks and hence planned Completion, Completion Date also moves out by two weeks (once the compensation event is implemented) maintaining the two week differential between these two milestones. If the Contractor takes two weeks longer to carryout an activity and this is not a compensation event, then planned Completion would move out by two weeks and Completion Date would remain where it was, with the Contractor using up their own terminal float.
It is important to consider what benefit this actually gives the Contractor. The Contractor does not benefit from any kind of defined cost for the period between planned Completion/Completion Date, so there is no direct financial benefit. Equally there is no issue with defect liability or maintenance periods as these would apply from Completion, which would/should follow quickly on from planned Completion. The only real benefit in having a planned Completion prior to Completion Date is the limitation in exposure to delay damages under the contract, which would apply should the Completion Date be exceeded.
As a Project Manager under the contract the only way to bring back a Completion Date if terminal float has been established is to request acceleration under clause 36.
Dates when in order to provide the works the Contractor will need access, plant/materials, acceptances etc: This elements can be summed up by saying “any Client or third party interfaces that has the ability to affect the Contractors works should be shown on the programme”. However, these will not normally be shown to the same high level of detail that the Contractor should go into for their own activities. Either an activity or a milestone can demonstrate to all concerned the date that the Contractor needs a design signed off, needs free issue material, or needs third parties to have completed an element of work before the Contractor can proceed with their next element of work. As long as these are shown clearly on the Accepted Programme, and things like acceptance periods shown are in accordance with the works information (you can not limit Client acceptance periods from those in the Scope) then it should be clear what the resultant effect would be should that element not occur as programmed. It is very important therefore that the Contractor has a suitable level of detail on their programme. If there is an element of Contractor work say eight weeks long and a compensation event affects part of that works – how can it clearly be demonstrated how much of the eight weeks has been affected? If this activity was broken down into smaller chunks of works, then this assessment will be clearer and much less subjective.
This should result in the Contractor’s programme being an integrated programme which will work to the benefit of all parties. The Contractor demonstrates all of their own activities to a good level of detail, as well as any Client/3rd party activities that interface with their work. The Contractor can also provide the Project Manager with a filtered programme of the Client’s deliverables that, providing are met by the dates shown, will maintain the Contractors ability to complete the programmed works on time.
Any other information required within Scope: As with any project you have to understand the contract that you are entering into and the implications of the specific contractual clauses. There may be additional requirements in the project specific Works Information that also need to be carried out or demonstrated. For example, there could be specific or additional reports to be carried out with each programme submitted for acceptance, or there could be the requirement to use specific planning software for the production of programmes.
Statement of how the Contractor plans to carry out the works: The words of this clause have subtly changed since the issue of NEC2 which use to read “a method statement of…” The words method statement in certain circles conjured up wrong images of what this statement should be in terms of a more traditional health and safety “method statement” that would be required for a site task. There have been projects in this situation that the Project Manager was not accepting under NEC2 because either the Contractor had not produced an all encompassing “method statement” or indeed issued all of the project method statements for a given project or shown them on their programme, which was not the original intent of the contract.
The programme itself can easily demonstrate some of the information that the statement is asking for. It is possible to show resources on the programme, in particular labour levels. In fact it is difficult to see how a programme can be properly evaluated without having resource levels on it. The bars shown may seem to be achievable in a given week, until you consider each activity needs six operatives and the cumulative number of resources you are showing being required is more than the total of the resources available to you. In that instance you would either have to delay some activities, or put less resources on each activity which in turn is likely to extend the duration of each activity. This can be show as an additional column on the programme showing number of resources. You could also have another column showing key equipment required for each operation. There is a balance to be struck here, as you end up with many columns on your programme (activity, start date, finish date, float, TRA etc.) but it is a case of showing the important columns alongside the bar chart itself for each programme produced (see example below.).
The statement required under this clause could be considered more practically speaking what might otherwise be called a programme narrative, focusing on forthcoming activities, remaining critical path and importantly what has changed and why since the last accepted programme. This statement should be issued with every programme submitted for acceptance to give the Project Manager the clear visibility of what the programme is showing. This should also speed up the acceptance process if the Project Manager can see what has changed and why, as the only thing the Project Manager then needs to assess is if they agree with the assessments and that it is not the Contractors liability if it has affected the planned Completion.