A Gantt chart baseline is a saved reference version of a project schedule, shown alongside the current plan or actual progress. It allows a team to compare the original approved timing with what now seems likely and what has already happened. A baseline is not a promise that uncertainty has disappeared.
The important distinction is between baseline, forecast, and actual. The baseline preserves an agreed reference. The forecast changes as the team learns. Actual dates record completed events. If those fields are overwritten together, the chart can no longer explain schedule movement.
This guide covers interpretation and team review rather than instructions for one scheduling application. NextRetro is a retrospective tool, not a Gantt scheduling engine; maintain the authoritative schedule in your project-planning system.
What belongs in the schedule baseline?
A useful baseline connects relevant activities, dependencies, calendars, and milestones. Saving a picture of arbitrary dates does not make the underlying plan credible. Confirm how the schedule represents resource availability and which assumptions determine important completion dates.
The U.S. GAO Schedule Assessment Guide treats maintaining a baseline and updating a schedule using actual progress as distinct scheduling practices. Our review method below applies that distinction to a small team's decision meeting; it is not a substitute for specialist schedule assurance.
Record the baseline's approval date, scope, version, and assumptions. Specify who can approve changes. A project with contractual or regulated commitments may need controls beyond the lightweight examples here.
Do not wait until the end of delivery to choose the reference that makes performance look best. If the project uses progressive planning, document which parts are detailed, which remain uncertain, and how approved elaboration will be preserved.
Read baseline, forecast, and actual dates together
Consider this hypothetical project excerpt. Dates and activities are invented for explanation.
| Item | Baseline finish | Current forecast | Actual finish | Review question |
|---|---|---|---|---|
| Data mapping agreed | 4 Nov | — | 6 Nov | Why did agreement take longer? |
| Migration rehearsal complete | 11 Nov | 16 Nov | — | Which predecessor or capacity constraint changed? |
| Operational acceptance | 18 Nov | 23 Nov | — | Does the receiving team accept the revised readiness window? |
A completed item needs an actual date, not a continuously moving forecast. An unfinished item needs a realistic forecast, not the old baseline copied into the current-plan field because nobody wants to report delay.
Also distinguish elapsed time from working time. Five calendar days and five working days are different comparisons. State the convention before calculating variance, especially when teams use different holidays or operating calendars.
Not every delay changes the project's finish. Examine the dependency logic and available flexibility before declaring that a late task means a late project. Conversely, a small delay in a consequential handoff can matter more than several large movements elsewhere.
A 30-minute variance review
Bring the current schedule, its baseline, and a short list of items whose movement could change a decision. Avoid reviewing every bar merely because it exists.
First five minutes: agree the reference version and status date. Confirm whether actual progress is current. Note known data gaps before interpreting the chart.
Next ten minutes: inspect one consequential chain of work. Ask what changed in scope, sequence, availability, effort, or external commitments. Separate events supported by evidence from plausible explanations.
Next ten minutes: compare responses. Can the team remove unnecessary waiting, change sequencing safely, secure a decision, or reduce authorized scope? What cost or risk would acceleration create? More people or overtime are options with consequences, not automatic corrections.
Final five minutes: record the decision, owner, and forecast update. If a commitment must change, route it through the project's established approval process. Preserve the previous baseline and the reason for any authorized replacement.
These timings are a suggested facilitation format. A complex program can need a deeper schedule-risk review rather than a shorter meeting.
Worked example: the late task was not the whole cause
In a hypothetical software migration, the rehearsal ends four working days later than the baseline. The first explanation is “testing took too long.” The team is about to reduce the next test window to recover time.
The review follows the evidence backward. The test execution itself used the planned amount of time. Work started late because the receiving operations team had not approved the production-like test data, and the named approver was unavailable.
Reducing test time would not address that cause and could weaken readiness evidence. The team instead agrees an earlier acceptance check for the next rehearsal and confirms a backup decision owner under the existing approval rules.
It updates the forecast and keeps the original baseline visible. The retrospective captures a reusable lesson: identify approval availability when planning the dependency, rather than assuming a named owner is always available.
There is still schedule impact. A good explanation does not erase it. The sponsor receives the revised forecast with options and tradeoffs, not a claim that the delay no longer counts.
When should a team rebaseline?
Rebaselining changes the approved comparison reference. It can be appropriate after an authorized scope change or a major reset of the delivery commitment. It should not be the routine response to an unfavorable variance.
Keep the original baseline archived, identify the newly approved scope and dates, and explain which comparisons future reports will use. If only one package of work changed, avoid silently rewriting unrelated history.
A new baseline can help manage the remaining work while the old one remains useful for learning. Those are compatible purposes. Reporting should make clear whether a statement compares against the original commitment or the later authorized plan.
Do not confuse a working forecast with a newly approved baseline. The forecast can and should become more realistic without waiting for every planning assumption to be formally renegotiated.
Turn schedule evidence into a useful retrospective
At the next retrospective, choose one repeated pattern: waiting for approvals, underestimated integration, missing capacity, or optimistic handoffs. Avoid turning the meeting into individual blame for every late activity.
Ask what decision the team could have made earlier with information already available. Then define an experiment, such as confirming reviewer availability before committing a milestone, and a check for whether that change reduces the specific waiting pattern.
Use the retrospective action-items guide to record the experiment and the facilitator checklist to prepare the discussion. The schedule supplies evidence; the retrospective supplies a deliberate learning loop.
Frequently asked questions
Is a baseline the same as a deadline?
No. A baseline is a reference version of the schedule. A deadline is a time constraint or commitment. A schedule can contain several deadlines, and its baseline can preserve how the team originally planned to meet them.
Should we update the baseline when a task slips?
Update the current forecast to reflect reality. Change the approved baseline only under the project's agreed governance, retaining its previous version and the reason. Routine overwriting makes original performance difficult to interpret.
Can a Gantt chart prove why a project was delayed?
A chart can show timing and dependency relationships, but it does not establish every cause. Use task records, decisions, capacity evidence, and the participants' accounts to investigate competing explanations before selecting a corrective action.