Change Control and Configuration Management
Change control
Once baselines are approved (scope, schedule, cost), any alteration must go through formal change control: raise and log a change request → analyse impact on scope, schedule, cost, quality, risk and benefits - including the cost of not changing - → decide at the correct authority level → implement → update baselines and plans → communicate → close the request. Decisions are made against delegated authority: a change within the project manager's tolerances can be approved by the PM; a change breaching tolerance, or affecting the business case, escalates to the sponsor or change board.
Scope creep is the uncontrolled accumulation of small, unapproved changes; formal control converts it into managed change, but a high volume of change requests is itself a signal that requirements or governance are weak.
Configuration management
Configuration management identifies and controls the components of the product (configuration items) and their versions. Its activities are: planning, identification (what items exist, naming and numbering), control (only approved changes are made; baselines are frozen and versioned), status accounting (records of what version exists and where), and verification/audit (confirming that what is built and documented matches the approved configuration). A baseline is a fixed reference point that can only be changed through change control.
Traps
Approving change without impact analysis; letting the PM approve changes beyond their tolerance; confusing change control with configuration management (the latter controls the product and its versions, not just the plan).
Rule of thumb
Every change must answer three questions before approval: what does it affect, who is authorised to decide it, and what baseline must be updated afterwards?