Kamal Dubey works at the intersection of commercial judgment, contract strategy, and leadership decision-making across complex construction and infrastructure projects. With a civil engineering foundation and over two decades of experience, he helps clients navigate uncertainty, protect long-term value, and make confident decisions throughout the project lifecycle.
The Contractor submits its programme.
The Engineer reviews it.
Comments are issued. The Contractor responds. Sometimes another revision comes back.
And somewhere along the way, we start using expressions like:
“The programme is approved.”
Or:
“The Engineer has not approved the programme yet.”
This is quite normal language on projects. I have used it myself.
But when we go back to Sub-Clause 8.3 of FIDIC 1999, there is an interesting question:
Is the Engineer actually required to approve the Contractor’s programme?
Sub-Clause 8.3 requires the Contractor to submit a detailed time programme to the Engineer.
It then gives the Engineer 21 days after receiving the programme to give notice to the Contractor stating the extent to which it does not comply with the Contract.
That wording is worth noticing.
It does not say:
“The Engineer shall approve the programme within 21 days.”
The mechanism is essentially about compliance with the Contract.
If there is something in the programme that does not comply with the Contract, the Engineer should identify it and notify the Contractor.
That is quite different from approving the programme.
This is where the practical difficulty starts.
Imagine the Contractor submits a programme showing a level of productivity which the Engineer considers very optimistic.
The Engineer may look at it and say:
“I don’t think they can achieve this.”
That may be a perfectly reasonable observation.
But the next question should be:
What exactly does not comply with the Contract?
Those are two different issues.
A programme can be optimistic and still comply with the contractual requirements.
The Engineer’s concern about whether the Contractor can actually achieve its planned productivity does not automatically turn the programme into a non-compliant programme.
And this is where I think we need to be careful with the word “approval.”
If the Engineer does not notify a contractual non-compliance within the 21 days, that should not be understood as the Engineer guaranteeing that the Contractor’s programme is achievable.
This makes the discussion even more interesting.
Suppose the contractual Time for Completion is December 2027.
The Contractor submits a programme showing completion in September 2027.
Can the Engineer say:
“I don’t approve this because your completion date is too optimistic”?
The Contractor may genuinely intend to complete three months early.
If that programme otherwise complies with the Contract, simply planning to finish early does not necessarily make it non-compliant.
But there is another side to this.
If the Contractor chooses to programme early completion, does that automatically mean the Employer, Engineer and Employer’s Personnel are now contractually required to work to the Contractor’s earlier dates?
Not necessarily.
The Contractor’s programme shows how the Contractor intends to execute the Works. It does not, simply by being submitted without objection, rewrite the contractual obligations of everyone else.
This is equally important.
Sometimes the discussion goes too far in the opposite direction:
“If the Engineer doesn’t approve the programme, then it is only the Contractor’s document.”
That is also too simplistic.
Sub-Clause 8.3 recognises that the Employer’s Personnel may rely upon the programme when planning their activities.
Think about this practically.
The Contractor says that a particular area will be ready in June.
The Engineer may plan inspections around it. The Employer may have interfaces to coordinate. Other activities may depend upon the sequence being communicated by the Contractor.
So the programme matters.
People may plan around it.
But relying upon a programme is not the same thing as approving every assumption contained in it.
That distinction becomes very important when disputes arise later.
Six months later, the programme may bear little resemblance to what is actually happening on site.
Activities have moved. Progress is different. The Contractor’s intended sequence may have changed.
At that point, continuing to refer to the old programme doesn’t help anybody.
Sub-Clause 8.3 addresses this as well. Where the programme becomes inconsistent with actual progress or with the Contractor’s stated intentions, a revised programme becomes relevant.
This is why I prefer to be careful with expressions such as “approved baseline programme.”
FIDIC 1999 gives us its own contractual mechanism. We should first understand that mechanism before importing terminology that may be commonly used in project controls but does not necessarily describe the contractual position.
When a programme lands on the Engineer’s desk, I think the review should start with a fairly simple question:
Does anything in this programme not comply with the Contract?
If yes, identify it and notify the Contractor within the contractual period.
The Engineer may also see durations that look aggressive, productivity that appears optimistic or sequencing that raises practical concerns. There is nothing wrong with raising those concerns.
But we should be careful about mixing those concerns with contractual compliance.
And equally, if the Engineer does not issue a notice within 21 days, we should be careful about later saying:
“The Engineer approved the programme, therefore the Engineer accepted all the Contractor’s assumptions.”
That is not what Sub-Clause 8.3 says.
For me, this is one of those small contractual distinctions that can become very important later.
On many projects, the conversation starts simply:
“Has the Engineer approved the programme?”
Perhaps under FIDIC 1999, the better question is:
“Has the Engineer identified anything in the programme that does not comply with the Contract?”
The difference between those two questions may look small.
In contract administration, it isn’t.
