70.2 per cent of all projects deviate from plan by more than 10 per cent, and by 54 per cent at the median. That comes from an anonymised analysis of 94,620 projects in ZEP (as of April 2026). The deviation itself is rarely the real problem. The real problem is when it becomes visible.
At many project service providers, the planned-versus-actual comparison only happens at month-end close. By then the extra hours have long been worked and the margin has already tipped. The comparison documents damage instead of preventing it.
Effects at project level:
- Margin: extra hours on a fixed-price project come straight out of the contribution margin
- Project costs: change requests without recalculation shift the target unnoticed
- Resources: consultants tied up longer are missing from follow-on projects
- Utilisation: overrunning projects crowd out billable work elsewhere
- Forecast: if you learn the actual position too late, you report the wrong figures to management
The key points at a glance:
- The planned-versus-actual comparison sets planned hours, planned costs and planned progress against actual values
- It only becomes meaningful when cumulated and related to the progress actually achieved
- Thresholds with traffic light logic turn figures into clear escalation rules
- Calculated in Excel at month-end, it arrives too late for real steering
Why deviations get more expensive the later you see them
A deviation of 70 hours rarely arises in a single day. It builds over weeks: an underestimated work package here, an unpaid extra request there. Every week without a planned-versus-actual comparison increases the damage.
According to the Project Management Institute, 43 per cent of all projects exceed their original budget. The reason lies less often in poor planning than in missing control during execution. The article on overrun project budgets shows how such overruns actually arise.
The planned-versus-actual comparison is therefore the central instrument in project controlling. It answers three questions: where are we? Where should we be? And what does the difference cost us?
What a planned-versus-actual comparison has to measure in the project business
In controlling, the planned-versus-actual comparison means setting planned values against those actually incurred in a given period, classically a task of standard costing. For project service providers, three levels matter.
Hours, costs, progress: the three comparison levels
Hours are the leading figure, because in a service business they are the largest cost block. Costs come from hours times the internal hourly rate, plus travel expenses and third-party services. Progress measures how much of the planned work is actually complete.
Looking at only one level means steering blind. 400 hours consumed is uncritical if 60 per cent of the work packages are done. The same 400 hours are an alarm signal if only a third is finished.
The worked example: starting position on a fixed-price project
An IT consultancy takes on a CRM implementation at a fixed price of €96,000. The costing: 800 hours at an internal cost rate of €85 per hour, so €68,000 in planned costs. The planned margin is €28,000, or 29 per cent.
The project runs for six months. At the halfway point, 400 hours should be consumed and 50 per cent of the work packages complete. These target values are the benchmark for everything that follows.
How does variance analysis work?
After three months the actual figures are in. The project team has booked 470 hours, but only 42 per cent of the work packages are complete. What does that tell us?
| Metric | Target (halfway) | Actual (halfway) | Deviation |
|---|---|---|---|
| Cumulative hours | 400 h | 470 h | +70 h (+17.5 %) |
| Cumulative costs | €34,000 | €39,950 | +€5,950 (+17.5 %) |
| Progress | 50 % | 42 % | 8 percentage points below plan |
Absolute and percentage deviation
The absolute deviation quantifies the damage in hours and euros: plus 70 hours, plus €5,950. It is the basis for every recalculation and every client conversation.
The percentage deviation makes projects comparable. Formula: (actual minus target) divided by target times 100. Here: 70 divided by 400 times 100 equals 17.5 per cent. Only the percentage shows whether a €50,000 project or a €500,000 project is running further off track.
Cumulative view instead of monthly slices
Individual monthly figures play down the trend. In the example: plus 10 hours in the first month, plus 25 in the second, plus 35 in the third. Each monthly figure looks manageable on its own.
Cumulated, a different picture emerges: 70 extra hours with a rising trend. The planned-versus-actual comparison therefore always belongs on a cumulative timeline. Only there do three small outliers become a recognisable pattern.
Milestone reference: align target values with delivered work
A pure time comparison actually understates the problem. The 470 actual hours stand against 42 per cent progress instead of the planned 50 per cent. For 42 per cent of the work, only 336 hours would have been appropriate.
The performance-related deviation is therefore plus 134 hours, or around 40 per cent. This is precisely the logic behind the concept of target costs: planned values converted to the level of progress actually achieved. Comparing at milestones forces this view, because effort and result are examined together.
What the deviation means for the margin
Extrapolating the trend, at the same pace the project needs around 1,119 hours instead of 800. That corresponds to actual costs of roughly €95,100 against a fixed price of €96,000.
Of the €28,000 planned margin, €885 remains, less than one per cent. This extrapolation belongs in every revenue and margin forecast, because it changes the commercial assessment of the entire quarter.
Which thresholds make sense? Traffic light logic for daily project work
Figures alone steer nothing. Only defined thresholds turn the planned-versus-actual comparison into an instrument of control, because they set out when who has to act. A three-stage traffic light has proven itself in practice.
| Status | Performance-related deviation | Responsible | Action |
|---|---|---|---|
| Green | under 5 % | Project management | Monitor, review weekly |
| Amber | 5 to 10 % | Project management, PMO informed | Root cause analysis within a week, define countermeasures |
| Red | above 10 % | Escalate to management | Adjust forecast, change request or renegotiation, descoping if necessary |
The percentages are guide values and depend on margin and project size. A project with a 15 per cent planned margin tolerates less deviation than one with 40 per cent. What matters is that the thresholds are fixed before the project starts.
Who escalates when?
Green is everyday project management. Amber requires root cause analysis: is it unpaid extra requests, a wrong estimate or resource bottlenecks? Red leaves the project level, because from here on it is about contractual questions and the profitability of the business.
In the worked example, at 40 per cent performance-related deviation the light would be deep red. At the halfway point there is still room to negotiate, replan or adjust scope. Four weeks before handover, all that remains is writing off the margin.
Why the Excel comparison at month-end arrives too late
In practice the concept rarely fails on understanding. It fails on execution: planned values sit in the project plan, actual hours in time tracking, costs in accounting. Somebody has to pull that data into an Excel sheet by hand every month.
The delay is structural
By the time all hours are recorded, exported and reconciled, one to two weeks have often passed after month-end. The finished comparison then shows a position that is up to six weeks old. Late time entries make this worse, as the article on time tracking as an early warning system shows.
In the worked example, a further 100 to 150 hours would have accrued in those six weeks. Each of them at €85, without anyone having seen the red light.
Manual comparisons are error-prone and infrequent
Hand-maintained spreadsheets contain outdated plan versions, forgotten change requests and copy-paste errors. And because the effort is high, the comparison only happens monthly, and on smaller projects often not at all. A weekly traffic light across ten parallel projects is practically impossible in Excel.
This is exactly where it is decided whether project controlling steers or documents. If you only see deviations in the rear-view mirror, all you can do is explain why the margin is gone.
{{blog-cta}}
Planned versus actual in real time: how ZEP works
The way out is a shared data basis for plan and actuals. In ZEP Compact you store planned hours and budgets per project and task directly in the project planning module. The actual hours come from ongoing project time tracking in the same system.
The planned-versus-actual comparison is therefore no longer a monthly effort, it is a report at the push of a button. Every booked hour updates the comparison immediately, per project, per task, per employee. The traffic light is available daily instead of six weeks late.
From deviation to decision
If a project exceeds its planned values, you see it immediately in project controlling and can respond: reallocate resources, adjust budgets or hold the client conversation. Through the revenue and costs module, you connect the hours view with the commercial assessment of the project.
Data quality improves too: ZEP Pulse produces automatic time suggestions, so actual hours are complete and up to date. Forgotten hours distort the comparison just as much as missing planned values. You can test all of this free for 14 days.
Conclusion: three steps to a planned-versus-actual comparison you can steer with
Start with your largest live project. First: record planned hours and planned costs per work package, otherwise there is no target. Second: define thresholds and escalation paths before the next milestone, including who decides at red.
Third: shorten the comparison rhythm from monthly to weekly. If that takes more than 30 minutes a week with your current tools, the problem lies in your data basis, and it is worth looking at a system that brings planning and time tracking together.
FAQs
How often should you run a planned-versus-actual comparison on a project?
In the project business, weekly at minimum, plus at every milestone. The classic monthly rhythm comes from accounting and is too slow for steering projects. On short projects under three months, a four-week delay can already cost the entire margin.
What is the difference between planned costs and target costs?
Planned costs relate to the originally planned volume of work, for example 800 hours for the whole project. Target costs convert that plan to the level of progress actually achieved. If only 42 per cent of the work is complete, the target costs are 42 per cent of the planned costs. Only this reference makes the deviation honest.
How do you calculate the percentage deviation in a planned-versus-actual comparison?
The formula is: (actual value minus target value) divided by target value times 100. Example: 470 actual hours against 400 target hours gives a deviation of plus 17.5 per cent. Positive values mean overconsumption, negative values show you are running under plan.
What level of deviation is still normal in the project business?
As a rule of thumb: under 5 per cent green, 5 to 10 per cent amber, above 10 per cent red. The thresholds should match your planned margin, because a project with a 15 per cent margin tolerates less deviation than one with 40 per cent. More important than the exact figure is that the thresholds are agreed before the project starts.
What should you do when the comparison shows a red deviation?
First establish the cause: estimation error, unpaid additional work or resource problems. Then adjust the forecast and review your options: raise a change request, reduce scope or renegotiate. The article on overrun project budgets describes how to proceed in detail.
Is Excel enough for a planned-versus-actual comparison?
For a single small project, Excel can be enough. Across several parallel projects it fails on three counts: actual hours have to be transferred manually, the comparison lags the project by weeks, and errors go unnoticed. A system with a shared data basis for project time tracking and planning solves all three.
