How to calculate a project's delay and forecast the real completion date
A project's delay is the difference between the progress you should have by today and the progress you actually have, expressed in time. It is calculated by comparing actual progress against planned progress and forecasting the completion date under an explicit assumption about the future pace. The key word is explicit: without stating the assumption, the forecast can neither be argued nor defended.
Saying “we are behind” is useless. Saying “we are 8 points below plan, running at 75 % of the planned speed, and if nothing changes we finish 100 days late” is a sentence you can make a decision with.
First: two different delays
They get confused constantly and they do not mean the same thing.
Progress delay. You have work outstanding that you should already have built. It is measured in percentage points or in money.
Schedule delay. You are going to finish after the committed date. It is measured in days.
They are not proportional. A project can be 8 points behind on progress and have no schedule delay at all, if what is outstanding is off the critical path or the schedule had float. And the other way round: a small delay on a critical activity can move the whole completion date.
The delay that matters contractually is the schedule one. Progress is the symptom.
The three methods
I use the same example in all three so the difference shows. A 300-day project, we are on day 120, with 32 % planned progress and 24 % actual.
Method 1 · Linear extrapolation
The most intuitive and the most wrong.
Actual speed = 24 % ÷ 120 days = 0.20 % per day
Days for the remaining 76 % = 76 ÷ 0.20 = 380 days
Total forecast duration = 120 + 380 = 500 days
Forecast delay = 200 days
Why it is wrong: it assumes the project advances at a constant speed, and it does not. The first 120 days include site setup and foundations, which are inherently slow. Projecting the rest of the project at that speed penalises you twice for the same phenomenon.
This method always exaggerates the delay early and understates it late. It only works once you are past the halfway mark and running steadily.
Method 2 · Performance index
The industry standard and a good starting point.
Actual progress 24
Index = ──────────────────── = ──── = 0.75
Planned progress 32
Forecast duration = 300 ÷ 0.75 = 400 days
Forecast delay = 100 days
What it assumes: that the ratio between your pace and the planned one holds. Since the schedule already carries the S-curve shape, this forecast does not penalise the slow start. That is why it gives 100 days instead of 200.
Its limit: it assumes relative performance is stable. If the delay came from a one-off cause that is already fixed, the method overstates it. If the cause is still active and worsening, it understates it.
It is the best quick method. It works for reporting and for raising the alarm.
Method 3 · Rescheduling with actual output rates
The only one that is any use for deciding.
Instead of forecasting from an aggregate index, you rebuild the remaining schedule with the output rates you are measuring on site.
- List the outstanding quantities per line item.
- Apply the actual measured output rate, not the budgeted one.
- Work out durations with the crews you actually have.
- Rebuild the sequence respecting the dependencies.
- Read off the new completion date.
It is more work and it gives a very different number, because it breaks things down. It almost always reveals that the delay is concentrated in two or three items and the rest is fine. That changes the conversation entirely: instead of “the project is slow”, you have “masonry is running at 60 % of the planned output and dragging everything else with it”.
And that sentence you can act on.
Comparison
| Method | Result | Effort | What it is for |
|---|---|---|---|
| Linear extrapolation | 200 days | Low | Almost nothing. Distorts early on |
| Performance index | 100 days | Low | Alerting and reporting |
| Real rescheduling | Varies | High | Deciding what to do |
The healthy practice is to use the index as a weekly traffic light and trigger the rescheduling when it crosses a threshold — say 0.90 sustained for three weeks.
What makes a forecast defensible
A delay figure is going to be argued over. What settles the argument is not the method but three things:
That the baseline schedule is current. If there were change orders, suspensions or authorised extensions that were never incorporated, you are measuring against a false baseline and anyone can take your calculation apart in a minute.
That the assumption is written down. “Forecast on the assumption that the current output rate holds” is a sentence that saves meetings. Without it, your forecast looks like a claim about the future rather than a scenario.
That the causes are documented and dated. This is the difference between a delay you can pass on and one you absorb yourself. A rain day recorded at the time, with evidence, is a day that can support an extension of time. The same day remembered three months later is not.
Frequently asked questions
- When does a delay become worrying?
- As a rule of thumb: an index above 0.95 is noise, between 0.85 and 0.95 is watch it, below 0.85 sustained calls for action. But the trend matters more than the level. An index of 0.80 that is climbing is better news than one of 0.90 that is falling.
- Can I recover a delay by adding crews?
- Only if the constraint is resources. If the front is not released or material is missing, more people produce no more progress and do produce more cost. There are also diminishing returns: doubling the crew on a confined front rarely doubles output, because of interference between workers.
- How do I tell my own delay from one caused by the client?
- By the cause and by the record. Fronts not released, late technical information, client-supplied materials that do not arrive, scope changes: all of that is on the client, and all of it needs to have been entered in the site record at the time. Without a contemporaneous record, attribution is an argument you usually lose.
- Should I report a forecast delay even if I can still recover it?
- Yes, with the recovery scenario alongside. A delay announced early with a plan is management. The same delay discovered late is a crisis, and it damages the credibility of everything you report afterwards.
- What if the original schedule was never realistic?
- It is more common than anyone admits: schedules built to win the tender. The honest move is to reschedule with actual output rates as early as possible and present the new scenario with evidence. The later that conversation happens, the worse it is for everyone.
Founder and CEO of Paladio. He has spent more than 15 years building financial products that touch the lives of millions of people. He writes about what he sees on site: how progress is really measured and where the money leaks.
See all their articles →
