Baseline

A baseline is a snapshot of your approved project plan — the dates, durations, and structure that were agreed upon at the start of the project or at a major re-planning point. Once set, the baseline provides a fixed reference for measuring schedule variance: how much earlier or later is each task compared to the original plan?

Why Set a Baseline?

Without a baseline, you can only see the current plan. With a baseline, you can answer: "Are we ahead of schedule or behind it? By how much? For which tasks?" This is essential for stakeholder reporting, change control, and understanding the cumulative impact of scope changes.

Setting a baseline is the project management equivalent of taking a dated photograph of your plan. Future changes to the live plan show up as deviations from the photograph.

What is Saved in the Baseline

When you set a baseline, DPlan records the following for every task, milestone, and summary phase:

Field Saved	Description
`baseline.startDate`	The task's start date at the moment the baseline was set
`baseline.endDate`	The task's end date (or milestone date) at baseline time
`baseline.duration`	Working-day duration at baseline time
`baseline.name`	Task name at baseline time (used to detect renamed tasks in reports)

The baseline does not capture progress, status, assignee, notes, resources, or dependencies — only the schedule parameters that define when work was planned to happen.

Tasks added after the baseline was set have no baseline data. They are shown as "new tasks" in the variance view (see below).

Setting the Baseline

Make sure your project plan is complete and has been reviewed — set the baseline on the approved plan, not a work-in-progress.
If you intend to use Auto Schedule, run SCHEDULE → Auto Schedule first so that all task dates are up-to-date before locking them in.
Click SCHEDULE → Set Baseline.
A confirmation dialog appears: "Set baseline? This will snapshot all current task dates. The existing baseline (if any) will be replaced." Click Set Baseline to confirm.
The baseline is immediately stored in the project data and written to localStorage. It is also included in any subsequent .dplan file export.

Pro tip: Set the baseline immediately after the project kickoff meeting when the sponsor has approved the plan. Waiting even a few days means the first few tasks may already have drifted, making the baseline less meaningful.

Viewing the Baseline Overlay

Click VIEW → Baseline in the ribbon. The button shows in a highlighted state when the overlay is active.
Alternatively, enable Baseline Variance Bars in Settings — this makes the overlay on by default when opening the project.
On the Gantt, a dashed bar (outlined, not filled) appears beneath or beside each task's solid current bar. This dashed bar represents the baseline position.

Reading the Dashed Baseline Bars

Each task has two visual elements when the baseline overlay is on:

Solid bar: the current planned dates (the live plan)
Dashed bar: the baseline dates (the approved plan)

The relationship between them tells you the variance:

Visual Pattern	Meaning
Solid bar starts and ends at the same position as the dashed bar	On schedule — no variance
Solid bar is to the right of the dashed bar	Late — the task has been pushed out. Positive variance.
Solid bar is to the left of the dashed bar	Ahead of schedule — the task has been pulled in. Negative variance (favourable).
Solid bar is longer than the dashed bar	Scope growth or duration increase — more work than planned.
Solid bar is shorter than the dashed bar	Duration reduction — work completed faster than planned.
Solid bar present, no dashed bar	New task — added after baseline was set. No baseline to compare against.
Dashed bar present, no solid bar	Deleted task — was in baseline but has been removed from the live plan. Shown in grey/ghost style.

Positive and Negative Variance

DPlan calculates two variance figures per task, visible in the task tooltip when hovering with baseline overlay on:

Start Variance: current startDate − baseline startDate in working days. Positive = late start; negative = early start.
Finish Variance: current endDate − baseline endDate in working days. Positive = late finish; negative = early finish.

Summary phases roll up the worst (most positive) finish variance from their children, giving you a phase-level variance indicator.

Clearing the Baseline

Click SCHEDULE → Clear Baseline. A confirmation dialog warns you that this action cannot be undone — clearing the baseline is not tracked in the undo history. Once cleared, all baseline data is permanently removed from the project.

Clearing the baseline is irreversible. There is no undo for this action. Before clearing, export a .dplan file — the file contains the baseline data, and you can re-import it if you change your mind.

Re-Baselining — When and How

Re-baselining means replacing the old baseline with a new snapshot of the current plan. This is appropriate when:

A formal change request has been approved that significantly alters scope, schedule, or budget.
The original baseline has become so stale (e.g., project was paused for 3 months) that variance figures are meaningless noise rather than useful signals.
A new project phase begins with a re-planned schedule that has been formally approved.

Re-baselining procedure:

Export the current .dplan file — this preserves the old baseline if you ever need to reference it.
Update the project plan to reflect the approved re-plan.
Run Auto Schedule.
Click SCHEDULE → Set Baseline to overwrite the old baseline with the new dates.
Document in your project records that a re-baseline occurred, including the date and reason.

Only re-baseline with sponsor or change-control board approval. Re-baselining without approval is "moving the goalposts" — it destroys the accountability value of the baseline.

Baseline in the .dplan File Format

The baseline data is stored inside each task object in the .dplan JSON under a baseline key:

{
  "id": "task-42",
  "name": "Design wireframes",
  "startDate": "2026-04-15",
  "endDate": "2026-04-21",
  "duration": 5,
  "baseline": {
    "startDate": "2026-04-10",
    "endDate": "2026-04-16",
    "duration": 5
  }
}

When you share a .dplan file with a colleague, the baseline travels with it — they will see the same variance indicators when they open the file.

Practical Tips

Set the baseline before communicating dates to stakeholders. Once you have told stakeholders when the project will finish, that date becomes the de facto baseline in their minds. Capture it formally in DPlan at the same time.
Use baseline variance in weekly reports. Rather than reporting only "we are on schedule" or "we are late", report the finish variance: "Phase 2 is currently 3 days behind its baseline finish date." This gives stakeholders a quantified, actionable picture.
Combine with the critical path. The most critical variance to watch is start/finish variance on critical path tasks. A 2-day slip on a non-critical task with 5 days of float is not a problem. A 2-day slip on a critical task is a project delay.
Enable Baseline Variance Bars in Settings so the overlay is automatically shown whenever you open the project. This keeps variance visible by default and prevents you from forgetting to check it.