M6.2 — Change Control

M6.2 — Change Control

1. Practical outcome

The learner should be able to recognise a potential change, record and define it, assess integrated consequences, identify the correct authority, support an approve/reject/defer decision and track implementation to verified closure. They should distinguish a changed requirement from a forecast movement, corrective action, data correction or contractual claim, and preserve these relationships without treating them as interchangeable.

M6.1 establishes decision rights. M6.2 controls the decision to change; M6.3 implements approved changes in the baseline and configuration. A project can identify a change before its price, schedule effect or entitlement is agreed. The control record must show that maturity and avoid presenting an unapproved proposal as authorised scope.

Ask: “What has changed from the controlled requirement, what would it affect, who may decide, and what must remain visible until the decision is implemented?”

2. Core concepts

A change needs a defined reference

Identify the approved requirement, drawing, specification, scope statement, budget or milestone being changed. A request for “better resilience” is not yet an assessable change. Define the existing function, proposed function, acceptance conditions and interfaces. Name the requester, reason, required decision date and evidence of the request.

A change can add, remove, substitute or resequence authorised scope. It can arise from client direction, design development, an interface discovery or an external requirement. Whether an item constitutes a contractual variation or creates an entitlement is a separate question for the authorised commercial and legal process. Controls should document facts and impacts without deciding that question by the label on a register.

Classify the event before routing it

Lower observed productivity changes the forecast even when scope is unchanged. An additional crew to deliver existing requirements can be a corrective response requiring expenditure authority without becoming new functional scope. A coding error needs a controlled correction. An additional system function needs assessment as a scope change. A supplier claim needs preservation and commercial review, whether or not the underlying event is also recorded as a change.

Use linked records where several processes apply. One event can have a risk, issue, change request, contract instruction and claim reference. Link them through a common event ID; do not create several independent allowances for the same cost or delay. Classification should help governance, not become an excuse to leave uncertain events unrecorded.

Decision status, implementation and closure

Typical states include identified, defined, under assessment, submitted, approved, rejected, deferred, implementing and closed. State what each means and who can move the record. A request approved in principle subject to price is not a fully authorised instruction. A deferred request remains open with a next decision point and a stated consequence of delay.

A valid instruction can authorise defined work before its final price is agreed, where the governing arrangements permit authorised unpriced work. Record the written authority, scope, limits, provisional estimating/budget basis and route to price agreement. Under an adopted EVMS, incorporate that authorised scope using its controlled planning and budgeting rules. Keep it distinct from an unapproved request, and do not treat a spending ceiling as evidence that forecast cost will remain within it.

Approved does not mean implemented; implemented does not necessarily mean accepted; accepted does not prove that all control records are reconciled. Closure needs evidence of the agreed scope, acceptance, contract treatment, baseline implementation and residual actions, as applicable. Rejected changes also need preserved rationale and instructions to prevent accidental delivery.

Integrated impact assessment

Assess scope and acceptance, engineering and operational interfaces, schedule sequence and calendars, direct and time-related cost, risk, commercial terms, procurement, resources, training, maintenance and handover. State exclusions and uncertainty. Confirm whether the same delivery assumptions support both date and cost.

Distinguish local duration from project completion. Adding three days of configuration work might consume readiness margin, create a new path or fit within non-controlling work. The planner must calculate and trace the affected network. A three-day activity is not automatically a three-day extension of the project's authorised opening.

Authority, funding and affordability

Identify who can approve the changed requirement, its funding and any contractual instruction. A budget transfer does not grant scope authority. Forecast headroom does not create a budget. Available contingency may have restrictions on its purpose and release; check them before proposing it as funding for discretionary new scope.

Record the gross instruction value and any offsetting savings separately. Do not request authority only for a net EAC difference if the transaction to be entered is larger. Compare options against whole-project commitments and residual uncertainty, not merely the change's immediate cost.

Forecast exposure before approval

An unresolved change can affect the current expected outcome without belonging in the approved baseline. Report approved budget and baseline separately from pending exposure, conditional scenarios and the current forecast treatment. Establish a documented inclusion rule based on available evidence and maturity; do not mechanically include every request or exclude every unapproved exposure.

