Before You Approve the Baseline: A Schedule Acceptance Review for Owners
The baseline schedule is the document every later argument refers back to, yet it is often approved with a quick glance at the completion date. The decision an owner actually faces is narrower and more useful: accept the baseline as the reference plan, accept it with recorded conditions, or return it for correction before the job gets far enough that the comparison stops meaning anything. Ryan Lippmann, an Orange County senior construction project manager who has worked in California construction since 2001 and is the principal of Pacific Project Controls, works in the discipline this review belongs to: the schedules, budgets, and reporting that keep a build's position visible. The sequence below is a general review format for owners, owner's representatives, and project managers. The examples are illustrative and do not describe any client project.
Decide what approval is going to mean
Before reading the file, the review team should agree on what acceptance signifies under the contract. In some agreements, approving the baseline means agreeing the plan is reasonable. In others it means little more than acknowledging receipt. Those are very different commitments, and reviewers who have not read the relevant contract clause may approve something broader than they intend.
Write down three things at the start: the contract milestones the schedule must satisfy, the submission requirements the schedule is supposed to meet, and the people whose sign-off is required. If the contract calls for a particular level of detail, activity coding, or narrative, that requirement is part of the acceptance test, not a preference.
The outcome of the review should be recorded in one of three forms — accepted, accepted with listed conditions, or returned with reasons — along with the file version and the date. A vague approval leaves everyone reconstructing intent later.
Check that the plan matches the scope and the contract dates
Start with coverage rather than mechanics. Does the schedule contain the full contracted scope, including the work the contractor expects others to perform? Are owner-furnished items, separate contracts, and utility or agency work represented, even if only as milestones?
Then compare the schedule's completion and interim milestone dates with the contract. A schedule that finishes earlier than required is not automatically a gift; it may mean the contractor intends to claim the difference as its own float, or it may mean the plan relies on approvals arriving faster than they normally do. A schedule that finishes later than the contract date is a problem to resolve before acceptance, not after.
Finally, check that the sequence reflects how the project is actually permitted, procured, and occupied. On California work subject to agency plan review, inspection, and approved-change processes, those steps belong in the logic as activities with duration, not as assumptions held in someone's head. The same is true of occupied-facility constraints such as shutdown windows and infection-control requirements, which govern when certain work can proceed at all.
Ask the contractor to walk the critical path aloud
The most informative part of a baseline review is usually a conversation, not a file inspection. Ask the project team to narrate the driving path from the current date to completion, in plain language, without reading activity IDs.
A team that can describe the path — what gets procured, what gets approved, what gets built, and why each step waits for the one before it — has a plan. A team that can only point at a highlighted bar has a file. The U.S. Government Accountability Office's Schedule Assessment Guide treats the integrity of the critical path as a core practice for exactly this reason.
Useful follow-up questions: which approvals are on that path, which long-lead materials are on it, and what the team would do first if one of those items slipped a month. The answers tell the owner where the project's real exposure sits.
Test the assumptions behind durations and calendars
Durations encode assumptions about crew size, access, and productivity. Ask what crew the contractor assumed for the largest activities and whether those crews are available in the local market during that window. A duration that only works with a crew nobody has committed is a forecast built on a hope.
Check the work calendars as well. Holidays, weather allowances, agency working hours, and planned shift patterns all change what a date means. If a weather allowance is included, confirm where it sits and how it will be consumed, so that later weather claims can be measured against something.
Procurement durations deserve particular attention. Submittal preparation, review, fabrication, and delivery are separate steps with different owners. Collapsing them into one activity makes it impossible to tell, three months later, whether the delay came from the subcontractor, the design team, or the supplier.
Look for what the schedule hides
Hard-coded dates, missing links, and unexplained waiting periods are the common ways a schedule stops responding to reality. Rather than chasing counts, ask the scheduler to list every imposed date and explain why each one exists. A contractual milestone can justify one; convenience cannot.
Then ask the scheduler to demonstrate that the network responds. If a representative activity on the driving path is delayed in a working copy, does the completion date move in a way the team can explain? Run that demonstration on a copy, record what happened, and discard the copy. A test file should never become the issued schedule.
Also look for activities with no apparent successor. Work that drives nothing is either genuinely free of constraint, which is worth confirming, or it is disconnected from the plan it is supposed to represent.
Record conditions instead of informal promises
Most baselines are neither perfect nor unusable. The practical outcome is conditional acceptance, which is only meaningful if the conditions are written down with owners and dates attached.
Use a short record for each condition: the issue, the evidence or document it refers to, the work or milestone it affects, the person responsible for resolving it, and the date the resolution is required. The structure is the same one that makes a weekly project controls review usable, and carrying the conditions into that routine is how they get closed rather than forgotten.
Retain the approved baseline version and the acceptance record together. Later progress updates should preserve that reference point; if a new baseline is approved through the project's change process, the earlier version and its approval record should be kept as well.
The decision at the end of the review
By the end of the review, the team should be able to state its position in a sentence. Either the schedule represents the contracted scope with logic the team can explain and assumptions the owner finds credible, or it does not yet, and the specific gaps are listed.
Returning a baseline costs a few days. Accepting a plan nobody can explain costs considerably more later, when a disputed delay has to be measured against a document that was never really agreed. Bad news early is cheaper than bad news late — a baseline review is one of the earliest opportunities a project has to apply that principle.
Once the baseline is accepted, the discipline shifts to the update cycle: confirming the status date, checking reported progress against field evidence, and explaining movement against both the previous update and the approved baseline.