What is a time programme?
The time programme is a document prepared by the contractor, post contract, detailing how he intendeds to carry out his obligations under the contract, in order to plan, monitor and control the works. Common software like Primavera and Microsoft Project uses the critical path method to create construction time programmes.
Programmes are intended to be flexible documents. This is evident in the FIDIC Red Book 99, which makes for revisions of the programme if actual progress has fall (or will fall) behind the current programme (Sub-Clause 8.6).
From this, and in addition to the fact that the programme is produced by the contractor AFTER the contract is signed, and is not subject to acceptance by the employer, it is clear that the programme is not intended to be part of the contract, i.e. it should not be followed in the same way as a "contractual obligation".
I am of opinion that this is the correct approach, as programmes contains lots of details pertaining to things like activity start and end dates, and logic, which is normally a contractor's risk, and will almost certainly will need to be revised from time to time as works progress.
On the other hand, contractual obligations such as drawings, specifications and conditions of contract should be fulfilled strictly to the letter.
However, it is becoming increasingly common for employers to include the programme as a contract document, mostly without understanding the consequences of doing so.
Consequences of having time programmes as a contract document
Several important implications of making the programme a contract document includes:
It is in the employer's interest to have a periodically updated programme. The programme serves two main roles, sequencing, planning and monitoring the works, and to assess claims for extension of time (along with other disputes). Without having a contemporary fairly accurate programme, claims would be supported (if at all) by a theoretical programme, without any input related to the contractor's own progress, allowing employers and engineers to withhold providing any extension of time which in turn increases the probability of sizeable disputes.
Making the programme a contract document means that the programme has become a contractual obligation, which follows that the parties should strictly follow it to the letter. Any departure from it (which is a commonplace in construction projects) constitutes a breach of the contract. Actions such as failure by contractor to start or finish activities on the date specified on the programme (even if it is non-critical) or if the employer does not allow the contractor to start any activity on the date mentioned in the programme may have unnecessary substantial implications. Similarly, any amendment to the normally-flexible programme would be an amendment to the contract. This adds a lot of risk and constraints on the employer, who in such cases choose to share the planning risk which is normally the contractor's in a bid for more control over methods and programme.
Another potential issue that may occur is that if the contractor sends to the employer revised programmes with a completion date which is different from the contractual completion date, and the employer simply ignore it, may be construed as acceptance by conduct by the employer and accordingly showing that the employer has implicitly agreed by his conduct to grant the contractor an extension of time.
Programmes are produced by the contractors in high detail after the contract is signed. It is illogical to include a contractual obligation upon the contractor which he could not reasonably have taken into account while agreeing the contract price.
A common argument in favour of including the programme as a contract document is that the employer needs to ensure that a specific phasing or intermediate milestones are contractual obligations on the contractor. FIDIC contracts make for concepts like sections, partial taking over and times for access to site, which may be, with skillful drafting, used to place the required obligations in the contract, all while avoiding the risks of having an entire programme as a contractual obligation.
As a professor of mine once told me, "common sense is not so common", employers and engineers usually shoot themselves in the feet by adding such a dynamic, usually inaccurate and highly sophisticated document as a contract document, for trivial reasons which may be overcome by other means inside the contract conditions or the specifications.