5.1 Baseline Establishment, Forecasts, and Controlled Revision

5.1 Baseline Establishment, Forecasts, and Controlled Revision

A baseline schedule is an approved reference used to measure performance. Its contractual status depends on the governing documents: it may be a contract requirement, an accepted submittal, or an internal management target. A current schedule records actual status to a data date and forecasts remaining work from current information. The two must be related but not confused.

Establishing the reference

Before approval, review the proposed baseline against its specification and intended use:

• scope and milestone completeness;
• activity definition and coding;
• logic, lags, constraints, and calendars;
• quantity, productivity, duration, and resource assumptions;
• procurement, owner, third-party, testing, and turnover interfaces;
• cost or resource loading where required;
• risk and contingency treatment;
• schedule basis, assumptions, exclusions, and known limitations; and
• reconciliation to the contract, estimate, execution plan, and reporting structure.

Record review comments and dispositions. Approval should identify the file, data date or start basis, revision, responsible authority, and any accepted exceptions. Preserve the approved native file and related basis documentation.

Baseline versus forecast

The baseline answers: what was approved? The current forecast answers: what is now expected? Actual starts, actual finishes, remaining durations, revised logic, and current conditions belong in the working update. Comparing current values with baseline values produces variance. If poor productivity moves completion later, the current forecast should show that movement; changing the baseline merely to remove the variance destroys useful information.

The baseline itself is usually retained as a frozen comparison. Some systems copy baseline dates into designated fields while others maintain separate files or versions. The control principle is preservation and traceability, not a particular software label.

Change states

A disciplined system distinguishes:

1. potential change: identified but not authorized;
2. proposed change: defined and submitted for evaluation;
3. approved change: authorized under the applicable process; and
4. implemented change: incorporated into the controlled cost and schedule systems.

A proposed change may be modeled in a sandbox, fragnet, or scenario to understand time and resource effects. Modeling does not itself establish entitlement or approval. The live forecast may need to reflect work that is actually occurring even while commercial responsibility remains unresolved; reports should label the situation and preserve both technical truth and governance status.

Controlled revision

An authorized scope, milestone, funding, or execution-strategy change may justify a revised baseline if the governing procedure permits it. Before revision:

• identify the authorization and effective date;
• define added, deleted, or modified scope;
• validate logic, durations, resources, cost, and risk;
• reconcile time and budget effects;
• preserve the prior baseline;
• issue the new revision with a bridge explaining the change; and
• retain the current forecast and historical variance record needed by governance.

Organizations sometimes use supplemental or replanned control baselines for major restructures. The terminology and authority vary. Do not infer from a schedule-health problem alone that revision is allowed or prohibited; apply the project’s rules and document the decision.

Reporting

A useful report can show original baseline, current approved baseline, prior forecast, current forecast, and any pending-change scenario as separate series. This allows management to distinguish authorized change from execution performance and emerging risk. Every series should have a named source and status.

The baseline is valuable because it preserves a stable reference. Change control is valuable because projects legitimately change. Sound baseline management supports both needs through authorization, transparent forecasting, version preservation, and an audit trail.

Applied review: build a change bridge

When an authorized revision is proposed, prepare a bridge that starts with the prior baseline and lists each approved scope, logic, duration, calendar, resource, cost, and milestone change. Recalculate the model, reconcile authorized time and budget, and explain any residual performance variance that the change does not address. The bridge lets a reviewer distinguish a changed commitment from changed execution performance.

Preserve scenario models separately from controlled baselines and current updates. Label their purpose, status, assumptions, and owner. This prevents a “what-if” recovery or claim model from being mistaken for the approved plan and keeps management comparisons reproducible across reporting periods. Confirm that the current cost system, change register, and schedule use the same authorized scope cutoff before presenting an integrated variance. Record the effective date, revision, status, and responsible approver for every controlled reference, artifact, and report.

Review disposition and acceptance

Keep technical review, contractual compliance, and approval status distinct. A schedule may calculate successfully yet omit scope, conceal a resource conflict, or violate a required coding rule. Conversely, an unusual relationship or a high-float path is not automatically defective if it has a documented purpose and satisfies the governing requirements. Review comments should identify the requirement or technical concern, its effect on the model, the responsible party, the requested correction, and the final disposition. Recalculate after material corrections because one logic, calendar, or duration change can move paths elsewhere in the network.

If the approving authority accepts a baseline with listed exceptions, retain the exception list beside the approved version and track its closure. Acceptance does not make a known limitation disappear, and a reviewer should not quietly repair another party's file without preserving what changed. In an exam scenario, favor traceable review and documented disposition over either automatic acceptance based on a software health score or automatic rejection based on a single metric.