Show whether a change allowance is already included in ETC, contingency modelling or a commercial provision. Reconcile status changes so that approval does not add the same cost twice. Retain a bridge between the prior forecast, newly assessed exposure and the approved outcome.

Emergency action and retrospective requests

Urgent protective action may be necessary under the project's actual emergency arrangements. Preserve what was instructed, by whom, under which authority and when; route subsequent assessment and documentation promptly. Urgency should not be used to hide an unauthorised scope commitment or manufacture an approval date after the event.

When work has already occurred, state that fact and separate the chronology of instruction, performance and subsequent governance decision. Do not backdate the change request. Investigate why the process failed and use the correct commercial and organisational route to regularise or resolve the position.

3. Step-by-step method

1. Capture the event or request promptly. Record source, date, requester, description, reference and the decision or delivery deadline.

2. Identify the controlled reference. Describe what is currently approved and exactly what differs, including acceptance conditions and affected interfaces.

3. Classify and link. Distinguish scope change, corrective response, forecast movement, error correction and commercial claim; create linked records where necessary.

4. Define the request. Resolve ambiguity, establish boundaries and assumptions, and identify the affected WBS, design, schedule, cost, risk and operational items.

5. Develop options. Include rejecting or deferring where feasible, and explain the consequence of each option for fixed commitments and operational value.

6. Assess integrated impacts. Obtain schedule, cost, risk, technical, commercial and operational input based on the same scope and delivery assumptions.

7. Reconcile forecast exposure. State what is already included, what is incremental and what remains uncertain; avoid adding exposure in several places.

8. Confirm authority and funding. Verify approval rights, restrictions, budget transfers, gross transaction values and contract-instruction responsibilities.

9. Prepare the decision brief. State the requested decision, options, evidence, conditions, residual uncertainty, latest decision point and consequence of delay.

10. Record the decision. Preserve authority, date, approved boundaries, conditions, rationale and rejected/deferred alternatives. Resolve conditional approvals explicitly.

11. Authorise and coordinate implementation. Issue instructions through the correct channel and pass the approved change package to M6.3 for controlled baseline/configuration updates.

12. Verify and close. Check delivered and accepted scope, actual control-record changes, commercial status and residual actions. Preserve the audit trail and learn from any process failure.

4. Worked Reference Project example — Community & Learning Centre

Context — distinguish recovery from new functionality

Continue the M5 recovery case as a new, clearly labelled teaching branch. For this branch, assume the defined recovery has been authorised, secured and validated sufficiently for 49.510m CU and readiness eight working days before opening to become the working deterministic forecast. This assumption does not claim that the later 81-point review proved recovery in the earlier exercise; these are alternative learning snapshots.

The approved project cap remains 50.0m CU. Use the M4.5 pre-fire-drawdown budget snapshot with 1.800m CU centrally held contingency and Technology package budget 3.800m CU. No later fire-defect drawdown is assumed in this branch. The cost and schedule forecasts include the existing recovery response, but not the new request below. Probabilistic confidence remains subject to updated assessment.

Step A — define change request CR-M6-01

The client asks for an additional power-resilience and remote-monitoring function in WBS 1.4 Digital & Technology Systems. It goes beyond the currently approved functional requirement. Existing required safety and operational acceptance standards still apply; the example does not assume that a statutory requirement can be waived.

The request defines additional equipment, configuration, integrated tests, handover information and operator familiarisation. The technical owner identifies interfaces with building power and operational readiness. The change assessor excludes unrelated refurbishment and records that the additional work's estimate is incremental to all cost already in the 49.510m CU forecast.

Step B — compare defined options

The before-opening estimate is 0.150m CU for equipment and configuration, 0.030m CU for integration/testing and 0.020m CU for training and handover: total 0.200m CU. The planner inserts the new work into the remaining network and confirms three working days of net downstream movement in this simplified branch. Existing forecast margin of eight days becomes five; the fixed public opening is not moved.

The post-opening alternative is an unpriced option, not a zero-cost solution. The decision brief identifies the information needed to price it and the operational implications of working in an occupied centre.

Step C — separate forecast, funding and authority

