Schedule Change Control and Baseline Management
This domain tests how the approved schedule baseline is protected, revised, and audited. CAPES expects you to distinguish a schedule update from a re-baseline, use time impact analysis for changes, and maintain traceability between approved changes and the current schedule. The exam also checks version control, approval authority, and contemporaneous records.
Baseline and change rules
- The baseline is the approved schedule against which performance is measured. It should be logic-linked, resource-loaded as required, and frozen for the reporting period.
- A schedule update reflects actual progress and forecast without changing approved scope or dates. A re-baseline changes the approved plan and requires formal authorization.
- Change control evaluates scope, time, cost, and risk impacts. The change control board approves, rejects, or defers.
- Time impact analysis (TIA) inserts a fragnet for the change into the current schedule and measures the effect on completion, accounting for float and concurrent delays.
- Version control preserves an audit trail: baseline, each update, each approved change, and the reason.
Worked example
Baseline completion is day 100. A client change adds 5 days of work on the critical path. The contractor proposes a 2-day mitigation by resequencing a non-critical activity, so the net impact is 3 days. TIA uses the current approved schedule, inserts the change fragnet, runs the calculation, and shows completion at day 103. The change board approves a revised completion of day 103 and a new baseline version. The original baseline is retained for historical comparison; it is not overwritten.
Traps that cost marks
Re-baselining to hide variance; approving a change without updating logic; using the original baseline for a changed scope without disclosure; and performing TIA on a schedule with open ends or missing logic. Also, a fragnet that ignores concurrent delays can overstate the change impact.