By Dr Samer Skaik
Ask three people on a FIDIC project what status the programme has, and you will usually get three answers.
The planner thinks it is a management tool. The contractor’s commercial manager thinks it is the baseline against which every delay claim will eventually be measured. And the Engineer, if pressed, will often say that it was never approved, which is a curious thing to say about a document the whole project has been working to for two years.
All three are partly right, and the confusion is not their fault. Sub-Clause 8.3 is one of the shortest provisions in the contract carrying one of the heaviest practical loads, and it does not answer the question everyone actually wants answered: is this thing binding?
What the clause requires
The mechanics are straightforward enough. The Contractor submits an initial programme within 28 days of the commencement notice. The Engineer has a window — 21 days — in which to give notice of the extent to which the programme does not comply with the Contract. If no such notice comes, the Contractor proceeds in accordance with the programme, subject to its other obligations. Whenever actual progress ceases to match, a revised programme follows.
The 2017 edition is considerably more prescriptive about content. It sets out an itemised list of what the programme must show, including the order of execution, the review and approval periods for design and documents, the sequence and timing of inspections and tests, and — a genuinely useful addition — an express requirement to identify the critical path.
What neither edition says is that an unchallenged programme becomes a contract document. It does not. And yet the consequences of that 21-day silence are far larger than most Engineers appreciate at the time they let it pass.
The four arguments that come out of it
In my experience almost every programme dispute is a version of one of three arguments.
Does the programme fix the Employer’s dates? The programme shows that certain drawings, approvals, access or free-issue materials are needed by particular dates. The Employer does not object within the period. Two years later the Contractor says the Employer was late by reference to those dates; the Employer says it never agreed to them and its obligation is to provide things in reasonable time. Both positions are arguable, and the answer usually turns on how the programme was received rather than on the clause. An Engineer who says nothing has not agreed to anything, but has made the Contractor’s argument considerably easier to run.
Who owns the float? The clause is silent, deliberately, and the 2017 edition’s critical path requirement makes the question sharper rather than answering it. If the Contractor built in six weeks of float and the Employer consumes it, has the Employer caused delay? The mainstream view in the delay analysis literature is that float belongs to the project, not to either party, but that is a professional convention rather than a contractual rule, and a well-drafted particular condition can settle it in either direction.
Can the Contractor re-baseline unilaterally? Contractors sometimes resequence to absorb an Employer delay, submit a revised programme still showing the contractual completion date, and then claim the delay much later. Employers cry foul, arguing the revised programme demonstrated the delay had no effect. The revised programme obligation exists precisely so that the document keeps tracking reality, and it should not be read as a waiver — but a Contractor that resequences without a contemporaneous notice explaining why has handed the Employer a decent argument.
What the Engineer should actually do in those 21 days
Here is where I think practice goes wrong most often, and it is a matter of habit rather than knowledge.
Engineers tend to do one of two things with a submitted programme. They stamp it “approved”, which the contract does not ask for and which creates an argument that the Employer has adopted every date in it. Or they say nothing at all, on the reasoning that saying nothing commits them to nothing.
Neither is right. The contract asks for a specific act: a notice identifying the extent of non-compliance. That is a narrow, technical response, and it is the one to give. If the programme does not show the critical path, say so. If the logic is missing, say so. If it assumes access to a section the Employer has not undertaken to provide by that date, say so — and say it in the notice, because that is the moment when saying it costs nothing.
Three further habits are worth building. Ask for the native scheduling file, not a printed document or bar chart, because a programme you cannot interrogate is a programme you cannot meaningfully review. Keep every submitted revision, dated, in a register; delay analysis two years later is often crippled by the fact that nobody kept the intermediate versions. And avoid the word “approved” entirely. “No notice of non-compliance is given” is a longer phrase and a much safer one.
What the Contractor should do
The mirror image, briefly.
Submit on time. The obligation is not onerous and a late initial programme weakens every subsequent position, including the ones that have nothing to do with planning.
Make the assumptions explicit. If the programme depends on access to a particular area by a particular date, on approvals within a stated period, or on Employer-supplied items, put those on the face of the document as stated assumptions rather than burying them in logic links. A programme whose dependencies are visible is a programme that generates a response; a programme whose dependencies are hidden generates silence, and silence is worth much less than people think.
Update genuinely rather than cosmetically. A revised programme that keeps showing the original completion date long after everyone knows it is unachievable does not preserve the Contractor’s position. It destroys the credibility of the entire schedule record, which is the thing the Contractor will need most when it eventually comes to demonstrate cause and effect.
And when resequencing around an Employer-caused event, say so in writing at the time. This costs one paragraph and preserves an argument that is otherwise very hard to recover.
Where the programme meets the delay claim
There is one further consequence of all this that deserves its own mention, because it is where the programme record does most of its work.
Every retrospective delay analysis has to start from a baseline and work through a sequence of updates. If the project has a clean, dated series of programme revisions that were actually submitted and actually reflect what was happening, the analysis is a technical exercise and the parties will argue about method rather than about facts. If the record is patchy — a baseline, then nothing for eighteen months, then a recovery programme produced during a dispute — the analyst is reconstructing, and reconstruction is contestable at every step.
This is why I am fairly relaxed about which delay methodology parties use and fairly unrelaxed about the underlying record. A competent analyst can work with most methods. Nobody can work well with a programme history that does not exist.
The corollary matters for Employers in particular. Rejecting or ignoring programme submissions may feel like a way of avoiding commitment, but it also means the project stops generating the contemporaneous record the Employer will need if it ever has to resist a claim. Both parties benefit from a disciplined programme cycle, which is unusual enough in this contract to be worth noticing.
The point about status
So, is the programme binding?
The honest answer is that it is not a contract document, but it is the single most important piece of evidence about how the project was meant to work and what actually happened to it. Tribunals and dispute boards read programmes closely. They read the revisions, the gaps between revisions, and the correspondence around them. A party whose programme record is coherent, contemporaneous and honest tends to be believed on other things too.
That is a lower-grade status than “binding” and a much more practically significant one. The programme does not decide the case. It decides who the decision-maker finds credible, which quite often amounts to the same thing.
Related reading: Decoding Concurrent Delay: The SCL Protocol and Employer Responsibility, The Critical Edge: Why Early Warning Notices Matter in FIDIC 2017, and The FIDIC 2017 Claims Mechanism.