Engineering and architecture
Schedule baselines vs actuals: why project schedule history matters
By SourceX Editorial · Updated
Short answer
Schedule baseline vs actual data compares the approved plan with what happened, update by update. The history matters because the gaps, and the recorded reasons for them, show how a firm plans, absorbs delays and recovers. Keep the baseline, every status update and the delay reasons; a final schedule on its own erases the story.
Key takeaways
- A baseline is the approved plan frozen in time; actuals are the recorded dates of what really happened.
- Schedule history has four layers: baseline, updates, delays and reasons, and each lives in a different system.
- Overwritten update files and reset baselines are the most common ways firms lose schedule history.
- Delay reasons drawn from a short, consistent list make projects comparable while notes keep the specifics.
- Delay analyses prepared for disputes belong with counsel, not in a general archive or a data license.
What is the difference between a baseline and actuals?#
A schedule baseline is the approved plan frozen at a point in time, and actuals are the recorded start and finish dates of the work that really happened. Between the two sit schedule updates: periodic snapshots where the team records progress, revises remaining durations and adjusts logic.
For an A/E firm, the baseline is often the design schedule agreed with the owner, with milestones for schematic design, design development, construction documents, permit submission and bidding support. Actuals record when each deliverable went out, when owner decisions came back and when agency comments arrived.
The difference between the two is variance. The explanation of that variance is the part most firms fail to keep.
The four layers of schedule history#
Useful schedule history has four layers, and each one usually lives in a different place. Losing any one of them weakens the other three, because variance without reasons cannot be learned from and reasons without dates cannot be measured.
| Layer | What it records | Where it usually lives | What breaks without it |
|---|---|---|---|
| Baseline | Approved activities, durations, logic and milestones | Primavera P6 or Microsoft Project baselines, fee proposal schedules, spreadsheets | No reference point for variance |
| Updates | Progress, revised durations and logic changes at each status date | Periodic schedule files, often overwritten | No view of how the plan drifted |
| Delays | Which activities slipped, by how much and when the slip first appeared | Variance reports, look-ahead schedules, time impact analyses | Slips appear without a timeline |
| Reasons | Why work slipped: owner decisions, RFIs, agency review, scope changes, staffing | Narratives, meeting minutes, RFI logs, change requests, email | Variance cannot be explained or learned from |
Why does schedule history matter after the project closes?#
Schedule history matters after closeout because it is the firm's only factual record of how long work really takes. Principals use it to set fees and durations in proposals, project managers use it to staff new pursuits, and risk managers reach for it when a schedule question surfaces years later.
AI teams value the same records for a different reason. A baseline, a string of updates and the reasons behind each change form a sequence of plan, disruption and revised plan. That sequence is the kind of material used to train and evaluate planning agents that must replan when conditions change, and it is rarely available in public sources.
In both uses, the value comes from linkage. A slip tied to a pending RFI and an owner decision teaches far more than a bar chart showing that a milestone moved.
What schedule files usually lose#
Schedule files usually lose their history when teams overwrite the same file at each update. A P6 project may hold only the current baseline, and a Microsoft Project file may have had its baseline reset after a major change, erasing the original plan without anyone noticing.
The fix is cheap if it happens during the project: save each update as its own file or export, write a short narrative at each status date, and reference RFI and change numbers in activity notes. After closeout, recovery depends on whatever copies survived in email and shared drives.
- Overwritten updates: one live file and no saved copy for each status date.
- Reset baselines: a re-baseline after a scope change without archiving the original plan.
- Missing narratives: variance explained in meetings but never written down.
- Detached reasons: delay causes held in RFI logs and email with no link to activity IDs.
- Format loss: PDF exports that keep the bars but drop logic, activity codes and durations.
Which delay reasons should a firm record?#
Delay reasons are most useful when they come from a short, consistent list that every project manager uses. A controlled list makes reasons comparable across projects, while a free-text note keeps the specifics of each case.
Keep disputed projects separate. Delay analyses prepared for a claim may be privileged or subject to settlement terms, and they belong with counsel rather than in a general archive.
| Reason category | Examples in A/E work | Linked record |
|---|---|---|
| Owner decision | Program change, late approval of a design phase | Meeting minutes, approval emails |
| Information gap | Survey or geotechnical report late, RFI pending | RFI log, consultant correspondence |
| Agency review | Permit comments, resubmittal cycles | Plan review comment letters |
| Scope change | Added area, new consultant scope | Change requests, fee amendments |
| Internal capacity | Staffing conflicts, key reviewer unavailable | Resource plans, staffing notes |
| Construction phase | Submittal backlog, field conflicts | Submittal and RFI logs |
A closeout checklist for schedule records#
A closeout checklist for schedule records takes little time while the project team still remembers why dates moved. Run it as part of the same closeout meeting that collects lessons learned and final fee reports, and file the outputs with the project record rather than in a personal folder.
Assign the checklist to the project manager and have a principal confirm it is complete. Without an owner, schedule files tend to stay wherever the scheduler last saved them.
- Archive the original baseline and every re-baseline, each labeled with its approval date.
- Save each status update as a separate native file, not only as a PDF.
- Export activity codes, logic and durations so the schedule can be read without the original software version.
- Write a short variance narrative for each phase, citing the RFI, change request or decision behind each slip.
- Note any open dispute, claim or settlement so those files are held separately.
- Record where the related minutes, RFI log and change records are stored.
Illustrative: an MEP firm rebuilding schedule history#
Illustrative: Corbel Engineering, a fictional MEP firm, plans design work in Microsoft Project and tracks hours and fees in its project accounting system. Project managers saved updates inconsistently, and most delay explanations sat in coordination meeting minutes.
The firm picks closed projects where an update file exists for most status dates and no dispute is open. For each, it pairs the baseline and updates with the minutes and the RFI log, tags each slip with a reason category, and removes client names, addresses and staff names.
The immediate payoff is a firmer basis for proposal durations. The firm also has a candidate package it can describe in a metadata-only fit check without sending a single file, and a new rule that every update is saved under its status date.
How SourceX approaches schedule records#
SourceX treats schedule history as workflow data: plans, changes and outcomes linked over time. In the SourceX five-step transaction, Supply describes which projects hold baselines, updates and reasons; Rights checks owner confidentiality and dispute history; Preparation removes client and personal identifiers; Approval and Delivery follow the firm's sign-off.
The SourceX Evidence Packet records which projects were included, the provenance of each schedule file and the permitted use agreed with the buyer, so the firm can see exactly what left its systems.
Frequently asked questions
Do we need every schedule update, or just the baseline and the final?
Every update you can find is worth keeping. The baseline and final schedule show total variance but not when or why it happened. Intermediate updates reveal how the team responded to each disruption, which is the part that informs future planning and the part AI teams find hardest to source.
Are project schedules confidential to the client?
Often, at least in part. Owner agreements commonly treat project information as confidential, and a schedule may reveal the owner's business plans, such as an opening or relocation date. Review the confidentiality clause and remove identifying details before any outside use.
Can contractor schedules from construction administration be included?
Contractor schedules are the contractor's work product, delivered to the owner under the construction contract. Your firm's review comments on those schedules are your own records, but the schedules themselves are usually not yours to license.
What if our history is mostly narratives and no schedule files?
Narratives still help. Progress reports, meeting minutes and project manager notes that explain slips can be linked to deliverable dates from your project accounting or document control systems. The result is less precise than a scheduled history but still shows plan, disruption and response.
Which scheduling software keeps history best?
Most scheduling tools can keep useful history if the team uses them that way. Baseline features differ between products and versions, so check the documentation for yours, but no tool replaces the habit of saving each update under its status date and writing a narrative. The discipline matters more than the product.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.