The Plan You Agreed To and the One You Have
The timeline here draws your current dates against a snapshot of the dates you agreed to, and shows the variance per task. It is one of the better-built things in this product — and it has exactly one snapshot, with no record of when it was taken.
Projects do not slip in a way anybody notices. They slip a day at a time, each one individually reasonable, and the total is invisible unless something is holding on to what you originally said.
The position, stated first
Baselines here work, and they are worth using from the first day of a project. Set one when the plan is agreed and the timeline will show you the drift per task from then on. The limitation to know is that there is one baseline and re-setting it overwrites — with no record that you did, and no date on the snapshot.
What it does
A control on the project timeline takes every task's current start and due dates and stores them as the baseline. From that point, the timeline draws the current bar against a ghost of the original, and each task shows its variance in days.
That is the whole feature and it is enough. It is the only place in this product where the plan is compared against itself rather than against a budget, a target or a customer's expectation.
Two details show it was thought about. Cloning a project deliberately clears the baseline on the copies, so a new project starts with no false history. And recurring tasks carry the baseline fields through when they spawn, so a repeating inspection keeps its shape.
A ghost bar behind a real one is the cheapest project control ever invented, and almost nobody sets it.
Why the variance is the number that matters
Because it is the only one that distinguishes a project that is late from a project that was always going to take this long.
A task with a due date in three weeks tells you nothing about whether that date has moved four times. The variance tells you it has, and by how much, per task — which is what turns "the project is behind" into "these four tasks are carrying all of the slippage".
What each view of a schedule can tell you
| View | Where we are | Where we said | The drift |
|---|---|---|---|
| Current task dates | Yes | No | No |
| The critical path | Partly — configurable by you | No | No |
| Baseline ghost and variance | Yes | Yes | Yes |
| Budget consumed | Yes | No | No |
Built and maintained Configurable by you, not maintained by us Not built
Only one row answers the third column, and it is the only one that requires you to have done something at the start of the project.
The one snapshot
Setting a baseline overwrites whatever was there. There is one per task, no history of previous ones, and no date recorded for when the snapshot was taken.
For most projects that is fine — you set it once when the plan is agreed and leave it. The trouble arrives on the projects where a re-baseline is legitimate, which is exactly the projects where variance matters most.
A contract variation is agreed and the plan genuinely changes. Re-baselining is correct. But afterwards there is no record that a re-baseline happened, when, or what the previous plan said — so the variance you are now looking at is measured against a plan whose origin nobody can reconstruct. And a project that has been re-baselined three times shows a small variance, honestly, against a plan agreed last month.
Two, and the first is one column
The feature works. What it lacks is provenance, and the smaller half of that is nearly free.
A date on the baseline
When the snapshot was taken and by whom. One timestamp and one user reference, shown on the timeline beside the variance. It converts "you are eleven days late" into "you are eleven days late against a plan set on the fourth of March", which is a materially different sentence in a contract conversation.
Baseline versions, with a reason
Keeping the previous baseline when a new one is set, with a note saying why — a variation, a scope change, a delay accepted. Then variance can be shown against the original plan and the current one at the same time, which is what a project review actually needs.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your projects run under contracts with variations, the second item is the one that matters.
Talk to us about project baselinesWhat AWRA OpsHub does today
- Baseline start and due dates per task, snapshotted from current dates by an explicit action.
- A timeline that draws the current bar against a baseline ghost and shows the variance in days per task.
- Baselines deliberately cleared when a project is cloned, so a copy carries no false history.
- Baseline fields carried through when a recurring task spawns its next occurrence.
- A confirmation before the snapshot is taken, since it overwrites.
What it does not do
- Any record of when a baseline was set, or by whom.
- Any history of previous baselines — a new snapshot overwrites the old one.
- Any reason or note attached to a re-baseline.
- A project-level baseline distinct from the per-task ones.
- Any alert when variance crosses a threshold.
Not ours, by choice
- This is one of the better-built features in the projects module and this page is mostly an argument for using it. The gap is provenance rather than function.
- A baseline is only as good as the discipline of setting one at the right moment. No software can supply that, and a baseline set halfway through a slipping project is worse than none.
- Nothing here is Nigerian or Ghanaian. West Africa is here because contracting and infrastructure delivery are major activities, and on those projects slippage is a contractual event rather than an inconvenience.
Four questions about schedule variance
Is there a baseline, and when was it set?
A good answer sounds like
Yes, with a date.
What it actually means
Ours answers the first half. The date is the part that makes the variance quotable.
What happens when I re-baseline?
A good answer sounds like
The old one is kept.
What it actually means
Ours overwrites. That is fine until the third variation, and then it is not.
Can I see variance per task, not just overall?
A good answer sounds like
Yes.
What it actually means
Overall variance tells you there is a problem. Per task tells you where it is.
Does cloning a project copy the baseline?
A good answer sounds like
No.
What it actually means
Ours clears it deliberately, which is right — a copied plan has not been agreed by anybody yet.
Set it on the day the plan is agreed
It takes one click and it is the only thing that will ever tell you how far a project has moved from what everybody signed up to.
Talk about project deliveryFrequently asked questions
When should I set a baseline?
On the day the plan is agreed and before work starts. A baseline set later is a snapshot of a schedule that has already moved, and it will make a slipping project look healthy.
Should I re-baseline after a variation?
Usually yes — measuring against a plan that has been formally superseded is not useful. Write down separately what the previous plan said and when you changed it, because the product will not keep that for you.
Does the critical path use the baseline?
No. The critical path computes from durations in relative day offsets and does not read baselines or calendar dates at all. The baseline lives on the timeline, where real dates are.
