A schedule changes PMB dates, logic, or time-phased budget only when the program approves a corresponding baseline change. Routine status updates and forecast revisions may move current dates, change float, or expose a new critical path. However, they should not automatically rewrite the Performance Measurement Baseline (PMB).
That distinction protects the integrity of earned value data. If a supplier finishes late, the Integrated Master Schedule (IMS) should show the delay and its downstream effects. The baseline normally remains unchanged so the program can measure performance against the approved plan. By contrast, authorized scope changes, approved internal replanning, and formal reprogramming can justify changes to the PMB.
Current schedule changes and PMB changes are not the same
The IMS usually contains both current and baseline information. The current schedule represents actual progress and the latest forecast. The baseline schedule preserves the approved plan used to time-phase budget and measure performance.
Therefore, a normal status cycle can change the current schedule without changing the PMB. For example, the scheduler may record actual dates, revise remaining durations, update forecast dates, or calculate a new critical path. These actions reveal performance. They do not authorize the team to replace the plan against which performance is measured.
This separation is central to the relationship between the IMS and earned value management. The schedule provides the timing and sequencing of work, while the PMB integrates authorized scope, schedule, and time-phased budget.
Changes that usually do not alter the PMB
- Recording actual starts and finishes
- Updating remaining durations based on current conditions
- Forecasting late completion of an in-progress activity
- Allowing network logic to calculate revised downstream dates
- Updating expected delivery dates that have not been contractually changed
- Developing a recovery schedule for management analysis
- Identifying a new critical or near-critical path
These changes may create or increase schedule variance, negative float, or milestone delay. That is the intended result. The current schedule should show the program’s latest forecast, even when the forecast differs substantially from the baseline.
Changes that may alter the PMB
- Authorized additions or deletions of contract scope
- Approved planning of authorized unpriced work
- Approved conversion of planning packages into detailed work packages
- Approved internal replanning of remaining work
- Approved use of Management Reserve for realized, in-scope risk work
- Approved correction of a material planning error
- Formal implementation of an Over Target Baseline or Over Target Schedule
Each action requires the approval, documentation, and reconciliation defined by the contract and the contractor’s approved Earned Value Management System (EVMS) description. The organization may call the approval document a Baseline Change Request, Budget Change Request, change package, or another controlled term.
How schedule changes affect PMB dates and planned value
An approved schedule baseline change can affect more than activity dates. Because the PMB is time-phased, changing the planned timing of work can move Planned Value (PV), formerly called Budgeted Cost for Work Scheduled (BCWS), from one accounting period to another.
Suppose a future work package has a budget of $600,000 spread from January through June. An approved replan moves the work from April through September. The total work package budget may remain $600,000, but its monthly planned value changes. As a result, the control account and contract-level PMB profiles also change.
The approved change may affect:
- Baseline start and finish dates: Work package dates may move to align with the revised execution plan.
- Baseline logic: New or revised relationships may change the planned sequence of work.
- Time-phased budget: Planned value may move between accounting periods.
- Control account dates: The earliest and latest work package dates may change control account boundaries.
- Milestone alignment: Baseline activities may need to align with authorized contractual or program milestones.
- Variance calculations: Future schedule variance will be measured against the revised planned value profile after implementation.
However, moving budget into future periods does not erase past performance problems. Earned value schedule variance equals Earned Value minus Planned Value. It is a monetary measure, not the number of calendar days late. The difference is explained further in Schedule Variance vs Cost Variance.
Choose the right treatment for the change
Before editing baseline fields, identify why the schedule changed. The cause determines whether the team should update only the forecast, process a baseline change, or pursue a contract action.
1. Performance caused the forecast to slip
Do not replan merely because work finished late or productivity fell below plan. Instead, update the current schedule and preserve the baseline. The resulting variance provides management insight into the consequences of execution.
A recovery plan may revise future sequencing, resources, or work methods. However, the recovery forecast does not become the PMB unless the program separately approves an eligible baseline change.
2. The customer authorized new or revised scope
Authorized scope changes normally require coordinated updates to scope documentation, the IMS, budgets, work authorization, and the EVMS cost tool. The timing and approval path depend on the contract, agency procedures, and whether the change has been negotiated.
The Department of Energy EVMS Interpretation Handbook describes a disciplined process for incorporating authorized changes and reconciling current budgets to prior budgets. Although its detailed evaluation methods are DOE-specific, the broader principle applies across disciplined EVMS environments: authorized scope, schedule, and budget changes must remain synchronized and traceable.
3. Remaining work needs internal replanning
Internal replanning realigns remaining scope, schedule, and budget without changing the Contract Budget Base. It may be appropriate when the original approach to future work is no longer executable, but the underlying authorized scope remains the same.
Internal replanning should not replace sound initial planning or conceal poor performance. It must follow the contractor’s approved change-control process. For a fuller distinction, see Replanning vs Rebaselining.
4. The PMB no longer provides meaningful control
Severe cost or schedule conditions may lead management to consider an Over Target Baseline (OTB), an Over Target Schedule (OTS), or both. Formal reprogramming is not a routine scheduler action.
For DoD contracts containing DFARS 252.234-7002, the contractor must request approval before initiating an OTB or OTS. The clause also requires the request to address projected growth, variance treatment, and the implementation schedule. An OTB or OTS changes the management baseline, but it does not by itself change the contract’s terms, price, or required delivery dates.
A practical schedule changes PMB workflow
The following workflow keeps the IMS, cost system, and authorization records aligned. Specific approval levels and timing rules vary by contract and organization.
- Classify the change. Determine whether it results from performance, authorized scope, internal replanning, a planning-package conversion, error correction, or formal reprogramming.
- Confirm authority. Review the contract, EVMS system description, change-control procedure, and applicable program direction. A scheduler’s ability to edit a field is not authority to change the baseline.
- Define the before-and-after condition. Identify affected activities, milestones, logic, baseline dates, work packages, control accounts, budgets, earned value techniques, and work authorization documents.
- Analyze integrated effects. Calculate impacts on the critical path, float, contractual milestones, resource requirements, planned value, undistributed budget, Management Reserve, and the Estimate at Completion.
- Obtain approval before implementation. Route the change through the required Control Account Manager, program manager, change board, contracts, and customer approvals.
- Implement the same approved change across systems. Update the baseline IMS, EVMS cost tool, work authorization documents, budget logs, and related source records in a controlled sequence.
- Validate reconciliation. Confirm that schedule dates and budget time-phasing match the approved package. Also verify that control account totals, PMB totals, undistributed budget, Management Reserve, and the Contract Budget Base reconcile.
- Report the change. Explain material changes in the required customer deliverables and internal reports. The narrative should identify the reason, authorization, timing, and performance impact.
The federal FAR 34.202 Integrated Baseline Review guidance emphasizes the relationship among scope, schedule, budget resources, risk, and baseline control. However, the contract and agency procedures determine the specific contractual requirements for a given program.
Fictional example: supplier delay versus authorized change
Consider the fictional Atlas Sensor Upgrade program. The baseline schedules environmental qualification testing for May, followed by system verification in June. The supplier then delivers a test article six weeks late.
First, the scheduler records the supplier delay and recalculates the network. Environmental testing moves into June, system verification moves into July, and the delivery milestone develops negative float. The PMB does not change. The program reports the variance and evaluates recovery options.
Next, the customer directs the program to add a new electromagnetic compatibility test that was not in the original control account scope. Contracts confirms the authorization, and the program estimates the required work. After approval, the team adds the new schedule activities and logic, assigns budget, updates work authorization, and incorporates the change into the PMB.
Finally, engineering proposes running two existing tests in parallel to recover three weeks. The scheduler models that approach in the current forecast. The team does not automatically revise the PMB because the recovery logic changed. If management later approves eligible replanning of future work, the team processes that decision through formal change control.
Applying approved changes in Microsoft Project and Cobra
Software can implement a baseline change, but it cannot determine whether the change is authorized. That decision belongs to the program’s governance process.
Microsoft Project supports updating baseline data for selected tasks or the entire project. It also provides options for rolling revised baseline data into summary tasks. Before overwriting baseline fields, preserve the prior configuration and verify the exact task selection, summary rollup settings, calendars, logic, resources, and time-phased values.
Do not treat Microsoft Project’s numbered baselines as automatic approval states. Programs should define which fields represent the contractual or performance baseline, which preserve historical snapshots, and who has permission to change them.
Similarly, Deltek Cobra’s schedule integration change-control options can update control account and work package baseline dates from the schedule. Configuration choices can also affect how historical budget changes are processed. Therefore, test the integration, review the process log, and reconcile the results before completing the accounting-period close.
Common baseline change failures
- Rebaselining every delay: Replacing the baseline whenever the forecast slips removes the evidence of performance variance.
- Implementing before approval: Editing baseline dates while the change request remains in review creates an unauthorized baseline.
- Updating only the IMS: Schedule dates may no longer match budget time-phasing, control account plans, or work authorization.
- Updating only the cost tool: Planned value changes while the IMS continues to show obsolete baseline dates and logic.
- Changing history to improve metrics: Retroactive changes can distort previously reported performance and should remain tightly controlled. See Retroactive Changes to the Performance Measurement Baseline.
- Moving contractual milestones without contract authority: An internal baseline change does not automatically revise a contract delivery date.
- Ignoring downstream logic: A local work package change may alter interfaces, critical paths, resources, or milestones outside the originating control account.
- Using Management Reserve to erase variance: Management Reserve addresses eligible in-scope risk work. It is not a pool for eliminating unfavorable performance.
Frequently asked questions
Does every IMS date change require a baseline change request?
No. Actual progress and forecast updates normally change the current schedule without changing the baseline. A change request becomes necessary when the team proposes to revise controlled baseline dates, logic, scope, or time-phased budget.
Can the program move a baseline milestone without changing its budget?
Possibly, but the move still requires the approval and documentation defined by the EVMS process. The team must also evaluate whether moving the milestone changes work package dates, planned value, logic, contractual commitments, or downstream control accounts.
Should an approved baseline change remove existing variances?
Normally, no. Approved changes should preserve visibility into actual performance unless a specifically authorized correction or formal reprogramming action permits different treatment. Variance removal should never occur solely to improve reported metrics.
The practical rule
Use the current schedule to tell management where the program is going. Use the PMB to show the approved plan against which performance is measured. Change the PMB only when the underlying scope, schedule, or budget plan has an authorized reason to change.
When a PMB change is justified, process it as an integrated configuration change. Document the before-and-after condition, obtain the required approval, update every affected system, and reconcile the result. That discipline keeps schedule changes from becoming uncontrolled baseline changes and preserves confidence in the program’s performance data.