M6.3 — Baseline Change & Configuration Control

M6.3 — Baseline Change & Configuration Control

1. Practical outcome

The learner should be able to turn a bounded approval into a verified revision of the affected scope, schedule, budget, progress, risk and configuration records. They should preserve previous baselines, maintain relationships between approved, forecast and as-built information, reconcile the revised control model and release the correct version to its users.

M6.2 governs the decision to change. M6.3 governs what happens to controlled information after that decision. It also governs routine configuration integrity: identifying controlled items, recording their status and ensuring that the right requirement, design, test and handover versions are used. The aim is to maintain a reliable reference without erasing delivery history or accepting inconsistent edits across systems.

Ask: “Which approved decision permits this edit, exactly which controlled items change, and can we prove that the released model reconciles while the previous reference remains recoverable?”

2. Core concepts

Baseline, current plan, forecast and as-built record

An approved baseline is the authorised reference for comparison. The current plan represents how remaining work is intended to be delivered. The forecast describes expected outcome given current evidence and assumptions. As-built information records what actually happened. Their dates and values may legitimately differ.

Do not reset the baseline every time a forecast deteriorates or a recovery plan is adopted. Doing so can remove the variance that management needs to understand. A baseline change requires the prescribed authority and a stated purpose. A forecast update follows evidence; a historical correction follows a controlled error process; an as-built entry follows actual records.

Configuration is the identity and relationship of controlled items

A configuration item is an identified element whose definition and status need control. Examples include an approved requirements set, design drawing, WBS dictionary, cost allocation, schedule file, acceptance rule, system configuration, test script and handover record. Define identifiers, owners, versions, approved states and dependencies.

Configuration control asks whether these items are mutually compatible. A new equipment specification with an old test script may produce an invalid acceptance result. A budget loaded under the wrong WBS can preserve the grand total while assigning authority to the wrong owner. A shared folder containing the correct file does not establish that users are working to it.

Approval boundary and effective date

The change package should specify what is authorised, which conditions must be satisfied, who checks implementation and when the release becomes effective. Conditional approval cannot be translated into an unconditional system update. If an approved scope cannot be implemented within its stated price or date boundary, route the exception back through change control.

Separate approval date, implementation date, release date and effective reporting period. They need not coincide. Preserve the actual chronology and the basis for applying a revision prospectively or correcting prior information. Historical figures should not silently become different because the latest file contains new values.

Preserve history and explain the bridge

Retain an immutable approved original and each authorised revision, with inputs, calendars, logic, estimates, mappings and approval evidence needed to reproduce it. Preserve the current forecast snapshots separately. A filename suffix alone is not a version-control system: the release record must identify the actual contents and approval.

For any reported movement, distinguish approved scope/budget/date changes from performance variance, forecast learning and data correction. Comparisons may be required against both the current control baseline and the original commitment. State the reference used. A changed denominator can alter reported percentages even when no additional work has been achieved.

Budget conservation and time phasing

Reconcile transfers at the item, package and project levels. Moving 0.200m CU from central contingency to Technology increases one budget and decreases the other; it does not increase the project cap. Include any authorised increase separately and never infer it from the fact that a package budget grew.

Time-phase the changed budget against the approved delivery sequence and progress method. Check that the sum of periods equals the revised package and project totals. Do not create retroactive planned value merely to improve an adverse index. Changes to historical period values require explicit approved treatment and transparent comparison, not an unnoticed overwrite.

Progress and earned-value boundaries

New scope needs its own measurement rules, weighting and acceptance conditions. If a new work package is separately budgeted, its accomplishment must not also earn credit in an existing work package. Review aggregation and denominators whenever scope changes, especially when a parent percentage hides differently measured children.

The 100-point, 1.000m CU acceptance subset in M5.3 is an explicitly defined teaching work package. Adding functionality to the broader Technology package does not automatically increase that subset's BAC or convert previously accepted points into a different earned value. Decide and authorise any measurement change; otherwise preserve its boundary and create a separate measured package for the new scope.

Status accounting and release verification

Maintain a list of controlled items and their status: current approved, superseded, working, awaiting approval, released and as-built as applicable. Record which versions belong together in a release manifest. A baseline release should reconcile scope, activities, budgets, risks, progress rules and interface documents before it is distributed.

