22.1 The Change Control Process and Its Stages

Why change control matters on the APM PMQ

Change control is learning objective 24 in Area D (Planning and managing deployment). It is the discipline that keeps baselines honest after the project has committed to scope, schedule, cost, quality, and product definitions. Change is normal — markets shift, regulators revise rules, users learn, risks materialise — but uncontrolled change is how projects lose time, money, quality, and credibility.

Change control is not "saying no to stakeholders." It is saying decide with eyes open: capture the proposal, understand impact, choose approve / reject / defer (or modify), re-baseline what was authorised, implement under configuration control, and communicate so the team and suppliers work from the same truth.

Exam frame: Once something is baselined, side agreements and quiet extra work are scope creep. The correct path is the agreed change control process, sized to the authority and life cycle in use.

What is being protected?

Without control, every friendly "small tweak" rewrites the deal the sponsor thought they approved.

The typical change control process — stages and purpose

Organisations label stages slightly differently, but APM PMQ expects you to understand a complete chain. Learn purpose, not only names.

These stages are sequential in logic but may loop: incomplete requests return to the requester; detailed evaluation may uncover options that need rework; implementation may raise new issues that spawn further change requests.

1. Request

The request stage creates a controlled entry. Anyone authorised by the process (users, team members, suppliers, operations, sponsor) may raise a change, but it must be recorded — not only mentioned in a meeting. Purpose: visibility, prioritisation, and prevention of informal scope growth.

A good request states what is proposed, why, who wants it, and any known urgency or constraint. Incomplete requests should not skip ahead; they waste evaluation capacity and produce weak decisions.

2. Initial evaluation

Initial evaluation is a gate, not a full impact study. Typical checks:

• Is the request complete and understandable?
• Is it a true change to a baseline, or a clarification, defect fix, or issue already covered?
• Is it a duplicate of an open CR?
• Is it obviously outside project charter / business-case boundaries (and thus escalate or reject early)?
• Does urgency justify fast-track paths defined in governance (e.g. safety emergency) without skipping records?

Purpose: triage. Detailed evaluation is expensive; initial evaluation protects that investment and keeps the change log credible.

3. Detailed evaluation

Detailed evaluation analyses impact across the integrated project — not only "how many hours of coding." High-yield dimensions include scope, time, cost, quality, risk, benefits, resources, stakeholders, compliance/safety, and configuration interfaces. Options may include full accept, partial accept, alternative designs, deferral to a later phase/release, or reject.

Purpose: replace opinion with evidence so the recommendation is defensible to a change authority, sponsor, or board.

4. Recommendation

Recommendation is the professional conclusion of evaluation: approve, reject, defer, or approve with conditions / modified scope. It should state impacts, options considered, residual risk, and why the recommended path best serves objectives and the business case within delegated authority.

Purpose: enable a timely, accountable decision. Analysis without recommendation dumps work on the board; recommendation without analysis is ungoverned opinion.

5. Update plans

If approved, plans and baselines must be updated before (or tightly coupled with) implementation. That includes schedule, cost baseline, resource plan, risk register, quality/test plans, benefits forecasts where relevant, and configuration records. Purpose: the project’s single source of truth matches what was authorised. Approving a change but leaving the Gantt and budget untouched is incomplete control — the next status report will lie.

6. Implement

Implement executes the approved change under configuration control: amend products and documents, run revised tests, brief stakeholders and suppliers, and confirm completion criteria. Then close the change request with evidence. Purpose: authorised intent becomes real, controlled output — not a half-finished side branch that confuses handover.

Why uncontrolled change destroys baselines

A baseline is only useful if it represents the current authorised commitment. Uncontrolled change produces:

1. Phantom progress — earned value and % complete measure the wrong scope.
2. Broken forecasts — remaining work no longer matches the plan people report against.
3. Quality failure — acceptance criteria and tests lag the "actual" product.
4. Configuration chaos — multiple unofficial versions; nobody knows the approved state.
5. Benefits erosion — effort shifts to unapproved features that do not deliver intended value.
6. Governance failure — sponsor and board cannot decide because information is false.
7. Supplier and team conflict — different parties work to different silent agreements.

Memory cue: baseline without change control is a snapshot that dies the day after the first hallway promise.

Scenario A — the "tiny report"

After scope baselining, a director asks a developer to "just add one management report." The developer agrees informally. Two weeks later the report needs new data feeds, security roles, extra testing, and training updates. The schedule slips; cost rises; UAT fails because the test pack still reflects the old baseline. Correct practice: log a request, initial evaluation (is it in scope or a change?), detailed evaluation of interfaces and cost/time, recommend approve/defer/reject to the change authority, update plans if approved, then implement under configuration control.

Linear vs iterative life cycles — same stages, different rhythm

The stages still apply in both life cycles. What changes is formality, cadence, artefacts, and what is treated as baselined versus flexible.

Product backlog refinement vs formal CCB

In iterative delivery, backlog refinement continuously clarifies and reorders uncommitted work. That is healthy adaptability — it is not a licence to rewrite baselined commitments without authority. Examples that still need formal change control (or explicit higher authority):

• Changing a regulatory must-have after it was baselined for a release
• Expanding a fixed-price supplier package without commercial change control
• Altering an already-accepted increment that operations rely on
• Moving a strategic milestone or investment envelope outside tolerances

In linear delivery, a change control board (CCB) or equivalent authority typically reviews significant requests against baselined plans. Small changes may sit within the project manager’s delegated authority; large impacts escalate to sponsor or programme board. Iterative projects still need clear authority boundaries — the product owner is not always free to approve cost overruns that break the business case.

Hybrid reality

Many projects are hybrid: predictive control on capital gates, safety cases, and contracts; iterative control on feature discovery. Change control must cover both rhythms — a monthly CCB alone is too slow for two-week iteration discoveries, and pure backlog grooming is too weak for a baselined safety requirement.

Scenario B — iterative done right

A product team refines the backlog weekly. A user suggests a new workflow. The product owner logs it, scores value vs effort, and schedules it for a later sprint — fine for uncommitted backlog. The same week, compliance states that a new data-retention rule must apply to the next public release already planned against a baselined non-functional requirement set. That is a controlled change: request, evaluate impact on design, test, and release date, recommend to the right authority (possibly sponsor if tolerances threatened), update the release plan and configuration items, implement in the agreed increment.

Scenario C — linear CCB discipline

A civil works project has baselined drawings and a stage cost plan. A contractor proposes a materials substitution that might save cost but affect durability warranties. Correct path: formal request → initial screen → detailed evaluation (design, quality, risk, whole-life cost, warranty, programme) → recommendation to CCB/sponsor → if approved, update drawings, schedule, cost baseline, and configuration status → implement and verify. Skipping to "use the cheaper material on site tomorrow" destroys the design baseline and may invalidate assurance.

Putting stages together for exam answers

When a scenario shows informal scope growth, conflicting versions, or a surprise feature:

1. State that the item is (or should be) under baseline and therefore change control.
2. Walk the stages that apply — especially the missing one (often: no request logged, no impact assessment, or plans not updated after approval).
3. Name authority (PM limits, CCB, product owner, sponsor).
4. Note linear vs iterative fit without dropping governance.
5. Stress that uncontrolled change destroys baselines and decision quality.

That chain matches LO24(a): purpose of each stage and life-cycle differences — before deep dive into request content, options analysis, and recommendation justification in the next section.