Baseline schedule · Kairos One

Scope note

The contract and schedule specification control required submittals, review periods, acceptance language, and the effect of approval. This guide is a technical review framework.

Key takeaways

A baseline is a logic-driven, contract-aligned plan of record—not merely a bar chart or a saved copy of the first schedule submitted.
Approval should follow a documented review of scope, sequence, calendars, durations, constraints, resources or costs where required, and schedule mechanics.
Preserve the native file, exports, narrative, review comments, responses, and accepted revision together so future variance and delay analysis retain lineage.

What the baseline establishes

The baseline records how the contractor proposes to deliver the contractual scope within the required dates. It connects scope, sequence, durations, calendars, milestones, procurement, design, approvals, construction, testing, and turnover in one time model. Once accepted under the contract’s process, it becomes the comparison point for progress and variance—not because every assumption will remain true, but because the parties need a controlled statement of the original plan.

A baseline is therefore both a management tool and evidence. Management uses it to coordinate work and measure performance. Later analysis uses it to understand what changed, when it changed, and whether the change affected a controlling path. That dual purpose is why baseline review should be careful, documented, and completed before extensive progress makes the original plan impossible to verify.

Begin with the contract and schedule specification

Before checking the network, build a requirements matrix from the contract. Capture required milestones, phasing, access constraints, owner activities, submittal and review durations, procurement detail, calendars, weather treatment, activity-duration limits, coding, cost or resource loading, narrative requirements, file formats, and review timelines. A technically elegant schedule can still be noncompliant if it omits the obligations it was required to model.

Distinguish contractual requirements from reviewer preferences. If the specification requires a fourteen-day owner review, a five-day activity is a compliance issue. If the reviewer merely prefers a different WBS color or activity naming convention, treat it as a recommendation unless it affects clarity or a stated requirement. A disciplined matrix keeps the review fair and makes each comment traceable.

Test completeness before testing the date

Confirm that the schedule covers the full scope and lifecycle: mobilization, design, permitting, submittals, procurement, construction, inspections, commissioning, training, documentation, substantial completion, punch work, and final completion as applicable. Compare the WBS and activity list with the estimate, responsibility matrix, procurement log, submittal register, and contract deliverables. Missing scope is often more dangerous than a poor duration because CPM cannot forecast work that does not exist in the network.

Milestones need definitions and responsibility. “Owner approval,” “utility available,” or “area complete” is ambiguous unless the schedule and narrative identify what satisfies it, who controls it, and what it drives. Interface milestones should connect the responsible parties rather than sit as disconnected dates.

Review logic, durations, calendars, and constraints as a system

Mechanical checks are the opening screen: missing predecessors or successors, excessive lags, leads, relationship types, hard constraints, high durations, high or negative float, and invalid dates. Passing those checks does not prove the sequence is buildable. Trace representative paths through each major work area and ask field, design, procurement, and commissioning specialists whether the handoffs reflect the intended means and methods.

Durations need a stated basis. Production work should reconcile quantity, crew, productivity, shift, and calendar assumptions where material. Procurement should distinguish submittal, review, fabrication, shipment, delivery, and installation rather than hide months inside one bar. Calendars should match the work they govern. Constraints should be few, visible, and tied to a real external or contractual condition.

Interrogate the critical and near-critical paths

Trace the longest path to each contractual milestone and review several near-critical paths. Confirm the path is continuous, supported by driving relationships, and consistent with the narrative. A baseline that reaches completion through an unexplained constraint or a chain of long lags has not demonstrated how the work will finish.

Review path sensitivity as well as the single answer. If two parallel paths are separated by only a few days, both deserve management attention. Ask what assumptions would cause the path to shift: utility access, long-lead delivery, enclosure, permanent power, systems integration, authority inspection, or owner occupancy. This converts the baseline from a compliance document into an operating plan.

Use a controlled comment-and-response workflow