Verification includes testing relationships, not merely checking filenames. Confirm that newly inserted work precedes its acceptance milestone, resources and cost cover the same work, the fixed opening constraint is preserved, total budget balances and downstream report definitions use the correct version. Controlled changes to a working copy should not leak into live reporting before release.

Corrections and replanning require explicit treatment

A mapping error, duplicate activity or incorrect formula may need correction even without a scope change. Document the error, affected outputs, authority and historical restatement rule. Keep the original record and explain which prior conclusions change. Do not label a correction as new scope to conceal the error.

Where a major replan or rebaseline is authorised, preserve accumulated performance information and the comparison to the original commitment. Define why the previous reference is no longer adequate and what the new baseline means. A fresh baseline may aid management; it does not prove that previous delay or overspend disappeared.

Distinguish controlled internal replanning and rolling-wave detail from a formal over-target baseline (OTB) or over-target schedule (OTS). Approved future-work replanning may be legitimate without a scope increase. OTB/OTS is a separate, authorised recovery process under the applicable system; it is not new funding or permission to rewrite history. If that process permits a variance adjustment, disclose it and preserve the original commitments and pre-adjustment performance.

Some adopted EVMS arrangements also permit a controlled single-point adjustment during an authorised replan within existing budget and schedule targets. That is not a routine forecast refresh: follow the system’s conditions, justification, customer notification and any required approval. Disclose the adjustment and retain pre-adjustment variances, original commitments and a full reconciliation so the new reference does not conceal past performance.

3. Step-by-step method

1. Verify the approval package. Check authority, scope, funding, date/cost boundaries, conditions and baseline-release rights.

2. Identify affected configuration items. Map requirements, WBS, activities, budgets, codes, progress rules, risks, specifications, tests, handover and reports.

3. Freeze the starting state. Retain the approved baseline, current forecast and relevant period data, with versions and reproducible input files.

4. Define the implementation and effective-date rules. Specify which reporting periods change and whether any authorised historical correction is required.

5. Work in a controlled staging copy. Restrict editing, assign owners and prevent unverified files entering production reporting.

6. Update scope and technical configuration. Implement approved requirements and interfaces, update acceptance/test definitions and trace their relationships.

7. Update schedule and resources. Insert authorised work, logic, calendars and milestones; recalculate and distinguish baseline change effect from current forecast movement.

8. Update budget and cost structures. Reconcile transfers, package/project totals and time phasing; keep actuals, commitments, ETC and approval balances distinguishable.

9. Update progress and uncertainty. Establish measurement for new work, preserve prior accomplishment, revise risk links and reconcile change allowances without double counting.

10. Verify the integrated release. Test identifiers, totals, paths, acceptance gates, period treatment, mappings and report references, using independent checking where proportionate.

11. Release and communicate. Record the approved contents, release/effective dates, users and superseded versions; obtain acknowledgement from affected owners.

12. Check first use and preserve the audit trail. Reconcile the next report to the release, inspect any stale interfaces and retain approval, edits, checks and distribution evidence.

4. Worked Reference Project example — Community & Learning Centre

Context — implement CR-M6-01 without resetting performance

Use the M6.2 teaching branch in which the Board approves the additional power-resilience and monitoring function for 0.200m CU. The unchanged project cap is 50.000m CU. The approved transfer increases Technology budget from 3.800 to 4.000m CU and reduces the specified pre-fire-drawdown central contingency balance from 1.800 to 1.600m CU.

For this example, call the previously approved control release B01 and the revised release B02. These are new illustrative identifiers; they do not rename historical files in the Reference Project. Set the teaching effective period as Month 17, preserving Month 16 source and report snapshots. Approval and release occur only after the stated availability, schedule and acceptance conditions are verified.

Step A — prepare the release manifest

The manifest identifies exact file/item versions and owners in the actual implementation. The table teaches the required relationships; the labels alone are not evidence of release.

Step B — reconcile budget and forecast separately

Before transfer: Technology 3.800 + central contingency 1.800 = 5.600m CU. After transfer: Technology 4.000 + central contingency 1.600 = 5.600m CU. All other approved allocations remain unchanged, so project budget remains 50.000m CU.

The new work's budget is time-phased across its approved procurement, configuration, testing and handover activities in the remaining periods. Its total is 0.200m CU. This does not alter the Month 16 actual-cost ledger or reassign already incurred cost to improve a performance ratio.

Working EAC moves from 49.510 to 49.710m CU because the new scope adds expected cost of 0.200m CU. The transfer does not add a second 0.200m CU. Baseline budget, available contingency and expected cost each remain visible, with headroom 50.000 − 49.710 = 0.290m CU.

