But what can be found in those requirements and what do you have to pay attention to? It does not matter if you’re part of the owner’s or contractor’s project team, it is indispensable to involve a professional with profound knowledge on the subject, because you quickly end up in highly technical discussions between the parties involved.

Structure and strategy

First things first: all requirements must be included in the tender or contract documents at the most appropriate place and only once. This implies that not everything related to time should be included in the schedule requirements. For example, clauses related to liquidated damages might be included in a separate contract paragraph or document, software specifications can be contained in a section regarding IT requirements and yet another section might include obligations related to acceleration plans in case of delay.

As for strategy, the type of contract will determine the focus of the requirements. A “cost plus” contract might require more stringent rules to follow to accommodate transparency towards the owner, while one may argue that in a ‘lump sum’ contract, many of the risks related to execution remain with the contractor. Thus, a less strict follow up of the project by the owner is required. Further to this, all requirements comprised in any document, should align with the project or company strategy and the schedule requirements are no exception.

Content of the requirements

General (schedule) requirements

In the general schedule requirements, one may find obligations on using the critical path method, calendars, working periods and shifts or information on the required level of detail. In addition, provisions for dealing with interfaces or close communication through daily, weekly, monthly, … progress and interface meetings can be addressed here. Look-ahead schedules – including past performance – can be required to facilitate this process.

An important and often overlooked aspect is related to the question: “What is contractual about the schedule?”. If the schedule is listed in as part of the contract documents and no other contract specifications deal with what exactly is contractual (exact sequence, duration of all activities, or only certain milestones?), one can assume that indeed everything about the schedule is contractual. In practice, this leaves room for many conflicts and difficult discussions. The schedule requirements can be used to this avail.

Another requirement might be the use of certain software. While, many different software packages are available on the market, the owner might decide to enforce the use of a certain package to ensure integration with its own systems. An important evolution regarding software is shortly touched under paragraph “Submissions” below.

Technical (Schedule) Requirements

Under this section, more technical aspects of the scheduling process can be included. For a large part, this will be related to best practices of developing schedules. When in the tender phase of a project, you might also find minimum requirements based on which tenderers can be excluded from further participation to the bidding process because of non-compliance with set thresholds. For example, quality aspects can be judged using some of the DCMA criteria. These technical aspects can include the restricted use of constraints, certain relationship types, lags and leads or the non-allowance of negative float. Additionally, structuring elements such as the use of activity ID’s, codes, resources, calendars, user defined fields, etc. should be found there.

Content of the Schedule

A list of items that should be included in the schedule can be part of the requirements as well. Those can be 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 might be very important to have a large degree of transparency related to contingency or risk buffers: in most cases, they should not be hidden in activity durations, but shown explicitly.

Support of the schedule

The structured sharing of all information required to enable the other party to understand and analyse the schedule should be captured by the schedule requirements as well. For a contract schedule or a new baseline, the so-called Basis of Schedule should include all relevant information. When progressing a schedule, the schedule report should include a narrative in which one can refer to the Basis of Schedule, supplemented with information on progress, delays, mitigation measures, deviations, changes in the critical path, issues, events, etc.

The relevant information of which talked about above, should include as a minimum:

• All assumptions and exclusions that lay at the base of the schedule.
• Elements used to structure the schedule (Phases, Locations, WBS, Activity Codes (e.g. in Primavera P6), etc.)
• Risk- and contingency buffers and their evolution.
• Total Float and its evolution.
• The strategy and methodology to achieve the contract milestones – although this might be already covered in a method statement which can be part of the project execution plan.
• All relevant data, calculations and assumptions used in deriving the activities’ durations.
• Calendars used for different activities and the reasoning behind it.
• Method of weather downtime modelling.
• Identification and analysis of the critical and / or longest path(s) and near critical paths.
• Coordination and interface activities.
• A report discussing schedule quality.

Progress

The contractor can be left free to choose its own method for progress measurement and reporting. But often the owner imposes more or less detailed instructions on this subject. Earned value management and accompanying S-curves are popular choices, but not always required. Also the steps to be taken in case of delay should be described. Of course, a delay can only be observed if actual progress is compared to the progress measurement baseline (PMB). Hence, baseline management (ref. paragraph below) should be addressed as well to ensure that there is always a formal baseline available to measure progress against.

Change and Baseline Management

Changes do happen on several levels. It is wise to include in the schedule specifications a section on how to deal with changes and how to manage them. A separate process should be described for dealing with baseline changes as opposed to changes on the various other project levels (e.g. scope change).

Submissions

The particulars on how and when to submit schedule-related documentation can be included under a section related to document control. However, it is best to be included under the schedule requirements, or at least the submission frequency per file-type.

Note

We are observing the tendency for projects to move towards more shared data environments, and it is no secret that we are pioneers regarding these recent developments in the market for the maintenance of schedules. In practice, a project owner can opt for setting up of an environment ‘in the cloud’ in which all contractors should maintain their project schedule. The many advantages for a setup like this are described in our blogpost 6 Reasons to bring Primavera P6 to the cloud. This has of course implications for the requirements on submissions of e.g. native files created by scheduling software. As the contractor’s schedule is accessible ‘live’, a different approach is required to deal with e.g. contractual consequences. The good news is that you can always refer to experienced professionals like Proove for assistance in dealing with such project requirements.

Conclusion

The schedule is a key instrument for effective project management. Due to its importance, very precise requirements should be included in tender and contract documents. There are plenty of different aspects one should keep in mind and the basics were addressed in the paragraphs above. We have to stress again the importance of involving experienced professionals on this matter seen the technicality of these topics and the implications they may have in claim cases.