Schedule Forecasts vs the Schedule Baseline
Two dates exist for every milestone on a well-run project, and both are legitimate. One is the date that was agreed when the plan was approved. The other is the date the work is now expected to finish, given everything known today. Projects get into difficulty when only one of the two is visible, and it is almost always the second one that goes missing.
Section 4 of the PMBOK® Guide Eighth Edition carries both as separate artefacts. Holding them apart is what allows anybody to say how a project has actually performed.
Two dates that must both exist
The baseline is the fixed reference. It was approved, it does not move without a formal decision, and its whole function is to stay still so that movement can be measured against it. A baseline that shifts whenever the position changes measures nothing, in the same way a ruler that stretches measures nothing.
The forecast is the current honest expectation. It moves as the work teaches you things: a rate that is lower than planned, a dependency that arrived late, a piece of work that went better than expected. A forecast that only moves when somebody insists is not a forecast; it is a restatement of the plan.
Three habits that break the pair
Re-baselining whenever the forecast moves. The variance disappears, the report looks clean, and the organisation loses its only record of how the project has performed. Projects that do this repeatedly cannot answer the simplest governance question, which is whether they are delivering to what was agreed.
Reporting the baseline date while privately holding a different forecast. Uncomfortably common, usually well intentioned, and corrosive: the project team knows the real date, the sponsor is told the approved one, and the difference surfaces when it can no longer be absorbed. Once a sponsor discovers this has happened, everything else the project reports is discounted.
Letting the forecast move only at reporting boundaries. A forecast that updates on the last Friday of the month, and only then, delivers bad news up to four weeks after it was known. Where something material changes, the forecast changes that day, and whoever needs to know hears it that day.
A rollout that quietly moved its own baseline
A retailer was fitting new picking and packing equipment across eleven fulfilment sites, each taking about five weeks, with the programme baselined at approval and reported monthly to a steering group.
Site three ran two weeks late for reasons that were understood and largely external: a power supply upgrade from the distribution network operator had slipped. The programme re-baselined to absorb it, which is a defensible decision taken once.
It then happened three more times. Each time a site overran, the remaining programme was rebaselined to the new dates, and each monthly report showed the programme as on plan. By site eight, the completion date had moved by about eleven weeks in total and no report had ever shown a variance, because there was no longer a stable reference to vary from.
What exposed it was an operations manager on the mezzanine at site eight, standing beside a run of racking that had been moved during the fit-out. The old bolt holes and paint outlines were still visible on the decking a clear margin away from where the racking now stood, and she made the obvious remark: you can still see where it was supposed to be. Her programme colleague had no equivalent for the schedule, because every version of where it was supposed to be had been overwritten.
The programme reinstated the original baseline as the reference for reporting, kept the current forecast beside it, and reported the gap with an explanation. The first report under the new arrangement was uncomfortable and it was the first one anybody outside the programme could actually use.
Reporting both
Show three numbers: baseline, forecast, variance. Every milestone that matters, on one line each, with the reason for any variance beyond a stated threshold. This takes very little space and answers the question a governance group is actually asking.
Re-baseline rarely, formally, and with the history kept. A reset is legitimate after a scope change, a major external event or a structural replan, and it should be an explicit decision with a record of what the previous baseline was. Keeping the original visible alongside is what allows an organisation to learn anything about its own estimating.
For a PMP® candidate, what matters is that the baseline is a fixed reference and the forecast is a moving expectation, so a scenario about a project reporting no variance across a long run is worth reading as a re-baselining habit. A response that accepts the reported position has accepted a measure with no reference behind it. Situations where the reporting is clean and the performance is unknowable are a standing exercise in a structured PMP exam preparation course.
Check one thing on your own project: how many times has the baseline been reset, and can you still see what the original approved dates were? If the answer to the second half is no, the project has lost its ability to describe its own performance, and restoring it starts with finding the earliest approved version and putting it back on the page.
Interested in going further?
A clean report with no reference behind it tells a governance group nothing, and it takes a while for anybody to notice. Omega's PMP® Exam Preparation works through baselines and forecasts as two things a project must hold at once.
Schedule baselines and forecasts are both described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A111: Dates Are Not a Schedule
A112: Critical Path Explained Without the Mystique
A113: Float Explained: How Much Delay Can You Really Absorb?
A114: Milestones vs Activities: Stop Treating Them as the Same Thing
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
