Baseline Schedule

Definition

The Baseline Schedule is the formally approved, time-phased plan of project activities, durations, logic, milestones, and resource loading that serves as the reference against which actual performance is measured. Once baselined, the schedule is frozen for measurement purposes; changes flow only through the formal change control process. The baseline is the schedule's commitment to the project's stakeholders — and the reference point that makes variance reporting meaningful.

"Baseline" is both a noun (the approved schedule) and a verb (the act of formally freezing it). Both meanings matter. A schedule that has never been baselined produces no meaningful variance reporting; a baseline that is re-baselined every month produces no meaningful trend.

What Goes Into a Baseline

• Activities — discrete units of work with unique IDs, descriptions, and WBS codes.
• Durations — estimated time to complete each activity, with assumptions documented.
• Logic — finish-to-start and other dependencies between activities.
• Calendars — working days, shifts, holidays.
• Resource loading — labour, equipment, materials per activity.
• Milestones — zero-duration markers for significant events.
• Constraints — externally imposed dates (start-no-earlier-than, must-finish-on).
• Critical path — the chain of zero-total-float activities driving the end date.
• Cost loading — for projects using earned value, each activity carries budget value.

Principles

• Baseline only when ready. An immature schedule baselined to satisfy a deadline becomes the reference no one trusts.
• Freeze in writing. Baseline approval is a formal milestone with signatures, not an email exchange.
• Change only through change control. Once baselined, no edits without an approved change request.
• Compare current to baseline at every status. Variance reporting is the baseline's reason for existing.
• Re-baseline rarely. Frequent re-baselining hides performance; once a year on long programmes, never on short ones.

Schedule Quality Before Baseline

Baselining a defective schedule guarantees defective reporting. The standard pre-baseline audit (often using the DCMA-14 checklist) verifies:

• No open ends (every activity has at least one predecessor and successor, except start and finish).
• No leads (negative lags).
• Lags below 5% of total relationships.
• Hard constraints below 5% of total activities.
• No activities longer than 44 working days without breakdown.
• Total float distribution: 95% of activities have positive total float.
• Critical path drawn end-to-end without gaps.
• Resource loading complete on activities that consume resources.
• Calendar consistent across related activities.

A schedule failing more than three DCMA-14 criteria should not be baselined; the defects compound into variance reporting that the team cannot interpret.

Real-World Construction Example

A USD 480M LNG receiving terminal baselined its schedule at award. Three months later, FEED issues forced fundamental re-sequencing of jetty and tank-farm work. The contractor proposed a re-baseline; the owner refused on the grounds that early variance would be hidden. The compromise: maintain the original baseline as the contractual reference, and run a parallel "current working schedule" with updated logic for execution purposes. Both views were reported; variance against the contractual baseline accumulated to USD 14M of approved change orders over 18 months, all properly documented. A premature re-baseline would have buried the change-order trail and produced a schedule with no meaningful history. The discipline of preserving the original baseline despite execution reality is what kept claims and disputes clean.

Real-World IT / Agile Example

An enterprise programme baselined a 24-month release plan at three levels: programme tranches (12-month), release waves (3-month), and sprint goals (2-week). The programme baseline was updated only at tranche boundaries; the release-wave plan was refreshed quarterly with formal re-baseline; sprint goals refreshed each sprint. The three-tier baselining matched commitment volatility to baseline cadence — long-horizon plans changed slowly, short-horizon plans changed frequently. The model is now standard for enterprise agile programmes and avoids the false choice between "everything baselined forever" and "nothing ever baselined."

Project Controls Perspective

Controls teams own the baseline: pre-baseline audit, formal approval ceremony, baseline storage in version control, variance reporting against baseline, and re-baseline governance. Three metrics matter: baseline stability (number of approved changes per quarter), variance against baseline (cost, schedule, scope), and re-baseline frequency (how often the project felt the need to start over). A project that re-baselines more than once a year is usually concealing performance; a project that never re-baselines after material scope change is usually reporting against a baseline nobody believes.

Common Mistakes

• Baselining a defective schedule to satisfy a contractual milestone.
• Re-baselining frequently to "improve" variance reporting — burying performance.
• Edits to baseline activities without formal change control.
• No DCMA-14 audit before baseline; defects compound into bad reporting.
• Resource loading or cost loading omitted, leaving EVM impossible.
• Baseline stored in a single planner's file rather than under formal version control.
• Variance reported in dates only without value impact, or vice versa.

Expert Tips

• Run DCMA-14 before baseline. The pre-baseline audit catches defects that would otherwise survive into variance reporting.
• Baseline in a formal ceremony. Signatures, dates, version numbers — the baseline is a contract, treat it as one.
• Store baselines under version control. Every variant tagged, dated, owned.
• Compare to baseline at every status. The baseline exists to be measured against; ignoring it is worse than not having one.
• Re-baseline only for material scope change. The bar is high deliberately.

Key Takeaways

• The baseline is the approved reference for variance reporting; freeze formally, change only through change control.
• Pre-baseline DCMA-14 audit prevents defects compounding into bad reporting.
• Three-tier baselining (programme, release, sprint) matches baseline cadence to commitment volatility.
• Re-baseline rarely; frequent re-baselining hides performance.
• The baseline is a contract — treat it as one.

Related Concepts

Baseline Schedule interlocks with CPM, Network Diagrams, Earned Value, Change Control, and WBS. DCMA-14 checklists and baseline-approval templates are at PMMilestone.org.