Baseline Development and Schedule Assurance

The decision: is this programme ready to become the control reference?Source §Baseline development · Decision-led opening

A project team may produce persuasive milestone dates while the underlying model still contains missing interfaces, unsupported calendars, unowned assumptions or incomplete approval evidence. Baseline development turns a schedule file into a controlled package that can support performance measurement, forecasting and accountable change.

Prerequisite checkSource §Learning sequence · Prior knowledge

This lesson assumes that activities have defined scope, defensible durations, calendars, relationships and resource assumptions. Assurance tests the quality and traceability of that model; it does not invent missing construction logic after submission.

Define the baseline as an authorised control referenceSource §Baseline development · Baseline concept

A schedule baseline is a time-phased, integrated plan accepted through the project’s stated governance for use as a performance reference. It records the intended scope, sequence, timing and assumptions at approval. Later actuals and forecasts are compared with it; the baseline is not silently rewritten whenever the current expectation changes.

Baseline

The authorised integrated plan retained as the reference for performance and controlled change.

Current forecast

The latest evidence-based projection of remaining work and completion at a stated data date.

Management target

An internal objective that may be more demanding than the approved reference but remains separately identified.

Schedule assurance

Structured challenge of completeness, logic, dates, calendars, traceability, governance and fitness for control.

Planning narrative

The controlled explanation of methods, basis, assumptions, interfaces, risks, paths and limitations that the schedule alone cannot communicate economically.

Baseline acceptance means the submitted plan is considered suitable for the stated control purpose under the recorded assumptions. It does not predetermine responsibility for every future event, transfer every risk, or prove that the project will finish exactly on the baseline date.

Assemble a reproducible baseline packageSource §Baseline package · Package assembly

A reviewer needs the editable or controlled schedule model, readable outputs and the evidence required to interpret them. The package should allow another competent person to trace a selected milestone through detailed logic, scope, calendars, resource assumptions, risk treatment and approval history without relying on undocumented personal knowledge.

Use the planning narrative to expose the model basisSource §Baseline package · Planning narrative

The narrative explains construction methods, access strategy, procurement interfaces, calendars, key paths, float interpretation, resource assumptions, risk allowances, constraints, unresolved matters and schedule limitations. Its role is not to repeat every activity row but to make the model’s decision logic reviewable.

• Identify submission purpose, status, data date, revision and approval sought.
• State scope boundaries, coding structure and reconciliation to project requirements.
• Describe construction, procurement, testing and handover methods that drive logic.
• List calendars, shifts, access windows and material time assumptions.
• Explain critical and near-critical paths, significant float and major interfaces.
• Record resource capacity, risk treatment, allowances, constraints and unresolved decisions.
• Name the evidence owner and update trigger for every material assumption.

Assure schedule quality through layered challengeSource §Schedule assurance · Assurance approach

Schedule assurance combines qualitative questions about scope, methods, ownership and usability with quantitative prompts about logic, dates, calendars, constraints and durations. Neither layer is sufficient alone. The reviewer investigates why a pattern exists and whether the explanation is consistent with the project basis.

• Confirm file identity, status, data date and review purpose before calculating metrics.
• Run completeness and integrity checks before interpreting milestone dates.
• Select representative milestones and trace their driving logic to source requirements.
• Investigate unusual patterns with the planner, method owner and interface owners.
• Classify each finding and name the evidence required for closure.
• Recalculate checks after corrections and preserve both response and result.
• Keep the recommendation separate from the authorised approval decision.

Challenge logic, dates, calendars and constraintsSource §Schedule assurance · Model-integrity checks

The review asks whether each significant date is calculated from physical or decision logic under the stated working-time basis. Hard constraints, large lags and global calendars can make a programme appear stable while disconnecting dates from the actual sequence.

Reconcile vertically and horizontallySource §Schedule reconciliation · Reconciliation concept

Vertical reconciliation tests whether detailed activities calculate the dates shown at higher summary levels. Horizontal reconciliation tests whether connected lifecycle streams—design, procurement, construction, testing, handover and external decisions—contain complete and consistent interfaces.

Classify findings before deciding readinessSource §Schedule assurance · Finding disposition

A useful assurance log distinguishes a model defect that needs correction from a question that needs explanation, an unusual but justified exception, and a matter that requires management authority. This prevents numerical prompts from becoming automatic failures and prevents unresolved blockers from disappearing into narrative text.

Preserve versions, targets and authorised changeSource §Baseline control · Version governance

The approved baseline, current forecast and internal targets require stable identifiers and status labels. Access controls protect the source model, while readable exports retain revision and data-date information. Approved change records why the reference changed, who authorised it, which impacts were accepted and when the new basis became effective.

• Record the event or decision that creates the proposed change.
• Identify affected scope, logic, resources, costs, risks, milestones and parties.
• Compare options against the current baseline and forecast using the same cut-off.
• Obtain the authority required by the governing procedure.
• Issue the new status and effective date while retaining the prior version.
• Communicate whether reports compare against baseline, forecast or management target.

Run a baseline-readiness panelSource §Interactive learning · Simulation sequence

The explorer begins with a fictional submission containing open finishes, missing procurement interfaces, unexplained lags, an unsupported calendar, untraced milestones and incomplete package evidence. Predict the panel outcome, change one condition at a time, and distinguish blockers from professional review prompts.

Issue a controlled readiness recommendationSource §Management interpretation · Decision communication

Independent challenge should sample important and surprising dates, trace them through the model and inspect the source evidence. The reviewer should be able to disagree constructively without changing the schedule secretly; the response log becomes part of the baseline record.

Lesson synthesisSource §Learning sequence · Synthesis