Cost Overrun: See It Coming Weeks Before the Final Invoice
A cost overrun is visible weeks before the final invoice if you steer by forecast instead of by the calendar. Every Monday, take the real rate of spending, project it to the finish as if nothing changes, and compare that figure with the budget. If the forecast misses, act now, while the gap is small. Then correct the forecast with the new facts.
In this article · 10 sections
- Three ways to drive a budget
- Project over budget? Run the croissant test first
- On time and on budget: forecast both on the same Monday
- Cost overrun on big IT projects: the Monday forecast
- Project risk that threatens the company: where a tool sits in the loop
- Project delays: what six more months of calendar control cost
- "My project is too complex to forecast"
- Where the Monday forecast stops
- Two choices for the next budget review
- Published research
Less than half of all projects actually stay on budget.
It didn't have to be that way. Behind that number are teams who worked late and meant well. Some of their budgets might have held if someone had looked ahead instead of back.
Picture your own project review. The finance report arrives on the fifth. It describes money that left five weeks ago. Everyone nods.
Here is the irony. You can say to the cent what the project spent in March. You cannot say what it will have spent by the finish line.
The villain is not the team. It is steering by the rear-view mirror: a plan locked on day one, and a report that turns up after the damage.
There is another way to drive. The Jirgenson Model is a control system for goals, budgets and plans. It is scientifically proven to work (the record on Zenodo). It is new, so it could not help the projects behind these numbers. Now it can help yours.
Three ways to drive a budget
Every budget runs on one of three control schemes. Picture three drivers on one road. The first locks the accelerator and watches nothing. The second brakes when the brake lights ahead come on. The third watches three cars ahead and eases off before anyone touches a pedal. One road, three results.
| Scheme | How a budget runs on it | Where it breaks |
|---|---|---|
| 1. By plan | Approve the budget, then follow it | It never reads reality, so it cannot adapt |
| 2. By deviation | Compare spend with budget each month, then correct | It reacts after the event, often too hard or too soft |
| 3. By forecast | Project the finish each week, act on that, correct it with facts | It needs a simple model and the discipline to update it |
Why does level two run late? Between the event and the fix lies a chain: notice, measure, report, decide, act. Meanwhile the project keeps moving, so the fix often overshoots.
Project over budget? Run the croissant test first
Watch a small budget first. Andrew's coffee shop, "The Corner", buys croissants from a local bakery. His display case shows all three schemes.
By plan. He took a hundred every day, because it had always been done that way. On Tuesday customers bought seventy, and thirty went in the bin. On Saturday demand reached a hundred and thirty, and thirty guests left without one. He called it bad luck.
By deviation. He ordered from yesterday's leftovers. Thirty were left on Tuesday, so he ordered seventy for Wednesday. Wednesday's customers took about ninety. He was twenty short.
By forecast. He recorded sales by day of the week and by weather. The pattern was clear after a few weeks: about 70 on a Tuesday, about 130 on a Saturday, 15% fewer when it rains. A rainy Saturday now gets 130 × 0.85, about 110. By midday he adjusts the order if sales drift. Waste fell, and so did shortages.
Then comes the lesson that costs projects the most. Faster is not better. Take two weeks of his sales and test four ordering rules on the second week. Here is the total miss for each:
| Rule | Total miss in the week |
|---|---|
| A hundred every day | 100 croissants |
| As many as sold yesterday | 130 |
| Shift yesterday's order by a third of yesterday's error | 119 |
| As many as sold on the same day last week | 76 |
The fastest rule did worse than the fixed plan. It chased random jumps. The winner knew the pattern.
A project budget behaves the same way. React to every weekly wobble, and you correct noise. Keep this order: find the pattern first, decide which deviation deserves an answer, and only then speed up.
On time and on budget: forecast both on the same Monday
Fewer than one project in ten lands on time and on budget.
One project in two hundred delivers on budget, on time and with what it promised. One.
Those numbers did not have to look like this. When time and money are forecast side by side, the clash shows up early. Some of those teams might have traded scope while there was still money to trade. With a control system, the odds could look different.
Forecast the finish date and the final cost in the same meeting, from the same facts. When one slips, check what it does to the other. Decide while both still have room.
Cost overrun on big IT projects: the Monday forecast
Big IT projects run almost half over budget and deliver less than half the value they promised.
That gap did not have to be so wide. The people behind it were not careless. A report that arrives late leaves good people steering blind. A forecast inside the loop might have shown the cost overrun while it was still a small number.
For a project, the third level looks modest. It is a rolling forecast of cash, workload and delivery for the next three months, updated every week or every month. Here is the tool in six steps, filled in with Elena, a freelance designer selling her first online book.
- Name the number that matters at the finish. Elena: 21 book sales a month.
- Take this week's real rate. Elena: 280 visitors to her book page, and 1.5% of them buy. That is 4.2 sales in the week.
- Project it to the finish as if nothing changes. Elena: 4.2 × 4 weeks, about 17 sales.
- Compare with the goal. Elena: four sales short, and the month is not over yet.
- Act now, on a lever you control. Elena can rewrite the page headline or email her subscribers this week.
- Next Monday, correct the forecast with new facts. The forecast will err. Feedback catches the error.
Checking only at month end, Elena would learn about the shortfall too late to fix it. For a project, swap sales for spend and the month for the project. Then run the six steps every Monday.
How to avoid an overrun: never approve next month's spending without this week's forecast of the final cost on the same page.
Project risk that threatens the company: where a tool sits in the loop
One IT project in six goes so wrong it threatens the entire company.
It didn't have to come to that. Some of those companies might still be standing if the new system had stayed inside clear limits. A control system draws those limits before go-live, not after.
An IT project builds a tool. With a lever you move the process; with a tool you see and calculate. Every tool sits in one of four places in the loop.
| Place in the loop | What the tool does | Main risk | Safeguard |
|---|---|---|---|
| Notice the deviation | Compares fact with goal, raises a signal | False alarms, or silence from poor data | One source per number, thresholds set in advance |
| Build scenarios | Calculates "if nothing changes" and "if the plan works" | An elegant sum on wrong assumptions | Write the assumptions down, check the forecast against facts |
| Prepare the decision | Gathers options and consequences | The first option to hand gets quietly accepted | A person approves the order of priorities |
| Execute | Reminds, orders, sends | A mistake repeated at speed, irreversible actions | Limited rights, a log, confirmation by a person |
Check the last row before launch. A system that can pay, order or delete needs limited rights, a log and a human yes.
Project delays: what six more months of calendar control cost
Delay has a price. Stay on the fixed plan for six more months. That is about 26 Tuesdays with thirty croissants in the bin: 780 thrown away. It is also 26 Saturdays with thirty guests leaving empty-handed: 780 lost sales.
Now Elena. Suppose she checks only at month end, and the four-sale gap holds. At €29 a copy, that is €116 a month and €696 over six months. Each time she finds out when the month is already gone.
And the human cost: another Friday call where you explain, again, why the number moved.
"My project is too complex to forecast"
It does not need to be perfect. It has to beat the rear-view mirror, and it keeps feedback attached.
Here is the honest limit. A forecast built on a poor model can do worse than simple feedback. So the schemes work together: the forecast leads, and the weekly comparison keeps it honest.
Start with one number: the final cost of your biggest project, forecast next Monday.
Where the Monday forecast stops
The weekly forecast treats the symptom: you see the overrun coming instead of reading about it.
The cause is still there. You have no written rule for which gap deserves an answer, so every wobble can start a fire drill. And you have no rule for when to change the plan and when to change the goal itself.
Two steps close that gap.
- Zone thresholds and the red protocol. Where normal ends, where you act, and what to save first when several numbers turn red. Chapter 4.
- Steady mode and manoeuvre. The tolerance corridor along the route, and the written condition for revising the plan or the goal. Chapter 10.
The forecast is one piece of a whole loop: goal, state, error, levers, plan, forecast. Without the next two steps, it shows you the overrun. It does not yet tell you how hard to react. For the checks to run before a project even starts, read why projects fail.
Key takeaways
- A budget runs by plan, by deviation or by forecast. Only the forecast sees the finish.
- Faster is not better. Find the pattern before you speed up the response.
- Every Monday: real rate, projection to the finish, gap, one action, correction.
- Forecast time and money in the same meeting, from the same facts.
- Look ahead three cars, not at the brake lights.
Two choices for the next budget review
You have two choices. Wait for the month-end report, find out what the project spent five weeks ago, and hope the finish looks better. Or forecast the final cost next Monday, while the gap is still small.
The forecast shows you the overrun early. The zone thresholds, the red protocol and the tolerance corridor tell you how hard to steer once you see it.
Picture next Monday. One line on the page reads "final cost, forecast", and you can still change it.
Test the logic for free: Chapter 1, with the refusal test. Or get the complete control system on Kindle now, on Amazon. The full method comes as a Kindle book, from the first goal to the forecast.
Published research
It is scientifically proven that the Jirgenson Model works. The published experiment, its record and its data:
- Zenodo (DOI): 10.5281/zenodo.23964934
- Hugging Face: E5 Jirgenson Model blind test
- Kaggle: E5 blind test dataset
- GitHub: experiment folder
- Wikidata: dataset Q142022866, author Q141981336
- ORCID: 0009-0001-3034-3552
The full chapter, with every calculation, is in the book.
Buy on AmazonQuestions people ask
What is cost overrun in project management?
Cost overrun means the final cost ends above the approved budget. A weekly forecast can show it long before the final invoice. Project the real weekly rate of spending to the finish, compare it with the budget, and act on the gap.
How do you stop a project going over budget?
Move from the calendar to the forecast. Each Monday, forecast the final cost and the finish date from this week's facts. Act on the gap while it is small.
Why do IT projects fail so often?
A report that arrives after the money has gone cannot steer, and a new system can act at speed without limits. Forecast the finish every week. Give any tool that pays, orders or deletes limited rights, a log and a human yes.
This topic is covered in Chapter 9, Three ways to control: from the calendar to the forecast of Steer, Don't Guess: Setting Priorities, Reading the Numbers and Correcting Course in Business and Life. The numbers in the examples are illustrative; the book states its limits in Appendix G.
Read Chapter 1 free
The Introduction and Chapter 1, with the refusal test, about 9,500 words.