Baselines, Change Control, and Staying Honest on Dates

Schedules slip. The difference between a “late project” and a “managed change” is disciplined baselining and transparent control.

Baseline early

• Baseline scope, schedule, and cost once the charter is approved and risks are known—not after execution starts.
• Capture version v1.0 with date, assumptions, and known risks.
• Store baselines in a controlled repository; reference them in status reports.

Define your change thresholds

• What moves trigger formal change? (e.g., >10% schedule slip, budget variance, scope expansion beyond MoSCoW Musts).
• Who approves what? Map thresholds to roles (PM, sponsor, steering).
• How fast? Set SLA for decision turnaround to avoid “death by pending.”

Run a lean change process

• Change request: driver, impact to scope/schedule/cost, options, and your recommendation.
• Assess schedule impact with a before/after snapshot; keep the Gantt simple.
• Record decisions in a log with effective date and follow-up actions.

Keep dates honest

• Show original baseline, current forecast, and variance in every status report.
• Update risk and RAID items when changes are approved; retire superseded risks.
• Avoid stealth slips: if you’re re-sequencing work, note the change explicitly.

Recover with intent

• Use fast-track/parallelization only when risk is understood and owned.
• Protect critical path tasks; don’t borrow time from integration and testing.
• If quality or scope will suffer, document the trade-off and get sponsor buy-in.

Baselines are commitments, not guesses. Treat them that way, and change control becomes a tool for credibility instead of bureaucracy.