Conditional EAC with the enhancement = 49.510 + 0.200 = 49.710m CU. Deterministic headroom to the project cap becomes 0.290m CU. This is a scenario, not proof of adequate protection or a new confidence percentage.

For this teaching branch only, the Board is permitted by the project mandate to release 0.200m CU from central contingency for this approved requirement and to transfer the budget into Technology. That permission is an explicit assumption; the learner must check whether a real reserve permits this use. The Board retains authority over new functional scope even though the expenditure is less than other delegated financial limits.

The proposed transfer is Technology 3.800 → 4.000m CU and central contingency 1.800 → 1.600m CU. Their combined budget remains 5.600m CU and the project total remains 50.000m CU. Funding allocation and forecast cost are different records; the contingency transfer is not added again to EAC.

Step D — record a bounded decision

Assume the Board approves the before-opening enhancement with the 0.200m CU transfer, conditional on confirmed equipment availability, a verified three-day network impact and the specified acceptance tests. The decision identifies who may issue the contract instruction and who may release the revised baseline. If a condition fails, the change returns for review rather than quietly expanding its cost or date boundary.

The authorised commercial officer records the agreed instruction and terms. The change record links the approved requirement, estimate, schedule analysis, funding decision and risk assessment. M6.3 receives this complete package; the fact that the Board approved the request does not authorise arbitrary edits to other baseline items.

Step E — follow implementation to closure

Closure requires delivered equipment, passed tests, updated configuration and handover records, approved budget/schedule release and reconciled forecast treatment. If only the contract instruction has been issued, status is implementing rather than closed.

The controls manager checks whether any unspent allowance has been removed or reconciled and whether residual integration risk remains. The final record preserves the original request and options, decision conditions, actual implementation and outcome. It should allow another practitioner to explain why the 0.200m CU appears in Technology and why the project cap did not change.

5. Interpretation and professional judgement

A better feature can still be the wrong timing decision

The requested enhancement may add operational value while reducing readiness margin. Governance must judge its value against delivery feasibility and uncertainty. An affordable deterministic EAC does not settle whether the feature should be implemented before opening. Preserve the option to reject or defer when evidence cannot support the requested timing.

Do not change history to make the process look compliant

A late request, informal instruction or completed unauthorised work creates a real governance problem. Record the chronology honestly and route the resolution. A retrospectively polished register cannot replace the evidence of who instructed what and when.

Approval has a defined boundary

Approval of one scope and cost does not authorise any future variant described with the same change ID. If configuration, cost or schedule conditions materially alter, reassess and obtain the required decision. A clear boundary supports delivery rather than creating a new argument after the work has occurred.

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Prepare the CR-M6-01 change assessment and decision record.

·       1. Write the existing and proposed functional requirements with three observable acceptance conditions.

·       2. Explain why the 0.120m CU recovery intervention and the 0.200m CU enhancement take different governance routes.

·       3. Reconcile the conditional EAC, headroom and budget transfer without double counting contingency.

·       4. Show what happens if new configuration produces a six-day rather than three-day downstream movement.

·       5. State how you would report the request if the Board defers its decision while equipment availability deteriorates.

·       6. Identify evidence required before marking the approved change implemented and closed.

·       7. Explain how you would handle an email showing that part of the enhancement had already been instructed informally.

What good performance looks like

The assessment states EAC 49.710m CU, headroom 0.290m CU and unchanged project cap 50.000m CU. Technology budget increases by 0.200m CU while central contingency decreases by the same amount. A six-day movement would leave only two working days of deterministic readiness margin, which must return for review against the approval boundary. The record preserves actual chronology and does not infer either entitlement or acceptance from an informal instruction.

Final challenge: “Could the approver understand exactly what is being authorised and could the implementation team prove that it delivered only that approved change?”

8. Bridge to capability

The How-to teaches how a potential change becomes a controlled decision and implementation. At APPLIED and above, capability assessment should test whether the practitioner can define a realistic request, reconcile impacts and use the correct authority and funding route. Scope, options, decision conditions and closure evidence should support the assessment. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how a proposed change becomes a controlled decision?

Capability question for APPLIED and above: Can you demonstrate a justified change decision and verified implementation without losing scope, authority, funding or forecast traceability?