The schedule specifications commonly included in project contracts lay out requirements for both the contractor and the owner. On a project-by-project basis, these requirements vary from general practices to technical requirements. There isn’t a commonly accepted set of specifications, as they are frequently tailored for each individual project.
Issues with scheduling specifications can broadly fall within two buckets: 1) Parties ignore the requirements for a variety of reasons, or 2) the requirements don’t add value to the project. With that in mind, what types of specifications are common, and what are the considerations for each?
Project scheduler resume requirements
Scheduling specifications can require the project scheduler to have a certain amount of experience, both in years and with similar projects. While the idea behind this requirement is sound, the scheduling specification should set realistic minimums that don’t constrain available candidates. Consider these two scenarios:
- Unreasonable expectation: Contractor will provide a project scheduler with 10 years of experience as a lead project scheduler and scheduling experience on two similar projects worth $20 million or more.
- Reasonable expectation: Contractor will provide a project scheduler with either five years of experience as a lead project scheduler or previous scheduling experience on two projects in the same industry.
Don’t use a requirement that is unachievable for the contractor. If you do, they may either ignore the specification, which is a breakdown in the contractual relationship, or hire an outside scheduler for a key role with whom they don’t have a rapport. A cohesive project team with a qualified scheduler can be more effective than a team without a history and a very expensive scheduling consultant.
Scheduling specifications can require that the project schedule meets basic technical requirements related to the fidelity of the schedule. Compliance with these requirements is usually necessary for a high-quality schedule, but they are usually very achievable. Don’t let an easily resolvable technical error delay the review and approval of your baseline schedule.
These requirements are commonly associated with the following: activity relationships, activity length, activity naming conventions and contract milestone compliance.
Activity relationships: Activity relationships are split into two major categories. First is whether every activity has a logical predecessor and successor except for the start and finish milestones. This is crucial and should be considered standard for a complete schedule; exceptions to this should be documented and agreed to.
Second is what type of relationships and lags are allowed. Of these, common restrictions include no Start to Finish relationships and limits of when lags can be used and their duration. These should be treated on a case-by-case basis, but a project scheduler can often make a compelling argument for their individual usage of lags.
Activity length: Activity length is a broad limitation meant to force a certain level of detail in a schedule. Adding a single activity that covers multiple months can often be seen as a way for a schedule to be “complete” with placeholders that will be detailed later. This restriction isn’t unreasonable, but a detailed review of the schedule and specific requested changes of subjectively “long” activities is a more collaborative way to deal with necessary schedule detail.
Activity naming conventions: These are predetermined coding structures for categorizing activities, such as by type of work. They are generally reasonable, but they should also be decipherable to a lay person, since a requirement that makes the project schedule inaccessible to all stakeholders is counterproductive.
Contract milestone compliance: This is the requirement that the schedule meets the technical requirements showing completion dates in line with the contract milestones. Simply put, this means your critical path allows the project to be done on time and meets all contract milestones.
This metric is reasonable, and the owner and contractor should collaborate to make sure there is a mutual understanding of any work that may be planned after completion (such as closeout) or how it applies to interim milestones during the work or if the project includes multiple independent scopes of work.
Overall, technical requirements are often straightforward and achievable. Contractors and owners should work collaboratively to avoid these requirements holding up review and approval of the project schedule.
Baseline “agreement” requirements
Schedule specifications often require parties to approve a baseline project schedule before the start of the project or within a short period of time after notice to proceed on the project. The baseline schedule represents the agreed upon plan and is the document that progress or delays can be measured against. Example specification language should be specific regarding why a schedule can be approved or denied.
If the specifications require owner approval without guidelines for how they make that determination, it provides an opportunity for the owner to assert control over the contractor that the contract may not have envisioned. Likewise, an owner should reserve the right to reject the schedule if it is incomplete, inaccurate, doesn’t meet contract milestones, or impacts other projects and areas outside of the contract’s scope.
Schedule update frequency
Schedule specifications often lay out a minimum frequency between schedule updates and a subsequent process for review and acceptance. Specifications tend to range between every week and every month for minimum schedule update frequency. The update frequency should align with the complexity of the project and allow stakeholders to make timely decisions. Once they agree on the frequency, both parties should strive to meet the basic reporting requirements.
An example of a schedule that should be updated more frequently is outage work, where contractors are working accelerated schedules with a compressed period to complete their work. In an outage scenario, stakeholders need to make adjustments as quickly as possible if there is an issue and monthly reporting will not be frequent enough.
An example of a project that can use monthly updating is one where the work is less dynamic and unlikely to experience significant sequence changes. Mass excavation projects would work well for this; however, the project management team should still use daily, weekly plans and two- or three-week look-ahead schedules to manage the work and track progress between monthly schedule updates.
As part of the schedule update, scheduling specifications may dictate the type of schedule deliverable that the contractor produces as part of the update process.
At a minimum, a full PDF of the project schedule — which includes start date, finish date, duration and float information for each activity, as well as a printout of the critical path — should be provided. Parties should negotiate what other standard “reports” are valuable to the project. Certain scheduling software, primavera specifically, has automated tools to produce massive volumes of data.
Owners and contractors should make sure they are agreeing to a specification that will actually have a functional purpose as opposed to being a paper exercise. An example is a report that tracks each change in logic or duration. Depending on the size of the schedule, these reports could includes hundreds of items each month. If this is the level of oversight an owner wants to have, they must set aside the appropriate time and personnel to review these reports and follow up with questions to the project management team.
A frequent point of contention for certain stakeholders is an inability to review native project schedules even if provided by the contractor. Stakeholders should consider third-party or in-house options that would allow them to review electronic schedules in their native software. This level of review will allow a more detailed check on the changes being made by the contractor.
Allowances (weather, other)
Schedule specifications may mandate a certain number of allowance days in the schedule for potential impacts. These could be applied to any issue, but they are most commonly added to address weather impacts. Two common ways these are measured are 1) a weather allowance activity at the end of the schedule, which is reduced by one day for each day of inclement weather that shuts down the project, and 2) a requirement that the contract budget a certain number of weather days per month based on historical averages and defined in the specification.
The owner and contractor should proactively discuss how and where weathers days are accounted for in the schedule. This agreed upon weather “budget” can then be tracked contemporaneously in the project schedule, daily reports, OAC meeting minutes or other readily available project document.
Specifications can require processes for the demonstration of project delay. The main example is a time-impact analysis or fragnet. These are essentially schedule updates at a point in time with a delaying event(s) added to the schedule. The effect of the delay is then calculated and used as part of change order negotiations.
Contractors and owners should confirm that the requirement is a relatively straightforward process that both parties agree to, going so far as to create a template or example to confirm mutual understanding. An agreed process to calculate delay is essential for constructively dealing with project impacts.
Wipfli can help with your contract review and scheduling needs
A contract’s schedule specifications are just one part of your overall scheduling needs. Wipfli can assist you with everything from contract and specification review, to schedule validation, to project monitoring and more.
With our deep scheduling experience, we understand how projects go wrong and why, which means we know what problems to look for and how to proactively — and cost-effectively — solve them before they turn into a dispute. Click here to learn more about Wipfli’s project scheduling services.