Each review comment should identify the activity or requirement, state the observed condition, explain why it matters, and request a specific response or correction. “Fix logic” is not actionable. “Activity ELEC-240 has no successor and therefore does not drive energization; connect it to the applicable turnover path or explain why it is terminal” is reviewable and auditable.

Track responses to closure. If the contractor disagrees, preserve the rationale and the owner’s determination. When a revision arrives, compare the native files rather than assuming only commented items changed. Record added and deleted activities, logic, calendars, constraints, durations, milestones, costs, and resources as applicable. Baseline approval should identify the exact revision and data state accepted.

Approval does not erase assumptions or transfer responsibility

The contract defines the legal effect and vocabulary of approval, acceptance, review, or no-objection. Technically, the owner should avoid language implying that review validates the contractor’s means, methods, productivity, or future performance beyond the contract’s stated effect. The record should show what was reviewed, what remained an assumption, and which responsibilities stayed with the contractor.

Re-baselining later may be appropriate after a major approved change, negotiated recovery plan, or other contract-defined event. It should not overwrite history. Preserve the original baseline, every accepted update, the reason for the new baseline, the approval authority, and a reconciliation of changed scope, dates, logic, and remaining work.

Preserve a defensible baseline package

The package should contain the exact native schedule file, a human-readable export, the schedule narrative, calendar and code definitions, required logs, the contract-requirements matrix, review comments, contractor responses, meeting records, approval correspondence, and a hash or version identifier where the document system supports one. A PDF alone cannot reproduce scheduling options or support later network analysis.

Store the package in the project’s controlled environment with clear revision lineage. Future updates, reports, and claims analysis should reference the same baseline identifier. If different teams silently use different copies, variance becomes a version-control dispute before anyone reaches the merits.

Worked example

Illustrative baseline review: the date is right for the wrong reason

A contractor submits a baseline meeting the contractual completion date. The longest path ends at a mandatory-finish constraint. A 120-day equipment procurement activity has no successor, and commissioning begins independently of permanent power.

The reviewer records three specific findings: the constraint prevents logic from demonstrating completion, procurement is open-ended, and commissioning logic conflicts with the stated turnover sequence.
The contractor replaces the finish constraint with the contractual milestone condition, connects procurement to installation, and links permanent power to functional testing.
The recalculated completion remains within the contract date, but the controlling path now runs through procurement, installation, energization, testing, and turnover.
The approved package identifies the corrected revision and preserves both the initial submission and comment-response log.

The review did not “make the date later.” It converted an unsupported date into a traceable plan and revealed the procurement path management must monitor.

Field-ready control

Baseline acceptance checklist

Complete a contract and schedule-specification requirements matrix.
Reconcile scheduled scope with contract deliverables, estimate, procurement, submittal, testing, and turnover requirements.
Run mechanical quality checks and trace representative paths through every major work area.
Validate calendars, durations, constraints, lags, and scheduling options.
Trace longest and near-critical paths to each contractual milestone.
Confirm cost and resource loading where contractually required.
Close every review comment through a documented response and determination.
Compare the final revision against the prior submission for unrequested changes.
Archive the native file, exports, narrative, comments, responses, and approval under one baseline identifier.

Common questions

Should a baseline contain progress?

Normally the original baseline represents the planned work at its defined status point and should not be contaminated by later progress. Contract requirements and late baseline submissions can complicate the treatment, so the data date and any actuals must be disclosed and handled explicitly.

Does owner approval make every duration and sequence reasonable?

No. The contract controls the effect of review or approval. The record should avoid implying that the owner assumed responsibility for the contractor’s means, methods, productivity, or performance unless the contract expressly says so.

When is re-baselining appropriate?

Typically only after a significant approved change, negotiated recovery, settlement, or another contract-defined event. It should be authorized, reconciled, and preserved alongside—not substituted for—the historical baseline and updates.

Sources and scope

Follow the reference trail.

This guide is original educational commentary. Kairos reference records identify the source organizations, editions and scope behind this guidance. The original publishers retain their publications and rights.