The one root cause behind most overruns
Ask why a project came in late and over budget and you will hear specifics: the material was delayed, the client changed the design, a machine broke, a subcontractor under-quoted. All true — but they are symptoms. Underneath almost every project overrun is one structural cause: the plan, the cost and the actuals live in separate places that never reconcile — the estimate in a quotation, the schedule in a spreadsheet Gantt, material issue in a stores register, billing in an accounts book. Each is fine on its own; the damage is in the gaps between them.
When those records are disconnected, drift is invisible until it is large. A task quietly running 15% over its estimate cannot be seen against that estimate when the estimate sits in a different file; a three-day slip does not move the finish date when nothing re-flows the schedule. By the time the numbers are added up — at a milestone or month-end — the small, cheap-to-fix problems have compounded into a large, expensive one. Fix the disconnection and most symptoms lose their power to surprise you.
The seven causes, and the fix for each
Overruns cluster into seven recurring patterns. Six of the seven are curable by the same move: connect the plan to the cost to the actuals on one engine.
| Cause | What goes wrong | The fix |
|---|---|---|
| Vague scope | Scope lives in prose, so it cannot be planned, priced or tracked | Author a WBS of tasks with owners and dates |
| Disconnected estimate | The quote is a lump sum unrelated to the task plan | Price each task with a Bill of Resources |
| Silent cost drift | Actual cost is not booked against the estimate until late | Issue material and hours against the task |
| Un-reflowed slip | A task slips but successors and the finish date do not move | Let Gantt dependencies re-sequence |
| Resource contention | Two tasks are scheduled on the same machine or crew | Use a resource-wise Gantt |
| Uncontrolled change | Design changes and rework leave no cost or schedule trail | Log changes on the task; re-estimate the BOR |
| Lagging billing | Cash falls behind work, masking the cost problem | Milestone / RA bills keyed to completed tasks |
Notice that the fixes are not seven different tools — they are seven facets of one connected system. Author scope as a WBS, price it with a Bill of Resources, schedule it on a Gantt with dependencies, book actuals against the tasks and bill from the same records — and each cause loses its hiding place. For the metrics that make the drift visible, see essential project reports & KPIs.
How cost drift stays invisible
Cost overruns are the most dangerous kind because they are the quietest. Nobody decides to blow the budget; it leaks away a line at a time — an extra week of hired plant, a few more tonnes of steel, a subcontractor line that crept above quote. Individually each is trivial; together, over a project, they are the difference between a healthy margin and a loss. And they stay invisible because the actual cost and the estimate usually are not in the same place: if the estimate is a quotation and the actual is a purchase ledger, comparing them is a manual exercise nobody does weekly. The cure is to put both on the same record — build the estimate from a per-task Bill of Resources, then book every material issue and resource hour against the same task, so estimated-versus-actual is a live figure at the resource line, the task and the project. When the machining task's consumables line goes 15% over, it turns amber the day it happens — not at the milestone review six weeks later.
Finding out a project lost money only when you invoiced it?
We can show you a live project where estimated-versus-actual updates as material is issued — so drift is visible task by task, in 30 minutes.
How a small slip becomes a late project
Time overruns follow the same logic: a small delay is cheap to absorb, but only if you can see its consequence. The failure is not that a task slips — tasks always slip — it is that the slip does not propagate. On a static Gantt, moving one task three days does nothing to its successors or the finish date, so the exposure is hidden until the successor cannot start and the delay is suddenly real.
A dependency-driven Gantt breaks the chain at step two: update the slipping task and the successors move, so the finish-date exposure is visible while it is still a few days. That early warning lets a manager re-sequence a parallel task or expedite the next material lot for a modest cost, instead of crashing the back end of the project with overtime — which is how a time overrun becomes a cost overrun too. For the mechanics, see how to track project progress.
Resource contention, the hidden delay
The subtlest cause hides between projects rather than within one. Two projects each look perfectly schedulable on their own Gantt — but both have booked the same welding bay, crane or crew for the same week. Neither project's own view shows the clash; it surfaces only when the crew physically cannot be in two places, and by then the delay is here, not forecast. The tool that exposes it is a resource-wise Gantt that plots machines and crews across every project at once, so an over-committed resource shows up as an over-stacked bar before any work starts — resolving it then is a calendar decision, resolving it later is a delay. That is the strongest argument for planning the whole portfolio on one engine, the subject of managing multiple projects.
Change and rework without a paper trail
The one cause that is not purely about connection is uncontrolled change. Clients change designs, site conditions differ from drawings, and rework happens — that is normal on build-to-order work. The overrun comes not from the change itself but from absorbing it silently: the extra work is done and paid for, but none of it is captured against a re-estimate or a variation, so the baseline never moved to reflect reality.
The discipline is to make change visible on the record: when a design change lands, log it on the affected task, re-estimate that task's Bill of Resources, and let the revised cost and dates flow into the project position. The change may still cost money and time — but now it is a documented, billable variation rather than an invisible erosion of margin. Keeping that record well is the subject of project documentation best practices.
Two overruns avoided by one connected engine
An engineering contractor runs two overlapping projects — a structural steel package and a process skid — on one system. When the skid's fabrication task slips five days on late plate, welding is a predecessor to assembly, so the successors re-flow and the forecast finish moves at once; the manager expedites the next plate lot and re-sequences a parallel task, recovering three days for a small expediting cost rather than a large crash cost. Separately, the resource-wise Gantt shows the shared welding bay double-booked across both projects in week seven; spotted three weeks out, it is resolved by shifting one non-critical task, avoiding a delay neither project's own view would have revealed. And when the client changes a skid nozzle, the task BOR is re-estimated and logged, turning the rework into a billable variation. Three overruns headed off — because the plan, the cost and the actuals reconciled on one engine. This is the profile behind deployments such as Micro India and DVC Process.
A prevention routine that works
Prevention is not heroics; it is a light routine run consistently on connected data. These five moves, done weekly, catch the causes while they are still small.
How Fast Project Software prevents overruns
Fast Project Software attacks overruns at the root by keeping the plan, the cost and the actuals on one engine. Mapping the causes to the product:
Because it runs on the shared Fast Suite platform, none of these records are re-keyed at a boundary — the estimate, the issue and the bill are one connected history, cloud or on-premise. INR pricing is indicative; confirm the commercial treatment with your CA. See pricing or the pillar guide.
Frequently asked questions
Why do projects overrun on cost and time?
Projects overrun for a small set of recurring reasons: scope never written down as a structured WBS, an estimate disconnected from the plan it prices, cost drift unbooked until month-end, schedule slip not re-flowed through task dependencies, resource contention where two tasks fight over the same machine or crew, uncontrolled change and rework, and billing that lags the work so cash problems mask cost problems. Almost all share one root: the plan, the cost and the actuals live in separate places, so drift is invisible until it is large.
How can you prevent cost overruns on a project?
Prevent cost overruns by making cost visible against its estimate continuously, not at the post-mortem. Author scope as a WBS, price each task with a Bill of Resources from a resource master, then book every material issue and resource hour against the task it belongs to so actual cost lands on the same record as the estimate. Read estimated-versus-actual at line, task and project level, and act on the first task to breach its estimate rather than waiting for the whole project to go red.
How does resource contention cause project delays?
Resource contention happens when two tasks — often on different projects — are scheduled to use the same machine, bay or crew at the same time. On a single-project Gantt this is invisible, because each project looks fine on its own. The clash only surfaces as a delay when the crew physically cannot be in two places, by which point re-planning is expensive. A resource-wise Gantt that shows how machines and crews are loaded across everything running at once exposes the contention before work starts, so it can be resolved while it is still just a calendar conflict.
How does Fast Project Software help prevent overruns?
It keeps the plan, the cost and the actuals on one engine. Scope is a WBS with predecessor dependencies; each task is priced by a Bill of Resources from a resource master; cost estimation rolls that up against budget; material issued against a task books actual cost on the same record; the Gantt re-flows slippage and a resource-wise view exposes contention; and project billing keeps cash in step with earned work. Because everything reconciles, estimated-versus-actual and forecast finish are always current, so drift is caught early rather than at hand-over.