A baseline change request is a formal document used to propose, evaluate and approve a change to an established project baseline. In an Earned Value Management System (EVMS), the request typically identifies the affected scope, schedule and budget, explains why the change is necessary and shows the baseline before and after the proposed adjustment.
Approval of the request authorizes the project team to revise controlled baseline data. It does not, by itself, authorize new contractual work. A contract modification, direction from the contracting officer or another valid work authorization must support any externally directed change.
Organizations use several names for this document. Baseline Change Request, Budget Change Request and Baseline Change Proposal may all appear as BCR or BCP. The terminology and approval thresholds depend on the contractor’s EVMS description, agency procedures, contract requirements and program governance.
What Does a Baseline Change Request Control?
A BCR protects the integrity of the approved plan used to measure performance. For an EVMS program, that plan is the Performance Measurement Baseline (PMB), which integrates authorized scope, schedule and time-phased budget.
A baseline change may affect one or more of the following:
- Work Breakdown Structure (WBS) elements and scope descriptions
- Control accounts, work packages or planning packages
- Baseline activity dates, durations, logic or milestones in the Integrated Master Schedule (IMS)
- Time-phased planned value
- Control account budgets and Budget at Completion (BAC)
- Undistributed Budget (UB) or Management Reserve (MR)
- Work authorization documents and responsibility assignments
- Earned value techniques or objective completion criteria
The BCR creates an audit trail between the previous baseline and the revised baseline. The Department of Energy’s EVMS Interpretation Handbook, for example, describes the need for supporting detail that shows current and proposed time-phased budgets by control account. It also emphasizes traceability and a clear before-and-after presentation.
A BCR Is Not a Routine Forecast Update
The distinction between baseline and forecast data is essential. The baseline represents the approved performance plan. The forecast represents management’s current expectation for how the remaining work will occur.
Schedulers update forecast dates as progress, risks and execution conditions change. They should not move baseline dates simply because an activity is late or the current plan has changed. Doing so would reduce or erase schedule variance without addressing the underlying performance problem.
For example, suppose a baseline activity should finish on June 10, but the current forecast finish is July 1. The scheduler should retain June 10 as the baseline finish unless an authorized and approved baseline change applies. July 1 remains the forecast finish and preserves visibility into the delay.
This separation allows managers to understand both the original commitment and the latest execution outlook. It also supports credible schedule and cost variance analysis.
When Is a Baseline Change Request Appropriate?
Valid reasons for a baseline change commonly include authorized contract changes, internal replanning permitted by the approved EVMS process, distribution of UB, authorized use of MR and formal reprogramming. However, each program must follow its own documented rules.
Authorized contractual change
A contract modification may add, delete or revise scope. After authorization, the program uses its baseline change process to incorporate the impact into the WBS, IMS, budgets and work authorization documents.
Work may initially reside in Undistributed Budget until the team completes detailed planning. A later BCR can distribute that budget to the affected control accounts and work packages.
Internal replanning
Internal replanning may address future work that no longer reflects an executable approach. For example, the team might revise the sequence of unopened work packages after selecting a different manufacturing method.
Internal replanning does not provide authority to change contractual scope, increase the Contract Budget Base or conceal unfavorable performance. The contractor’s EVMS description should define restrictions, approval levels and any freeze-period rules.
Use of management reserve
Management may approve the use of Management Reserve for realized, in-scope risks that were not included in the distributed baseline budget. The associated BCR should identify the risk event, affected control account, added budget and revised schedule plan.
Management Reserve is not a source of funding or fee. It is budget held outside the PMB for management control of in-scope uncertainty.
Formal reprogramming
A program may need an Over Target Baseline (OTB) or Over Target Schedule (OTS) when the existing baseline no longer provides a realistic basis for managing the remaining work. This is more significant than routine internal replanning.
The current DFARS 252.234-7002 Earned Value Management System clause requires a contractor to request contracting officer approval before initiating an OTB or OTS when the clause applies. Therefore, an internal BCR cannot substitute for required customer approval.
Correction of an error
A controlled correction may be necessary when the team discovers a data-entry, coding, time-phasing or accounting error. However, retroactive changes require particular scrutiny because they can alter previously reported planned value, earned value or actual cost.
The justification should identify the error, periods affected and impact on prior reporting. It should also show that the adjustment follows the contractor’s approved process. A BCR should never become a convenient way to rewrite unfavorable history.
What Should a Baseline Change Request Include?
The exact form varies, but a useful BCR gives reviewers enough information to understand, approve and verify the proposed change. It should include more than a short statement such as “update schedule to current plan.”
A strong BCR normally contains:
- Identification: A unique BCR number, title, originator, date, status and requested implementation period.
- Change category: Contract modification, internal replanning, UB distribution, MR use, error correction or formal reprogramming.
- Authority: The contract modification, internal decision, risk authorization or other basis for the change.
- Rationale: A specific explanation of why the current baseline requires adjustment.
- Scope impact: Affected WBS elements, control accounts, work packages, planning packages and work authorization documents.
- Schedule impact: Added or deleted activities, revised logic, baseline dates, durations, constraints, milestones and critical or near-critical path effects.
- Budget impact: Before-and-after budgets, time phasing, elements of cost and changes to BAC, UB or MR.
- Performance impact: Treatment of completed work, actual costs, earned value, existing variances and estimate-to-complete assumptions.
- Implementation instructions: Systems, schedules, logs and documents that require updates.
- Approvals: Signatures or electronic approval from the designated authorities.
The change should also identify what does not change. For example, a BCR may revise the timing of future work while leaving total control account budget unchanged.
How the BCR Process Works
- Identify the need. The Control Account Manager (CAM), scheduler, business manager or program manager identifies a valid basis for changing the baseline.
- Analyze the impact. The team develops a what-if schedule and evaluates scope, logic, resources, budget, risk and downstream milestone effects.
- Prepare the request. The originator documents the current baseline, proposed baseline, authority, rationale and implementation details.
- Conduct functional reviews. Scheduling, finance, contracts, engineering and program management review the portions within their responsibility.
- Obtain approval. The designated Change Control Board or approving manager accepts, rejects or returns the request for revision.
- Implement the approved change. The team updates the IMS, EVMS cost tool, work authorization documents, logs and related baseline artifacts.
- Validate and reconcile. Program controls confirms that every implemented value agrees with the approved BCR and that PMB, MR, UB and Contract Budget Base totals reconcile.
- Report and archive. The program reflects significant changes in applicable customer reporting and retains the request with its supporting analysis.
Approval should precede implementation. Otherwise, the schedule or cost system may contain a baseline that management never authorized.
Fictional Example: Adding Qualification Testing
Assume the fictional Northstar Sensor Upgrade program receives a contract modification that adds environmental qualification testing. The modification provides additional target cost and extends a contractual delivery milestone by 20 working days.
The program first places the new budget in UB. The planning team then develops the detailed scope and adds test procedure development, chamber preparation, test execution and report approval activities to the IMS. The scheduler links the new activities into the existing integration and delivery sequence.
The BCR identifies the affected WBS elements and control accounts. It also shows the original and revised milestone dates, new logic, resource assignments and time-phased budget. In addition, it documents the transfer from UB into the applicable control accounts.
After approval, program controls updates the baseline IMS, cost tool, work authorization documents, UB log and reporting data in the same accounting period. Finally, the team compares the implemented values against the approved request.
The contract modification authorized the new work. The BCR did not create that authority; instead, it controlled how the program incorporated the authorized change into the integrated baseline.
Practical Guidance for Schedulers
The scheduler should treat the BCR as more than a signature form. Schedule analysis often reveals impacts that budget-only reviews miss.
Before approval, compare the proposed schedule with the current baseline and forecast. Review changes to driving logic, critical and near-critical paths, total float, constraints, calendars, activity coding and contractual milestones. Also confirm that added work fits within the authorized scope and period of performance.
After approval, update only the authorized activities and fields. Microsoft Project allows users to update baseline data for selected tasks or the entire project. However, the software function does not provide change-control authority. The project should first approve the BCR and define which tasks require new baseline values. Microsoft’s baseline update guidance for Project desktop explains the selected-task and summary roll-up options.
Before changing an operational file, retain a controlled copy of the prior schedule. Then verify summary roll-ups and compare the revised file with the approved what-if model. If the scheduling environment supports activity-level change coding, record the BCR number on affected activities to improve traceability.
Common Baseline Change Failure Modes
- Using a BCR to eliminate variance: Poor performance alone does not justify moving the baseline to the current forecast.
- Implementing before approval: An unapproved baseline update breaks configuration control and may create reporting discrepancies.
- Treating the BCR as work authorization: Internal approval cannot authorize out-of-scope contractual effort.
- Updating only the schedule: The IMS, budget tool, work authorization documents and logs must remain integrated.
- Providing no before-and-after detail: Reviewers cannot evaluate a change if the request only describes the desired end state.
- Changing historical data without justification: Retroactive changes can undermine previously reported performance and trend analysis.
- Ignoring downstream logic: A local date change may affect external dependencies, contractual milestones or the critical path.
- Resetting the entire schedule unnecessarily: Updating every baseline field can overwrite unaffected commitments and destroy traceability.
Contractual Requirements Versus Program Practice
No universal FAR or DFARS rule requires every contractor to use a form specifically named “Baseline Change Request.” The required process and terminology may come from the contract, the contractor’s approved EVMS description, agency direction or internal governance.
Likewise, a routine baseline transaction is not the same as a substantive change to the contractor’s EVMS procedures. DFARS 252.234-7002 contains notification and approval provisions for proposed substantive EVMS procedure changes when applicable. Those provisions should not be interpreted as requiring cognizant federal agency approval for every internal BCR.
Agency terminology also differs. The Department of Energy’s Project Management Lexicon, for example, defines a Budget Change Request as an internal adjustment that does not change specified top-level project baseline parameters. NASA’s program planning and control glossary describes a Change Control Board as the body that decides whether proposed technical, schedule or cost baseline changes should be accepted.
Therefore, practitioners should review the contract, EVMS description, program management plan and change-control procedure before deciding which approvals apply.
Frequently Asked Questions
Does every schedule change require a BCR?
No. Current and forecast schedule dates change as the team records progress and revises its execution outlook. A BCR applies when the program proposes changing controlled baseline data. The approved process should define any additional thresholds.
Can a BCR change the Budget at Completion?
Yes, if authorized budget enters or leaves the affected control account or work package. However, an internal BCR cannot increase the total Contract Budget Base without valid contractual or formal reprogramming authority.
Can a BCR change completed work?
Only under tightly controlled circumstances, such as correcting an error or implementing another permitted retroactive adjustment. The request should explain the impact on previously reported planned value, earned value and actual cost.
Who approves a baseline change request?
The approving authority varies. It may include the CAM, program manager, business manager, contracts representative or a formal Change Control Board. Customer approval may also apply to contract changes, OTB or OTS actions and other changes defined by the contract or agency procedures.
Why does baseline change control matter?
Without disciplined change control, the program loses a stable point of comparison. As a result, managers cannot tell whether performance changed or the team merely changed the plan. A well-supported BCR preserves that distinction while keeping the baseline aligned with authorized work.