Skip to content
Advanced · 2 min read

Schedule change-control playbook

Separate progress from revisions, authorize consequential edits, preserve before-and-after files, and keep the baseline yardstick intact.

Working definition

Schedules change for legitimate reasons: approved scope, means and methods, actual field sequence, calendars, access, risk response, correction of defects, and contractual time decisions. The control problem is not preventing change; it is making every consequential change visible, authorized, technically reviewed, and traceable to its reason and effect.

Key takeaways

  • Classify progress, forecast, model, and baseline changes separately.
  • Require owner, reason, authority, effective period, and schedule effect.
  • Preserve native before-and-after files under consistent calculation settings.
01

Classify changes by what they alter

Track added or deleted activities, logic, lag, duration, calendar, constraint, code, resource, cost, progress, and scheduling-option changes separately. A change can affect dates even when no activity was added.

02

Do not erase the comparison point

The current schedule should evolve while the accepted baseline remains protected unless a separately authorized baseline action occurs. Preserve before and after native files and compare under consistent calculation settings.

Control a consequential schedule change

Use the process for changes that can affect dates, float, paths, reporting, or entitlement.

Before you start

    1. Register the proposed change

      Record requester, date, reason, authority, affected activities and fields, supporting record, and intended effective period.

      Verify: The request is unique and reviewable before implementation.

    2. Create an analytical copy

      Apply the proposed edit to a copy of the current accepted schedule.

      Verify: The source file remains untouched and identifiable.

    3. Calculate consistently

      Run before and after schedules using the same data date and options unless the option change itself is being tested.

      Verify: Date, float, path, and milestone differences are attributable to the proposal.

    4. Review and authorize

      Assess technical need, contract status, risk, downstream handoffs, reports, and baseline implications.

      Verify: Named authority approves, rejects, or conditions the change.

    5. Implement and retain

      Apply the authorized change to the next controlled schedule, update narrative and registers, and retain all files and decisions.

      Verify: The published update and change register reconcile.

      Field-ready control

      Schedule change record

      • Unique change ID
      • Requester and reason
      • Authority or contract reference
      • Affected activities and fields
      • Before-and-after native files
      • Consistent calculation settings
      • Milestone and path impact
      • Approval decision
      • Narrative and register updated

      Common questions

      Is correcting a schedule-quality defect still a change?

      Yes. The correction may be necessary, but its effect and authorization should remain visible, especially if it changes dates, float, path, or historical interpretation.

      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.

      Schedule Assessment Guide: Best Practices for Project SchedulesU.S. Government Accountability Office · checked 2026-08-01UFGS 01 32 01.00 10: Project ScheduleWhole Building Design Guide / U.S. Department of Defense · checked 2026-08-01Delay and Disruption Protocol, second editionSociety of Construction Law · checked 2026-08-01