Metric Definition
Schedule variance
Track from
Project timeline variance
Project timeline variance is the difference between when project work was planned to finish and when it actually finishes, expressed in days or as a percentage of planned duration. A negative variance means the project is running behind, a positive variance means it is ahead. It is the most direct measure of whether a schedule is holding.
7 min read
What is project timeline variance?
Project timeline variance is the difference between when project work was planned to finish and when it actually finishes, expressed in days or as a percentage of planned duration. If a phase was planned to take 40 days and took 46, the variance is 6 days late, or 15 percent. Stated as schedule variance in earned-value terms it is negative when behind and positive when ahead.
Variance matters because it quantifies slippage in a way you can act on. A project manager who says work is running late is describing a feeling. A variance of plus 15 percent on the critical path is a number you can forecast forward, compare across phases, and assign to a cause. Tracking variance over the life of a project shows whether the gap is stable, widening, or recovering, which is often more useful than the size of the gap on any single day.
Definition note
Be clear about sign convention. In earned-value reporting a negative schedule variance means behind schedule. When expressing variance as days late, a positive number usually means behind. Pick one convention and label it, because mixing them creates confusion that hides the direction of the slip.
How to calculate project timeline variance
The simplest form of timeline variance is actual duration minus planned duration, which gives the gap in days. To compare projects of different sizes, divide that gap by the planned duration and express it as a percentage. A 6-day overrun on a 40-day plan is a larger problem than a 6-day overrun on a 200-day plan, and the percentage form makes that comparable.
Worked example. A workstream was scheduled for 30 working days and is forecast to complete in 36. The variance is 36 minus 30, which is 6 days late. As a percentage that is 6 divided by 30, which is 20 percent over plan. In earned-value terms you can also compute schedule variance as the budgeted cost of completed work minus the budgeted cost of scheduled work, where a result below zero confirms the project is behind.
- 1
Fix the baseline duration
Record the planned duration or planned finish date for the task, phase, or project from the agreed baseline.
- 2
Capture the actual or forecast finish
Use the real completion date for finished work, or the current forecast finish for work still in progress.
- 3
Subtract to get the gap in days
Actual or forecast duration minus planned duration gives the variance in days, positive when behind.
- 4
Express as a percentage
Divide the day gap by the planned duration and multiply by 100 to make variance comparable across projects.
Project timeline variance in a metric tree
Variance tells you how far the schedule has drifted but not what pulled it there. A metric tree decomposes the variance into the causal drivers beneath it, so a 20 percent overrun becomes a breakdown of where the days were lost. Most variance traces to a handful of sources, optimistic estimates, scope added mid-flight, blocking dependencies, and rework that was not planned for.
KPI Tree models this decomposition and attaches RACI ownership to every branch, so each driver of variance has someone Responsible and Accountable for it. When variance widens, the change is pushed to the accountable owner of the branch that moved, rather than landing as a generic schedule alert. The verified impact loop then checks whether the corrective action actually reduced the variance, so you build a record of which interventions work. That is the difference between a dashboard that shows the project is 20 percent late and a system that routes the slip to the person who can close it.
Metric tree insight
Variance from added scope is not the same failure as variance from poor estimation, and the fix differs. Scope-driven variance calls for a tighter change gate, estimation-driven variance calls for better baselines. The tree separates the two so you do not apply the wrong remedy.
Project timeline variance benchmarks
Acceptable variance depends heavily on how predictable the work is. Routine delivery with stable requirements should stay within a tight band, while research-led or first-of-a-kind projects routinely run wider and that is reasonable. Use these percentage ranges as a reference for reading variance, calibrated against your own project history.
| Timeline variance | Reading | What it usually means |
|---|---|---|
| Within plus or minus 5 percent | On track | Schedule is holding within normal tolerance, no intervention needed |
| 5 to 10 percent over plan | Watch | Minor slippage worth monitoring, identify the driver before it compounds |
| 10 to 20 percent over plan | At risk | Material overrun that will push dependent work, active management required |
| Above 20 percent over plan | Critical | Serious slippage, the plan is not holding and the baseline or scope needs to be revisited |
How to improve project timeline variance
Reducing variance means attacking the drivers that create the gap rather than simply demanding the work go faster. The most effective teams find which branch of the tree is generating the most lost days and act there first. The aim is a schedule that drifts less and recovers faster when it does.
Calibrate estimates
Track estimate-to-actual variance on completed work and apply a realistic adjustment to future plans. Persistent optimism bias is the most common single source of timeline variance.
Gate scope changes
Make every accepted change carry an explicit schedule impact. Variance from silent scope creep is invisible until the date slips, so price the change at the point it is agreed.
Manage dependencies actively
Identify blocking dependencies up front and track wait time as its own line. Days lost waiting on upstream or vendor work are recoverable if you see them early.
Cut rework at the source
Catch defects and requirement misunderstandings earlier, where fixing them costs hours rather than weeks. Late rework is one of the heaviest contributors to variance.
Common mistakes when tracking project timeline variance
- 1
Mixing sign conventions
Switching between negative-means-behind and positive-means-late across reports hides the direction of the slip. Fix one convention and label it everywhere.
- 2
Measuring against a moved baseline
Re-baselining after a slip resets variance to near zero and erases the lesson. Keep the original baseline so the true gap stays visible.
- 3
Reporting variance without a cause
A bare variance figure shows the symptom but not the source. Without a driver breakdown, every overrun becomes guesswork.
- 4
Averaging variance across all tasks
A small overrun on the critical path can matter more than a large one with slack. Weight by critical-path impact rather than treating every task equally.
Related metrics
Cycle time
Process speed
Operations Metrics
Metric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Sprint velocity
Agile planning metric
Operations MetricsMetric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Deployment frequency
DORA metric
Operations Metrics
Metric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Why did my metric change? A diagnostic framework
Metric Definition
When project timeline variance widens, this diagnostic framework helps you trace which underlying drivers pushed the schedule off track so you can act on the cause.
Metric trees for operations teams
Metric Definition
Project timeline variance is an operations delivery metric, so this guide shows how operations teams place it within a metric tree alongside the inputs that move it.
Build project timeline variance as a metric tree
Decompose variance into estimation, scope, dependencies, and rework, then put a named owner on every branch with RACI. When variance widens, KPI Tree pushes it to the accountable owner and the verified impact loop confirms whether the fix actually closed the gap.
