PROJECT PLANNING & SCHEDULING GUIDE
How to Manage Schedule Baseline Changes
Managing schedule baseline changes requires more than updating dates in a project schedule. This guide provides a practical approach to identify and assess changes, evaluate recovery options, determine when rebaselining is justified, obtain formal approval, preserve historical performance, and maintain effective schedule control.
Practical Guide · Project Management
The Schedule Baseline Change Challenge
Why Schedule Baseline Changes Go Wrong
Schedule baseline changes rarely fail because of the technical process of changing dates. The real problems usually come from weak change assessment, incomplete schedule analysis, poor governance, and pressure to reset project expectations.
1. Treating Every Delay as a Baseline Change
A delay does not automatically justify changing the baseline.
First identify the cause:
- Poor productivity
- Resource shortages
- Late decisions
- Contractor performance
- Weak planning
These may require corrective or recovery action, rather than rebaselining.
2. Starting With an Unrealistic Baseline
Some baselines are built using:
- Optimistic durations
- Incomplete scope
- Unsupported productivity rates
- Insufficient resources
- Aggressive completion targets
When these assumptions fail, rebaselining may be used to reset expectations.
The team should distinguish between a genuine project change and a weakness that existed in the original baseline.
3. Changing the Baseline Before Understanding the Impact
A single change can affect several parts of the schedule.
For example:
Design change → Procurement → Fabrication → Installation → Testing
Changing dates before analysing these relationships can produce an unreliable revised baseline.
The team should assess the complete schedule network before making the baseline decision.
4. Confusing Forecast With Baseline
The forecast shows what the project currently expects to achieve.
The baseline represents the approved performance reference.
If the forecast moves from December to March, the baseline should not automatically move to March.
First determine:
- Why did the forecast change?
- What caused the variance?
- Can recovery still be achieved?
- Is the existing baseline still meaningful?
5. Using Rebaselining to Reset Performance
Rebaselining can unintentionally make poor performance appear acceptable.
For example:
Original baseline: December
Current forecast: March
New baseline: March
The three-month delay has not been recovered.
Only the performance reference has moved.
The original baseline should therefore remain available for historical performance measurement.
6. Weak Change Governance
Without clear governance, similar changes may be handled differently across projects.
The project should define:
- When rebaselining is permitted
- Required supporting evidence
- Approval authority
- Review requirements
- Documentation requirements
- Baseline version control
This makes the process consistent, transparent, and auditable.
7. Ignoring Recovery Options
Before changing the baseline, assess whether the project can recover through:
- Resequencing
- Additional resources
- Overtime
- Acceleration
- Parallel working
- Procurement expediting
- Productivity improvement
Rebaselining should not become the first response to schedule pressure.
Reasonable recovery opportunities should be evaluated first.
8. Failing to Assess the Critical Path
The impact of a change cannot always be measured by simply adding days to an activity.
The team should examine:
- Critical path
- Near-critical paths
- Total float
- Logic relationships
- Milestones
- Downstream dependencies
This determines whether the change actually affects the project’s completion date.
9. Disconnecting Change Control From Schedule Control
Engineering, commercial, procurement, risk, and planning teams may manage changes separately.
This can leave planners without complete information about:
- Approved scope
- Effective dates
- Quantities
- Contract requirements
- Resource implications
- Execution requirements
Schedule changes should therefore be integrated with the project’s wider change-control process.
10. Overwriting the Previous Baseline
Replacing the original baseline with a revised version removes valuable project history.
Maintain controlled records of:
Original Baseline → Revised Baseline → Current Forecast → Actual Performance
This allows the team to understand:
- What changed
- When it changed
- Why it changed
- Who approved it
- How performance evolved
The Underlying Problem
What Should You Do?
Managing a schedule baseline change requires a controlled process rather than simply moving project dates.
The following eight steps help the planning team identify the change, assess its impact, evaluate recovery options, determine whether rebaselining is justified, validate the revised schedule, obtain approval, preserve historical baselines, and continue monitoring performance against the new reference.
1. Establish Baseline Change Rules
Before project changes occur, establish clear rules for when a schedule baseline can be changed. This prevents the planning team from making ad-hoc decisions when schedule pressure increases.
The rules should define:
- What qualifies as a baseline change
- What evidence must be provided
- Who can request the change
- Who has approval authority
- What level of impact requires escalation
- How the previous baseline will be preserved
Not every delay, forecast movement, or schedule update should trigger rebaselining.
For example, a short-term productivity issue may require recovery action rather than a new baseline. An approved scope change that materially affects the remaining work may require formal baseline review.
The project should also establish whether different types of changes require different levels of approval.
Most importantly, the criteria should be agreed before the project encounters significant schedule pressure.
A clear baseline-change framework gives the planning team a consistent decision process and protects the integrity of the project performance record.
2. Identify and Classify Changes
Once a potential baseline change is identified, the planning team should first establish what has changed and why. The team should not immediately modify schedule dates.
Record the source and nature of the change, such as:
- Approved scope change
- Client instruction
- Design development
- Contract variation
- Regulatory requirement
- Procurement issue
- Resource change
- External event
- Contractor performance
- Planning error
This classification helps determine whether the issue represents a legitimate change to the project plan or a variance against the existing plan.
For example, an approved addition to the project scope may require schedule re-planning. However, poor productivity on an unchanged scope may require corrective action instead.
The team should also identify the affected WBS elements, activities, milestones, contracts, interfaces, and responsible parties.
A well-documented change record creates a clear starting point for impact analysis.
The key principle is simple:
“Understand and classify the change before deciding whether the baseline should change.”
3. Assess Schedule Impact
4. Evaluate Recovery Options
Before changing the schedule baseline, determine whether the project can reasonably recover within the existing approved plan. Rebaselining should not become the automatic response whenever the forecast moves beyond the baseline date.
The planning team should evaluate practical recovery measures such as:
- Resequencing activities
- Increasing resources
- Adding shifts or overtime
- Accelerating procurement
- Improving productivity
- Parallel execution
- Changing construction methods
- Removing unnecessary constraints
Each recovery option should be tested against cost, resources, safety, quality, contractual requirements, and technical feasibility.
The team should also determine whether the proposed recovery is supported by realistic assumptions. Simply shortening activity durations to achieve the original completion date does not constitute a credible recovery plan.
For significant delays, compare the recovery scenarios against the current schedule and identify their effect on the critical path, milestones, resources, and project completion.
The key question is:
“Can the project realistically recover without changing the approved baseline?”
If recovery is achievable, manage the variance through corrective action. If it is not, proceed to determine whether formal rebaselining is justified.
5. Determine Whether Rebaselining Is Justified
6. Develop and Validate the Revised Baseline
If rebaselining is justified, develop a new, evidence-based baseline for the remaining project work. Do not simply move the completion date or extend selected activity durations to match a desired target.
Rebuild and review the affected schedule elements, including:
- Remaining scope and WBS
- Activities and durations
- Logic relationships
- Resources and calendars
- Key milestones
- Procurement requirements
- Constraints and interfaces
- Critical and near-critical paths
- Schedule risks and assumptions
The revised baseline should reflect the current project reality and the approved changes.
Where possible, validate important durations using quantities, productivity data, historical performance, supplier information, contractor input, or other reliable evidence.
The planning team should then conduct a cross-functional review with relevant stakeholders, such as engineering, procurement, construction, commercial, project controls, and commissioning.
Challenge the revised schedule before approval:
“Is this plan achievable with the available scope, resources, time, logic, and execution conditions?”
Validation should confirm that the revised baseline is not simply more convenient—it is credible, internally consistent, and achievable.
7. Approve and Document the Change
Once the revised baseline has been developed and validated, it should go through the project’s formal change-control and approval process.
The change request should clearly document:
- Reason for the baseline change
- Source and nature of the change
- Affected scope
- Schedule impact
- Recovery options considered
- Key assumptions and constraints
- Revised completion dates
- Approval authority
- Effective date
- New baseline version
The appropriate stakeholders should review the proposal before approval. Depending on the project, this may include the Project Manager, Project Controls Manager, Commercial Manager, Client, Change Control Board, or senior management.
Approval should confirm that the revised baseline represents an authorized change to the project plan, rather than simply a revised forecast.
Maintain a clear audit trail showing what was approved, when it was approved, and why the change was necessary.
Once formally approved, establish the revised schedule as the new controlled baseline.
“A baseline change is not complete when the schedule is updated. It is complete when the revised plan is formally approved, documented, and placed under configuration control.”
8. Preserve History and Monitor
After the revised baseline is approved, do not replace or delete the original baseline. Preserve each approved baseline version so the project can maintain a clear history of how its plan evolved.
Maintain controlled records of:
- Original baseline
- Approved revised baselines
- Current control schedule
- Actual progress
- Current forecast
The planning team should also document the reason, date, scope, and approval associated with each baseline revision.
After implementation, continue monitoring the revised baseline against actual performance. Reassess the critical path, float, milestones, risks, and forecast completion as the project progresses.
The new baseline should become a reliable reference for measuring performance, not another temporary target.
If further changes occur, apply the same controlled process rather than repeatedly modifying the schedule without proper analysis.
The objective is to maintain both historical transparency and forward-looking control.
“A revised baseline establishes a new performance reference; it does not erase the project’s previous performance history.”
This allows the project team to understand not only where the project is now, but how and why the approved plan changed over time.
Practical Example
Putting the Approach Into Practice
Common Mistakes to Avoid
Managing schedule baseline changes requires more than updating dates in scheduling software. Weak change assessment, poor governance, inadequate impact analysis, and loss of baseline history can reduce the credibility of project controls.
Treating Every Delay as a Baseline Change
Not every delay justifies rebaselining. Productivity problems, poor planning, resource shortages, or contractor underperformance may require corrective action instead.
First determine the cause of the variance and assess whether the project itself has materially changed. Rebaseline only when the existing baseline is no longer an appropriate reference.
Changing the Baseline Before Assessing Impact
Moving dates before analysing the schedule can hide the actual consequences of a change.
Assess affected activities, logic, float, critical paths, milestones, resources, and downstream dependencies before deciding whether a baseline change is necessary.
Using Rebaselining to Hide Poor Performance
Rebaselining should not be used to make historical delays disappear.
If the project is behind because planned productivity was not achieved, changing the baseline does not correct the underlying performance problem. Preserve the original baseline and clearly distinguish performance variance from approved project change.
Starting With the Desired Completion Date
Forcing the revised schedule to achieve a preferred completion date can create unrealistic durations, excessive resources, or artificial logic.
Develop the revised baseline from the approved scope, actual project conditions, realistic resources, credible durations, and logical sequencing rather than working backwards from an unsupported target.
Ignoring Recovery Options
Rebaselining should not automatically become the first response to schedule pressure.
Before changing the baseline, evaluate realistic recovery measures such as resequencing, additional resources, procurement expediting, parallel working, overtime, or productivity improvements.
Document the options considered and explain why they can or cannot recover the delay.
Failing to Connect Changes to the Schedule
A change request may describe scope, cost, or contractual impacts without clearly demonstrating its schedule consequences.
Connect the change to the affected WBS elements, activities, milestones, logic, resources, and completion dates so that the baseline decision is supported by schedule evidence.
Confusing the Forecast With the Baseline
The current forecast represents what the project expects to achieve. The baseline represents the approved performance reference.
A forecast moving from December to March does not automatically mean the baseline should move to March.
Keep the two concepts separate and use variance analysis to understand why the forecast has changed.
Overlooking Critical and Near-Critical Paths
A baseline change can affect more than the final completion milestone.
Review changes to the critical path, near-critical paths, float, key interfaces, and major milestones. A seemingly local change may create new schedule drivers elsewhere in the project.
Making Changes Without Cross-Functional Review
Planning teams may understand schedule impacts but lack complete information about engineering, procurement, construction, commercial, or contractual implications.
Involve the relevant functions before approving significant baseline changes. Their input can identify impacts, constraints, and recovery opportunities that are not visible in the schedule alone.
Failing to Document the Justification
A revised baseline without a clear explanation creates questions later about why the project dates changed.
Document the cause, evidence, schedule impact, recovery assessment, assumptions, approvals, effective date, and revised baseline version.
This creates an auditable record of the decision.
Overwriting the Previous Baseline
Replacing the original baseline with the revised schedule destroys valuable performance history.
Maintain controlled versions of the original and subsequent approved baselines. This allows the project team to distinguish between original commitments, approved changes, actual performance, and current expectations.
Failing to Revalidate After the Change
Key Takeaways
Effective schedule baseline management is more than changing project dates after a delay. It provides a controlled and evidence-based process for assessing changes, protecting baseline integrity, and maintaining reliable project performance information.
- Establish clear baseline-change rules. Define what constitutes a legitimate baseline change, required evidence, approval authority, and documentation requirements.
- Identify and classify the change. Understand whether the issue results from approved scope, external events, execution conditions, performance problems, or other project circumstances.
- Assess the full schedule impact. Review affected activities, logic, float, critical paths, milestones, resources, dependencies, and project completion.
- Evaluate recovery options first. Consider resequencing, additional resources, expediting, productivity improvements, and other practical measures before recommending rebaselining.
- Determine whether rebaselining is justified. A delay or poor performance does not automatically justify changing the approved baseline.
- Develop a credible revised baseline. Base the revised plan on approved changes, realistic durations, resources, logic, constraints, and current execution conditions.
- Validate the revised plan. Involve project controls, engineering, procurement, construction, commissioning, commercial, and other relevant stakeholders.
- Obtain formal approval. Document the reason, impact, assumptions, recovery assessment, revised dates, approvals, and effective baseline version.
- Preserve baseline history. Never overwrite previous approved baselines. Maintain version-controlled records to distinguish original commitments, approved changes, actual performance, and current forecasts.
- Continue monitoring after rebaselining. The revised baseline should remain a controlled reference for measuring performance, forecasting completion, identifying further changes, and managing project risks.
A baseline change should reflect an approved change to the project plan, not simply a convenient adjustment to reported performance.
References
- AACE International — Schedule Change Management: As Applied in Construction (Recommended Practice 109R-19)
- NASA — NASA Schedule Management Handbook (NASA/SP-2010-3403)
- U.S. GAO — Schedule Assessment Guide: Best Practices for Project Schedules
- U.S. GAO — Global Positioning System: Updated Schedule Assessment Could Help Decision Makers Address Likely Delays Related to New Ground Control System
- U.S. GAO — Infrastructure Projects: Actions Needed to Fully Develop Performance Schedules for Environmental Reviews
- U.S. GAO — Financial Management Systems: DHS’s Modernization Plans Should Fully Incorporate Key Practices
- U.S. Environmental Protection Agency — Project Schedule and Cost Baseline Procedure Guide
- SLAC National Accelerator Laboratory — LCLS Earned Value Management System Description
- AACE International — Original Baseline Schedule Review: As Applied in Engineering, Procurement, and Construction (Recommended Practice 78R-13)
- Herroelen & Leus — The Construction of Stable Project Baseline Schedules, European Journal of Operational Research
- Cheng et al. — Risk Propagation Model and Simulation of Schedule Change in Construction Projects: A Complex Network Approach
- AACE International — Getting Back to Basics: Update Schedule Review by the Numbers
FEATURED PROJECT PLANNING & SCHEDULING GUIDES
Practical Guidance for Planning, Scheduling, and Schedule Control
Effective project planning and scheduling requires more than creating activities and assigning dates. Our featured guides focus on practical planning and scheduling activities, helping professionals structure projects, establish sound planning foundations, review schedules, and maintain schedule control.
How to Identify Schedule Constraints
Learn how to identify conditions that restrict planned activities, document their effects, assess their implications, and manage constraints throughout project delivery.
How to Develop a Project Plan
Learn how to structure a project plan, define the planning approach, establish key project information, and create a practical foundation for project delivery.
How to Develop a Work Breakdown Structure (WBS)
Learn how to break project scope into manageable deliverables and work packages, creating a structured foundation for activity planning and scheduling.
MORE PROJECT PLANNING & SCHEDULING RESOURCE TYPES
Continue Your Project Planning & Scheduling Learning
Project planning and scheduling knowledge becomes more valuable when you can understand the concepts, apply structured approaches, and develop practical skills. Explore the other resources within the Project Planning & Scheduling collection to complement the guidance provided in these guides.
Templates
Use practical templates and checklists to organize planning information, document scheduling decisions, review schedules, and support schedule control activities.
Downloads
Access useful planning and scheduling materials and reference resources to support learning and day-to-day project planning and controls activities.
Career Roadmaps
Follow structured learning paths to develop project planning, scheduling, and project controls knowledge, practical skills, and professional capabilities.
Case Studies
Explore planning and scheduling situations, decisions, challenges, and outcomes to understand how planning and scheduling practices are applied in real projects.
Glossary
Find clear explanations of project planning, scheduling, project controls, schedule management, and related professional terminology.
Insights & Articles
Explore professional perspectives, practical insights, emerging practices, and deeper discussions relevant to project planning, scheduling, and project controls.
Looking for more project management resources? Explore the Kleios Technologies Resources Hub to discover our complete collection of guides, templates, downloads, career roadmaps, case studies, glossary resources, and insights.
RELATED KNOWLEDGE DOMAINS
Continue Your Learning Across Related Knowledge Domains
Project Management is closely connected with specialized disciplines that support successful planning, execution, governance, performance measurement, and professional growth. Explore related knowledge domains to expand your expertise, develop complementary skills, and access practical resources across the complete project management ecosystem.
Expand your expertise one domain at a time and build a well-rounded project management skill set.
Why Explore Related Domains?
- Develop cross-functional project management expertise
- Discover specialized knowledge beyond core project management
- Access practical resources across interconnected disciplines
- Build a complete professional learning pathway
- Strengthen career readiness through continuous learning
Each knowledge domain complements your Project Management expertise, helping you build broader capabilities and solve real-world project challenges with greater confidence.
Project Management
Practical project management knowledge, practices, and professional resources.
Project Controls
Performance measurement, forecasting, and project control best practices.
PMO
Governance, portfolio management, and organizational project excellence.
Risk Management
Risk identification, assessment, mitigation, and monitoring resources.
Primavera P6
Professional planning, scheduling, resource management, and reporting.
Microsoft Project
Project scheduling, tracking, reporting, and collaboration resources.
Power BI
Interactive dashboards, reporting, visualization, and project analytics.
PMI Certifications
Certification guidance, exam preparation, and professional development resources.