Replanning vs Rebaselining

A replan adjusts the plan for authorized work, usually by revising the future schedule, budget time-phasing, or work package structure through change control. A rebaseline establishes a new approved measurement reference when the existing baseline no longer provides a useful basis for control.

That is the practical answer to replan vs rebaseline. However, the terminology requires care. Programs sometimes use rebaseline as a general label for any baseline revision. In formal Earned Value Management System (EVMS) usage, a major reset may instead be called formal reprogramming, an Over-Target Baseline (OTB), an Over-Target Schedule (OTS), or both.

Therefore, planners should identify the type of change, approval authority, budget source, variance treatment, and affected baseline level. The label alone does not establish what the program may change.

Replan vs Rebaseline: The Working Distinction

What is replanning?

Replanning modifies the plan for authorized work. It commonly affects future activities, relationships, durations, resources, budget time-phasing, planning packages, or work packages. The program processes these revisions through its approved baseline change-control procedure.

Replanning can take two broad forms:

• Internal replanning adjusts the remaining plan to address execution conditions without changing the externally authorized scope. Examples include resequencing future work, converting a planning package into detailed work packages, or revising the approach for completing a test effort.
• Authorized-change replanning incorporates a customer-approved change to scope, schedule, budget, or technical requirements. The source may be a contract modification, approved change order, or equivalent program authorization.

NASA’s Program Planning and Control glossary describes replanning as updating the plan for formally authorized requirements while maintaining traceability to previous baselines. It also distinguishes internal replanning from customer-directed or external replanning.

A replan does not automatically mean that the entire Performance Measurement Baseline receives a new starting point. Instead, the change should remain limited to the affected future work and follow the program’s approval thresholds.

What is rebaselining?

Rebaselining establishes a revised basis for measuring performance. Programs generally consider it when the existing cost or schedule baseline has become so unrealistic that it masks emerging problems instead of supporting management decisions.

The GAO Schedule Assessment Guide explains that schedule rebaselining should restore management control over remaining work when the current baseline no longer supports realistic performance measurement. GAO also warns that it should be rare because a new baseline can eliminate historical schedule variances and reduce visibility into prior performance.

In a DoD contractual EVMS environment, a broad rebaseline may involve formal reprogramming through an OTB, OTS, or both. However, rebaselining can also refer to a revised acquisition program baseline, an agency project commitment, or a software baseline snapshot. Those actions operate at different governance levels and are not interchangeable.

How the Two Actions Differ

Scope of the change

A replan normally targets specific remaining work. For example, a Control Account Manager (CAM) may revise the future sequence of design-release activities or detail a planning package as the work approaches.

A rebaseline is broader. It may restructure much of the remaining Performance Measurement Baseline (PMB) or establish new program cost and schedule commitments. The affected scope depends on whether the change occurs at the work package, control account, contract, or acquisition-program level.

Effect on budget

An internal replan does not create budget. It redistributes or time-phases authorized budget within the controls defined by the contractor’s system description and program procedures.

For example, an approved allocation from Management Reserve can add budget to the PMB without increasing the Contract Budget Base (CBB). Likewise, distributing Undistributed Budget assigns existing contract budget to control accounts. Neither transaction should be described as recovering an overrun.

An authorized contract change may increase or decrease the CBB when the modification changes authorized scope and budget. In contrast, an OTB adds performance budget above the CBB for management purposes. It does not, by itself, increase contract value, funding, or contractual scope.

Effect on historical variances

Routine replanning should preserve actual performance and completed-work history. Teams should not move past budget merely to hide a schedule variance or cost variance. Retroactive adjustments require strict controls and a valid reason, such as correcting an accounting error or an incorrect work assignment.

A formal rebaseline may change the presentation of historical variances. On DoD contracts containing the applicable clause, DFARS 252.234-7002 requires an OTB or OTS request to address whether performance variances will be retained. Therefore, the contractor should not decide variance treatment by simply overwriting schedule or cost-tool fields.

Approval level

A routine replan may remain within delegated program authority. For example, a CAM, program-controls lead, change board, or program manager may approve it under established thresholds.

A rebaseline usually requires higher approval because it changes a major performance reference. An OTB or OTS on a contract containing DFARS 252.234-7002 requires a request to the Contracting Officer before implementation. Agency project rebaselines may follow separate governance rules.

As a result, teams must review the contract, data-item requirements, EVMS system description, program directives, and baseline-control procedures. No universal approval path applies to every federal program.

Updating the Forecast Is Not Automatically Replanning

A common mistake is to call every schedule update a replan. During a normal status cycle, the scheduler enters actual dates, updates remaining durations, verifies logic, and calculates the current forecast. That process reveals what the team now expects to happen.

The baseline remains the approved comparison point. Therefore, a late forecast finish does not justify moving the baseline finish to match it. Doing so would erase the variance that management needs to see.

The distinction is simple:

• Current schedule: The latest execution forecast based on actual progress, remaining work, logic, and known conditions.
• Baseline schedule: The approved time-phased plan used to measure performance.
• Replan: An authorized revision to affected baseline elements, usually focused on remaining work.
• Rebaseline: A new or comprehensively revised measurement reference approved under the applicable governance process.

A disciplined IMS status process updates the forecast first. Management can then evaluate whether corrective action, replanning, or formal rebaselining is justified.

When a Replan Is Usually Appropriate

A replan may be appropriate when the current baseline remains useful overall, but the detailed plan for specific future work needs revision. Common situations include:

• Detailing a planning package through rolling-wave planning.
• Incorporating an authorized scope change.
• Revising future activity logic to reflect an approved technical approach.
• Moving future budget to match a valid change in execution sequence.
• Allocating Management Reserve for realized, in-scope risk.
• Correcting a documented planning or coding error.
• Reorganizing remaining work packages while preserving control-account objectives.

