The role of the project control professional is, in many ways, affected by tendering or contract requirements related to scheduling. From now on, I will refer to the ‘ scheduling requirements ‘ for simplicity.
If you are on the project owner’s side, your expertise may be needed to develop these requirements for future contractors to comply with these requirements.
If you are on the contractor’s side, you will be responsible for ensuring that the tender complies with the requirements of the tender. At a later stage, during the execution of the contract, you will have to ensure that all actions and documentation submitted to comply with the requirements.
Structure and Strategic Approach
First of all, all the requirements must be included in the tender or contract documents at the most appropriate place and only once. This means that not everything relating to time should be included in the requirements of the schedule. For example, clauses relating to liquidated damages may be included in a separate contract paragraph or document, software specifications may be included in the IT requirements section, and yet another section may include obligations relating to acceleration plans in the event of a delay.
As for the strategy, the focus of the requirements will be determined by the type of contract. A cost-plus contract may require stricter rules to be followed to accommodate transparency towards the owner, while it may be argued that many of the risks associated with the execution of the contract remain with the contractor in the’ lump sum’ contract. Therefore, the manager needs less strict monitoring of the plan.
In fact, the specifications included in any report should be compatible with the plan or company strategy and the criteria of the schedule are no exception.
The details of the Schedule Requirement
The requirements of the general schedule may include obligations to use the critical path process, schedules, working hours and changes, and details on the level of detail needed. In addition, guidelines for dealing with interfaces or near contact by regular, weekly and quarterly, progress and application meetings may be discussed here. Look-ahead schedules – including past performance – may be required to facilitate this process.
A significant and often ignored factor relates to the question: “What is the contractual meaning of the schedule?”. If the schedule is set out as part of the contract documents and no other contract specifications deal with exactly what is contractual (exact sequence, duration of all activities, or just a few milestones?), it can be assumed that everything on the schedule is actually contractual. For reality, it leaves room for a lot of conflict and complicated conversations. The requirements of the schedule may be used for this purpose.
The use of certain technology may be another necessity. While many different software packages are available on the market, the owner may choose to require the use of a package to ensure compatibility with their own systems. The significant evolution of the code will soon be touched on in section “Submissions” below.
Further technical aspects of the scheduling process can be included in this paragraph. This will, to a large extent, be related to best practices in the design of schedules. In the tender phase of the project, you may also find minimum requirements on the basis of which tenderers may be excluded from further participation in the bidding process due to non-compliance with the set thresholds. For example, some of the DCMA criteria can be used to assess quality aspects. Such technical aspects may include the limited use of controls, other forms of partnership, lags and lead, or the non-allowance of negative float. In addition, structuring elements such as the use of activity IDs codes, resources, user-defined fields, etc. should be found there.
A list of items that should be included in the schedule may also be part of the requirements. These may include contract milestones (sometimes called key dates), interface milestones and other milestones, owner and third party activities, long lead items, approval flows for important project documents, QHSSE related actions, and documentation and contingency buffers. Depending on the contract strategy of the project owner, it may be very important to have a high degree of transparency with regard to contingency or risk buffers: in most cases, they should not be hidden for the duration of activities but should be explicitly stated.
Structured sharing of all information required to enable the other party to understand and analyze the schedule should also be covered by the requirements of the schedule.
- Elements used to organize the schedule (phases, locations WBS, codes of activities, etc.
- Buffers of risk and uncertainty and their evolution.
- Total float
- Critical Path in the schedule
- The methodology of works.
- Calendars used.
- All the assumptions and exclusions on which the schedule is based.
A schedule is a key tool for the effective management of projects. Because of its importance, it is necessary to include very precise requirements in the tender and contract documents. There are many different aspects to keep in mind and the basics in the paragraphs above have been addressed. Once again, we have to emphasize the importance of including experienced professionals in this matter, given the technicality of these issues and the consequences they may have in claim cases.
Extension of Time Claim