Baselines and variance
A project plan is a living document — dates shift, work estimates change, and scope evolves. Without a fixed reference point, it is impossible to answer the question: "How does our current plan compare to what we originally committed to?"
Baselines provide that reference point. Raytio PPM lets you snapshot the current state of a project and later compare it against the live data to measure variance — the difference between plan and reality.
What is a baseline?
A baseline is an immutable snapshot of a project's schedule data at a specific point in time. Think of it as a photograph of the plan: once taken, it cannot be edited, retouched, or deleted.
Typical moments to save a baseline:
- At project kickoff — the original committed plan
- After a major re-plan — when the scope or schedule has been formally revised
- At phase boundaries — to track drift between phases
- Before a risk-response change — to measure the impact of a schedule recovery action
A project can have any number of baselines.
What gets snapshotted
When you save a baseline, the following data is captured for every work item in the project:
| Data | Fields captured |
|---|---|
| Schedule dates | planned_start, planned_finish |
| Effort and duration | planned_work, planned_duration |
| Progress | percent_complete |
| Dependencies | All dependency records (type, lag) between work items |
| Milestones | Milestone dates and status |
Each baseline record is linked to the work item it snapshots, creating a one-to-many relationship: one baseline contains one snapshot row per work item.
Immutability
Baselines are immutable. Once saved, a baseline's data cannot be modified. This supports:
- Audit trail — baselines serve as evidence of what was planned and when.
- Variance integrity — a fixed reference point keeps variance analysis meaningful.
- Stakeholder trust — a baseline claim such as "planned to finish on March 15" is verifiable after the fact.
If the plan changes significantly and you need a new reference point, save a new baseline. The old baseline remains available for comparison.
Baselines are project-scoped. When you save a baseline, it captures all work items in the project — you cannot baseline individual items in isolation. This ensures the snapshot is internally consistent (dependency relationships make sense only in the context of the full schedule).
Variance: measuring drift
The ppm_baseline_variance database view computes the difference between a baseline snapshot and the current live data. It produces a row per work item per baseline, with the following variance columns:
Date variance
| Column | Calculation | Interpretation |
|---|---|---|
start_variance_days | actual_start - baseline_planned_start | Positive = started late, negative = started early |
finish_variance_days | actual_finish - baseline_planned_finish | Positive = finished late, negative = finished early |
If actual dates are not yet set (work hasn't started or finished), the view uses planned_start / planned_finish as the comparison value — so you can see schedule drift even before work begins.
Work variance
| Column | Calculation | Interpretation |
|---|---|---|
work_variance_hours | actual_work - baseline_planned_work | Positive = more effort than planned, negative = less |
This tells you whether tasks are consuming more or fewer person-hours than originally estimated.
Duration variance
| Column | Calculation | Interpretation |
|---|---|---|
duration_variance_days | actual_duration - baseline_planned_duration | Positive = took longer, negative = completed faster |
Duration variance is independent of work variance. A task might take more calendar days (duration variance positive) but fewer person-hours (work variance negative) — this often happens when a task is deprioritised and stretched over more days with less daily effort.
Typical use cases
Earned value analysis (lightweight)
While Raytio PPM does not implement full Earned Value Management (EVM), the baseline variance data provides the inputs for lightweight earned value calculations:
- Planned Value (PV): Baseline planned work, prorated by baseline percent complete at the reporting date
- Earned Value (EV): Baseline planned work × current percent complete
- Actual Cost (AC): Actual work × cost rate (if cost tracking is configured)
Teams using external reporting tools can query the variance view and compute Schedule Performance Index (SPI) and Cost Performance Index (CPI) from these inputs.
Schedule health dashboard
A common reporting pattern:
| Work item | Baseline finish | Current finish | Variance | Status |
|---|---|---|---|---|
| Design | Mar 10 | Mar 10 | 0 days | On track |
| Build | Mar 20 | Mar 25 | +5 days | Late |
| Test | Apr 01 | Mar 28 | -3 days | Ahead |
| Deploy | Apr 05 | Apr 08 | +3 days | Late |
This dashboard is derived directly from the ppm_baseline_variance view.
Trend analysis across baselines
By comparing multiple baselines, you can see how the plan has evolved:
| Baseline | Saved | Planned finish (Deploy) |
|---|---|---|
| Baseline 0 | Jan 15 | Apr 05 |
| Baseline 1 | Feb 20 | Apr 12 |
| Baseline 2 | Mar 10 | Apr 08 |
| Current plan | — | Apr 10 |
This shows that the finish date has shifted three times, with the current plan landing between Baseline 1 and Baseline 2. This kind of trend visibility is only possible because each baseline is preserved as an immutable snapshot.
Further reading
- How PPM handles scheduling — how baselines fit into the overall scheduling model
- Percent complete — manual and rollup — how progress values feed into baseline snapshots
- Work, duration, and elapsed time — the fields that baselines capture and variance compares