For example, converting a planning package into executable work packages is normal baseline maintenance. It does not justify rewriting completed work or eliminating unfavorable performance.

The team should also confirm that schedule and cost systems remain synchronized. A future schedule movement without corresponding budget time-phasing can create an artificial Schedule Performance Index (SPI) signal and weaken the integrity of the integrated baseline.

When Rebaselining May Be Justified

Rebaselining may be justified when the baseline no longer measures execution in a useful way. Indicators can include:

• The remaining PMB is not executable under current technical, schedule, and resource conditions.
• Large accumulated variances obscure new performance trends.
• The forecast extends materially beyond the contractual or approved completion date.
• A major restructuring changes the program’s execution strategy.
• A substantial authorized change requires a new integrated cost and schedule plan.
• The program cannot produce credible performance information against the existing baseline.

Poor performance alone does not automatically justify a rebaseline. First, management should determine whether corrective action can recover the plan. In addition, the Estimate at Completion (EAC) should remain realistic even when it exceeds the budget baseline. The purpose of the EAC is to forecast cost, not to protect the appearance of the baseline.

Likewise, a rebaseline should not serve as a periodic variance-clearing exercise. Frequent resets can indicate weak initial planning, uncontrolled scope, unrealistic commitments, or ineffective change discipline.

Fictional Example: Three Different Baseline Decisions

Assume the fictional Atlas Relay program is developing a communications payload. The contract uses an EVMS, and the Integrated Master Schedule (IMS) supports the time-phased PMB.

Scenario 1: Internal replan

A supplier qualification test finishes six weeks late. However, the team can preserve the contractual delivery date by resequencing future integration work and using an approved alternate test facility.

The program updates the current forecast and analyzes the critical path. It then processes a Baseline Change Request for the affected future work. The approved replan revises the remaining logic and budget time-phasing, while actual results and prior variances remain visible.

Scenario 2: Authorized-change replan

The customer adds a new encryption requirement through a contract modification. The change adds scope, budget, and three months to the contractual delivery date.

The program plans the new scope in the IMS and EVMS, assigns budget to the responsible control accounts, and maintains traceability to the modification. This action is external replanning because it incorporates an authorized customer change. It is not an OTB merely because the PMB increased.

Scenario 3: Formal rebaseline

Later, major technical failures drive the forecast eight months beyond the revised contract date. The remaining baseline budget is also inadequate, and accumulated variances prevent managers from identifying new deviations.

The contractor develops a realistic plan for all remaining work. If the applicable contract requirements and approval authorities support it, the contractor requests an OTB and OTS. The request addresses projected growth, variance treatment, and the implementation schedule. This is formal reprogramming and represents the broad type of action professionals often mean when they say rebaseline.

A Practical Decision Process

1. Update the current forecast. Enter status, calculate dates, validate logic, and identify the driving and near-critical paths before proposing a baseline change.
2. Define the trigger. Determine whether the issue involves normal execution, realized risk, an authorized customer change, a planning error, or an unrealistic overall baseline.
3. Identify the affected baseline. Separate work-package, control-account, PMB, contract, and acquisition-program baselines.
4. Confirm the budget source. Identify existing performance budget, Undistributed Budget, Management Reserve, authorized change budget, or proposed over-target budget.
5. Assess variance treatment. Preserve historical performance unless an approved process explicitly authorizes different treatment.
6. Obtain approval before implementation. Follow the contract, EVMS system description, change-control procedure, and agency or program governance requirements.
7. Implement schedule and cost changes together. Align dates, logic, resources, work authorization, earned value techniques, and time-phased budget.
8. Retain traceability. Archive the prior baseline, approved change documentation, reconciliation reports, and implementation evidence.
9. Validate the revised plan. Confirm that the new plan covers all scope, uses sound logic, aligns with resources, and supports credible performance measurement.

Common Failure Modes

• Overwriting the baseline to match the forecast. This removes the variance without solving the execution problem.
• Using replanning to erase poor performance. Baseline maintenance should not convert unfavorable history into favorable history.
• Calling every contract change a rebaseline. Many modifications require controlled external replanning rather than a wholesale reset.
• Moving schedule dates without budget. This disconnects the IMS from the PMB and produces misleading earned value results.
• Treating an OTB as new contract funding. An OTB is a performance-measurement action. Contract value and funding change only through the appropriate contractual processes.
• Ignoring the baseline level. A revised control-account plan does not automatically revise the contract completion date or acquisition-program baseline.
• Implementing changes before approval. Premature implementation can create reconciliation problems and undermine configuration control.

Microsoft Project Does Not Approve a Rebaseline

Microsoft Project can store the unnumbered Baseline plus Baseline1 through Baseline10. Microsoft describes these fields as snapshots used to compare the current plan with earlier plans. It also recommends considering an additional baseline rather than immediately replacing existing baseline data.

However, selecting Set Baseline is only a software operation. It does not approve a Baseline Change Request, authorize an OTB, modify a contract, or establish a new customer-approved PMB.

Before changing baseline fields, archive the schedule and record which data set represents the original plan, current approved plan, and any intermediate snapshots. Microsoft’s guidance on creating or updating Project baselines explains the available software functions, but the program’s change-control procedure must govern their use.

Bottom Line

Use a replan when authorized remaining work needs a controlled adjustment and the broader baseline still supports meaningful management. Consider a rebaseline when the approved measurement reference has become unusable and a new, integrated plan requires higher-level approval.

Most importantly, use precise terms. State whether the action is internal replanning, authorized-change replanning, formal reprogramming, an OTB, an OTS, or a change to another program baseline. That precision protects historical visibility, preserves accountability, and helps the schedule and EVMS continue to support real management decisions.