Step C — preserve the schedule reference

The approval permits the defined additional work and its verified three-working-day downstream effect, while keeping public opening fixed. For the working forecast in this branch, readiness moves from eight to five working days before opening.

For B02, the planner implements the approved scope into the B01 baseline network, verifies its own change effect and preserves the original B01 planned dates. If the verified baseline effect is also three working days, B02 planned readiness equals B01 planned readiness plus three working days on the applicable calendar. B01 planned readiness is not assumed to equal the current forecast. Copying the forecast's five-day margin directly into the baseline could erase existing performance variance.

The release check therefore reports the B01-to-B02 approved change separately from the B02-to-current-forecast variance. It also confirms that the unchanged opening commitment remains explicit and that any conflict with it returns to the release authority rather than being resolved by moving the opening date.

Step D — protect progress measurement

The existing 100-point acceptance subset and its 1.000m CU BAC remain as defined in M5.3. The enhancement becomes a separate measured work package with 0.200m CU budget and defined equipment/configuration/test acceptance stages. Previously accepted points do not earn the enhancement's budget.

Month 16's 64 accepted points, EV 0.640m CU and AC 0.800m CU for the original subset remain preserved. The new package's PV is set according to its approved Month 17-onward plan; EV requires its own evidence. If a later aggregate combines the packages, the report identifies compatible budgets, cut-offs and methods and does not present the parent's percentage as unchanged merely because the old subset has advanced.

Step E — verify before and after release

A peer checker finds that one integration-test script still references the superseded configuration. B02 stays in staging until the acceptance owner issues and approves the compatible script. A changed drawing cannot compensate for an unchanged test definition.

The released manifest records approval, exact item versions, Month 17 effective treatment, checks and distribution. The first Month 17 report confirms the 50.000m CU budget, 49.710m CU working EAC, correct change bridge, unchanged Month 16 snapshot and current acceptance references. Working copies of B01 are marked superseded for current use but preserved for history and forensic comparison.

5. Interpretation and professional judgement

An unchanged total can conceal a serious error

A budget may reconcile to 50.000m CU while the wrong package receives authority or a cost code maps to the wrong owner. Check allocation and meaning as well as arithmetic. Similarly, a date may look acceptable because an open end allows new test work to sit outside the readiness path.

Preserve comparisons that management needs

Current-baseline reporting helps delivery against authorised scope. Original-baseline reporting explains how commitments and scope have evolved. Forecast comparisons show expected performance. Select and label the reference appropriate to the question; do not switch references because one produces a more favourable variance.

Version control is a delivery control

Using a superseded technical or test item can create rework, failed acceptance and disputes. Communicate releases to actual users and check first use. A central repository helps, but permissions and distribution records need to make the controlled version usable and distinguish it from unfinished work.

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 B02 implementation and release record for CR-M6-01.

·       1. List eight controlled items, their owners and the evidence needed to verify each revision.

·       2. Reconcile the Technology, contingency and project budgets and explain the separate EAC movement.

·       3. Show how you would preserve Month 16 and make Month 17 the effective period.

·       4. Explain why the original 100-point work package does not automatically gain a 1.200m CU BAC.

·       5. Describe how you would report approved baseline movement and current forecast variance separately.

·       6. Investigate a test script that references the old configuration and state whether release may proceed.

·       7. A mapping error is discovered in a prior report: define a correction route that preserves the original and states which comparisons change.

What good performance looks like

The release maintains project budget 50.000m CU, Technology 4.000m CU and the specified central contingency 1.600m CU. It reports EAC 49.710m CU once, retains the original subset's BAC and historical values, and blocks release of incompatible test configuration. It does not assume that B01 readiness equalled the current forecast or that a baseline edit removes performance variance.

Final challenge: “Could another practitioner reconstruct the approved change, its implementation and every reported comparison from the preserved versions?”

8. Bridge to capability

The How-to teaches how authorised changes become coherent controlled references. At APPLIED and above, capability assessment should test whether the practitioner can implement a realistic release across linked records without losing history or measurement integrity. A release manifest, reconciled before-and-after positions and verification records should substantiate the outcome. 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 approved control references are maintained?

Capability question for APPLIED and above: Can you demonstrate a coherent authorised release and prove that history, totals and progress treatment remain reliable?