Baseline, forecast and variance: keep commitment separate from expectation
How to preserve an approved project baseline while maintaining an honest current forecast and controlled record of change.
Decision this guide supports
Has the expected delivery changed, and does that require recovery, approval or a new baseline?
Key takeaways
- The baseline records the approved commitment; the forecast records the current expectation; actuals record what happened.
- Variance is management information, not a reason to hide or automatically rebaseline.
- Rebaseline only through agreed change control when the basis of commitment genuinely changes.
Three views that answer different questions
| View | Question |
|---|---|
| Baseline | What did we approve and commit to? |
| Forecast | When and at what cost do we currently expect to deliver? |
| Actual | What has already happened? |
Variance creates the management conversation
If a milestone was approved for 10 June and is now forecast for 24 June, the two-week variance is useful. It prompts investigation of cause, downstream effect, tolerance and recovery options.
Replacing 10 June with 24 June may make the chart look tidy, but it removes the information governance needs. RuruPilot’s baseline and variance view is intended to keep both dates visible.
Update the forecast whenever evidence changes
An honest forecast is not a promise to fail. It is the best current estimate based on remaining work, dependencies, decisions and uncertainty. Delaying a forecast update until recovery is certain deprives leaders of time to act.
Record the short rationale for material movements. The audit trail should explain whether the change came from new scope, estimation learning, a missed dependency, an external event or a deliberate trade-off.
When rebaselining is appropriate
- An approved scope or outcome change materially alters the delivery basis.
- A governance decision accepts a revised cost or schedule commitment.
- The original baseline is no longer a meaningful control reference after authorised restructuring.
- The change, rationale, approver and prior baseline remain traceable.
Not a valid reason
“The current dates are uncomfortable” is not sufficient. Rebaselining should record an approved change, not erase performance history.
Worked example: supplier approval delay
A design milestone has a 1 May baseline. Supplier approval moves the forecast to 12 May and pushes testing by one week. The project manager updates the forecast immediately, records the dependency cause and tests recovery options.
If the sponsor accepts a reduced first-release scope that restores the original launch outcome, the milestone forecast may change again. The baseline changes only if the authorised scope decision changes the approved commitment and governance approves a rebaseline.
Common control failures
- Using one date field for baseline, forecast and actual.
- Waiting for certainty before showing forecast movement.
- Rebaselining every reporting cycle to remain green.
- Reporting variance without cause, effect or action.
- Comparing tasks that changed identity or scope without recording the change.
Sources & method
This guide is RuruPilot’s practical synthesis. Definitions and established control principles are grounded in the primary sources below; examples, operating conventions and recommendations are our interpretation unless stated otherwise.
- 1Schedule Assessment Guide: Best Practices for Project Schedules
U.S. Government Accountability Office. Detailed criteria for comprehensive, well-constructed, credible and controlled schedules.
- 2APM glossary
Association for Project Management. Reference definitions for schedules, milestones, baselines, change control, risks, issues, governance and reporting.
Talk it through
Want to apply this to your own project?
Tell us what you are facing. We can discuss project support, practical PM training, consultancy, or how RuruPilot could support your team.
Prefer email? Write to hello@macrocyra.com.