Baseline approval must preserve assumptions

A baseline is an authorised reference for explaining change and performance. It is not a declaration that uncertainty has disappeared. The reference should preserve scope, logic, duration bases, calendars, resources, acceptance conditions and the decision context that justified its use. A date-only baseline cannot explain why later forecasts differ. It can show movement, but it cannot distinguish scope development from execution variance or an invalid original assumption. Baseline control begins with preserving the argument behind the dates.

The baseline should have an identifiable version and approval record. Its authority follows the project’s governance, not the software’s save function. A planner can publish a technically consistent candidate while the sponsor has not authorised a commitment. Conversely, a sponsor can approve a target that remains unsupported by the current forecast. The record should retain these distinctions. Calling every saved schedule approved creates false authority; calling every forecast revision a new baseline removes the reference needed to understand performance.

A baseline package should include its perimeter and exclusions. If operating readiness is excluded, state that the finish is construction completion under the defined acceptance boundary. If procurement durations are preliminary, identify the condition that will require review. These qualifications do not make the baseline useless. They make its use conditional and its future revision understandable. An early baseline can be a valid control reference for a bounded phase without pretending to be a firm end-to-end delivery promise.

Freeze the evidence cutoff with the baseline. The forecast may use supplier information available at that moment, while later information improves or contradicts it. A reviewer should be able to tell whether the original assumption was reasonable given its evidence, rather than judging it solely by hindsight. The same principle protects against retrospective optimism: a late favourable outcome should not be used to claim that an unsupported initial forecast was sound. Decision quality depends on the evidence and reasoning available when reliance occurred.

The baseline is also a coordination instrument. Package owners should know the obligations and interfaces against which they are being managed. A sponsor-level programme that assigns dates without recipient agreement may be a useful target but a weak execution baseline. The baseline review should test whether package boundaries, acceptance events and shared resources are understood. Consensus alone is not proof of feasibility, but disagreement about basic meanings is strong evidence that the model is not yet ready for reliance.

The current forecast should change when evidence changes. Protecting a baseline does not mean forcing the forecast to remain unchanged. A controlled system keeps the authorised reference while updating expected outcomes and explaining variance. This permits timely intervention. If teams suppress forecast movement because any delay is treated as a failure of loyalty, the baseline becomes a reporting constraint rather than a diagnostic tool. Delivery control needs a truthful forecast more than an unchanged chart.

Distinguish correction from authorised change. A typographical predecessor error may be corrected with a record explaining the defect and its effect. A revised design scope may require change approval. A different estimate based on new supplier evidence may alter the forecast while the baseline remains intact. These cases need different dispositions. A single button labelled rebaseline should not erase their differences. The change log should identify the category, authority and reason for the update.

A baseline revision should preserve comparability where possible. If a package splits, retain the mapping to its earlier identity. If new work is added, identify the added obligation and affected successors. If an estimate basis changes, state whether the scope remains comparable. This makes variance analysis useful without forcing artificial equivalence. It also allows lessons to distinguish a task that took longer than planned from a task whose actual scope became materially different.

Baseline changes can alter incentives. If delays are routinely absorbed into a new reference, performance appears to recover without a corresponding improvement in delivery. If legitimate scope changes are never recognised, owners are judged against obligations they did not accept. The control process should protect both historical truth and fair responsibility. Retain the original reference, approved revisions and current forecast, with a clear explanation of which comparison supports each reported conclusion.

Do not use baseline approval as a substitute for readiness. Approval may authorise a planning basis, budget or phase, while a subsequent release still depends on technical evidence and permissions. A package can be baseline-approved but not ready to start. A task can be forecast to finish without being accepted. The control vocabulary should preserve these states so a governance signature does not become an accidental physical completion claim.

A fictional planner discovers that an assembly task lacks a required receiving predecessor. At the same review, the sponsor requests an additional test. Both changes move the forecast, but they have different causes. The missing edge is a defect in the earlier network representation. The additional test is a proposed obligation whose treatment depends on actual authority and scope. Combining them into a single rebaseline would obscure the evidence needed to explain the variance.

The planner preserves the earlier version and records the logic defect. The corrected network reflects the already required receiving condition. Its effect is shown separately from the proposed test scenario. The sponsor can then see how much of the forecast movement comes from repairing the model and how much comes from changing the obligation. This is a controlled comparison, not an attempt to allocate legal responsibility through arithmetic. Actual agreements and contemporaneous evidence remain necessary for that question.

The test request receives a change record. The team asks whether it is a new requirement, clarification of existing acceptance or a different method of proving the same outcome. The answer affects scope and comparability. The current forecast can include a labelled scenario while the authority decides. The planner should not suppress the corrected receiving relation because the test decision remains pending. Model integrity and change authorisation are separate processes with different evidence.

The executive report retains the authorised baseline, corrected current forecast and test-change scenario. This may require more explanation than a single date, but it prevents a false story. A revised baseline can be approved later for future control while the earlier reference remains available. The report should state which comparison supports its conclusion. Saying the project is back on baseline after adopting a new date would be incomplete unless the actual delivery performance also improved.

The package owners need the corrected logic immediately. Assembly must understand that receiving acceptance governs its release regardless of how the sponsor treats the reference. The proposed test should not become an instruction until authorised. The manager therefore distributes a controlled release clarification and a separate pending-change notice. This avoids the operational danger of mixing a necessary correction with an optional or unresolved obligation.

The lesson is to preserve change categories through the decision chain. A model defect, new evidence and scope revision can occur together, but their concurrence does not make them equivalent. Separate their bases, then reconcile the selected plan. This supports truthful forecasting, fair review and usable future control without inventing a universal rule about when rebaselining is permitted.

The fictional installation baseline omits a separate readiness decision before integrated testing. During an interface review, the operator explains that the decision requires assembled-system evidence and a named accepting authority. The team has discovered a real obligation in the fictional case. The current forecast should include it immediately once its basis is sufficiently defined, while the change process decides how the reference and responsibility are treated. Waiting for formal rebaseline approval before showing the forecast would conceal useful information.

The baseline review asks whether the obligation was excluded deliberately, included implicitly in testing, or omitted unintentionally. Each answer leads to a different interpretation. If it was implicit, separating it may improve transparency without adding scope, but duration double counting must be avoided. If it was excluded, the baseline’s stated finish may have had a narrower perimeter than the sponsor assumed. If it was omitted, the original reference was incomplete for its intended use. The record should state the conclusion and supporting evidence.

The revised network should show the selected remedy rather than a generic delay allowance. A readiness decision with a defined submission and acceptance boundary provides a clearer control event than adding unexplained time to assembly. It also lets the team investigate review capacity, evidence preparation and conditional release. The interface-gate study offers an illustrative calculation of this structure. Its result should not be treated as the actual review duration or the financial value of the change.

The sponsor then decides whether an authorised baseline revision is justified. The decision should consider scope, governance rules, responsibility and the need for a usable control reference. Regardless of that decision, the earlier baseline remains available and the current forecast remains truthful. A revised reference can improve future management without rewriting the history of the earlier promise. This is especially important when external parties relied on that promise, since their consequences may remain even after internal reporting adopts a new date.

A baseline archive should be usable, not merely stored. Retain machine-readable inputs, relevant evidence versions, approval records and a concise explanation of change. Test that someone can reconstruct the comparison without relying on a planner’s memory. An archive of screenshots may prove what was shown at a meeting but cannot reproduce the network. The frozen study bundles demonstrate the more useful form: explicit input, exact output, scalar bindings and method limits. Real baseline archives need the corresponding operational and authority records as well.