Slippage and Trend Analysis
Last reviewed 9 September 20262,456 words11 min read
Reading three months of updates — one update is a data point, three are evidence
🟩 In one line: Slippage is how far a forecast date moved since the last accepted update; trend is three or more of those movements read together, and the trend — not the latest variance — tells you whether the project is recovering, holding or sinking.
👤 Who this is for: J/M/S. Prerequisites: data-date, statusing-a-schedule, forecasting-honestly, cpli-and-bei.
First, let's be honest about why this page exists
Most monthly narratives report one number: "forecast completion is 32 days beyond the contract date." That number is true and nearly useless on its own. It does not say whether last month it was 12 or 40, whether the movement came from a single late delivery or from a structure cycle that has never once hit its planned duration, or whether the same three activities have been driving the path since March.
The narrative that gets taken seriously is the one that says "32 days, up from 25 last month and 18 the month before; slipping roughly 7 days a month for three months; the driver has been the tower structure cycle throughout; at this rate completion moves another 40 days before structure tops out." That is a trend. This page shows how to build and read one.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Why it matters here |
|---|---|---|
| SCL Delay and Disruption Protocol 2nd ed., Core Principle 1 and Guidance Part B | Programme updated regularly with actual progress; records kept so that the effect of delay can be seen contemporaneously | The sequence of accepted updates is the trend record |
| FIDIC 1999 Cl 8.3 / 2017 Cl 8.3 | Revised programme whenever the previous one is inconsistent with actual progress or obligations | A three-month slippage trend is exactly that inconsistency |
| FIDIC 1999 Cl 8.6 / 2017 Cl 8.7 (Rate of Progress) | Engineer may require revised methods where actual progress is too slow to meet the completion date | Trend is the evidence the Engineer will use — get to it first |
| NEC3/NEC4 Cl 32.1 | Revised programme shows actual progress and its effect on remaining work, and how the Contractor plans to deal with delays | "Its effect" means the movement, not just the new date |
| DCMA 14-Point, Metrics 13 (CPLI) and 14 (BEI) | Threshold 0.95 on both | Meaningless as single values; useful as a monthly series |
| GAO Schedule Assessment Guide, Best Practice 9 | Update the schedule using actual progress and logic; document trends and variances | Trend reporting is named as a best practice, not an extra |
| AACE RP 53R-06 (Schedule Update Review) | Compare each update to the previous update as well as the baseline | Two comparisons every month, not one |
| PMI Practice Standard for Scheduling, 2nd ed. (schedule maintenance) | Variance and trend analysis as part of every update cycle | Same instruction from the PM side |
🟢 Rule: every update is compared twice — to the accepted baseline (are we late?) and to the previous accepted update (are we getting later?) — and the second answer is carried in a trend register that is never reset.
How it actually works
1. Two comparisons, every month
| Comparison | Answers | P6 method |
|---|---|---|
| Current update vs accepted baseline | How far from the contract plan? | Project baseline = accepted BL from the register; column Variance – BL Project Finish Date |
| Current update vs previous accepted update | Which way, and how fast, are we moving? | Assign previous update as Primary User Baseline (Project → Assign Baselines); column Variance – BL1 Finish Date; then Tools → Schedule Comparison for the cause |
The baseline comparison tells you the size of the problem. The previous-update comparison tells you whether the problem is growing. Only the second one is a trend input.
2. The trend register — one row per data date, never reset
Keep it in the same workbook as the quantity sheet, one row per update, for the life of the project. Columns:
| Column | Note |
|---|---|
| Data date | Same calendar day every month |
| Baseline in force | From the baseline register — a revision here is flagged, never silently absorbed |
| Contract completion | Current contractual date incl. awarded EOT |
| Forecast completion | From the network, not from the recovery target |
| Variance vs contract (days) | Positive = late |
| Movement vs previous update (days) | The slippage figure |
| Slippage ratio | Movement ÷ working days elapsed in the period |
| BEI / CPLI | From the accepted baseline |
| Planned % / earned % | Weighted by manhours or cost |
| Driving activity (ID) | The first critical activity behind the data date |
| Cause tag | One of: duration growth / logic driven / scope added / restraint (approval, access, material) |
Also track the same movement for each contractual milestone and for the top 3 near-critical paths (float trend). A completion date that holds while the second path loses 15 days a month is a completion date about to move.
3. The slippage ratio — the one number that reads itself
Slippage ratio = days the forecast completion moved ÷ working days in the period.
| Ratio | Meaning |
|---|---|
| 0 | Critical path progressed exactly as planned |
| 0.3 | Losing about a week a month — recoverable with modest measures |
| 1.0 | Standstill on the critical path — every day that passed was lost |
| > 1.0 | Worse than standstill — rework, logic added, or remaining durations growing faster than time passes |
A ratio above 1.0 for two consecutive months means the forecast is not yet honest, whatever the site says.
4. Finding the cause, not the biggest variance
The activity with the largest variance is rarely the cause; it is usually at the end of the chain. Work back along the longest path to the first activity behind the data date, then open Schedule Comparison on that activity and ask which of the four it is:
| Cause | What Schedule Comparison shows | Typical Gulf example |
|---|---|---|
| Duration growth | Remaining duration higher than original − elapsed | Structure cycle achieving 9 days against 7 |
| Logic driven | Late finish inherited from a predecessor; own RD unchanged | Façade waiting on a slab edge that moved |
| Scope added | New activities under the path | Variation fragnet incorporated this month |
| Restraint | Start On or After moved; or an activity waiting on approval | Material approval cycle at 35 days against 21 in the SBM |
Tag the register with one of these. After three months the tags tell you whether the project has a productivity problem, a sequencing problem or a client problem — and those three are argued very differently.
5. Extrapolating — carefully
The trend is not a prediction, but it is a sanity check on the network. If the network forecast has held at "+32 days" for three months while the trend register shows +18, +25, +32, the network is being managed to a number. Use the three-way check from forecasting-honestly: network forecast, trend extrapolation and remaining manhours ÷ achieved monthly output should agree within a few weeks. Where they don't, the network is usually the one that is wrong.
6. What a baseline revision does to the trend
A revised baseline moves the yardstick, not the work. Keep the register continuous, add a row note ("BL1 accepted, contract completion +25 days"), and report movement vs previous update across the revision without a break. Restarting the register at zero after a re-baseline is the oldest trick in the book and every experienced reviewer knows it.
🟥 Where people go wrong
- Reporting one update as if it were a trend. A 3-day movement this month is noise if last month was −5 and the month before +4; it is a crisis if the two before were +12 and +20. Never quote a variance without the previous two.
- Comparing to the baseline only. The baseline says how late you are; only the previous update says how fast. A project 40 days late and holding is in better shape than one 15 days late and slipping 10 a month.
- Chasing the biggest variance instead of the first one. The 60-day variance on Handover is a symptom. Trace back to the first critical activity behind the data date and diagnose there.
- Trending percent complete instead of dates. Percent can climb steadily while the critical path stands still, because non-critical work is being done. Trend the forecast completion, the milestones and the critical-path float. Percent is a supporting figure.
- A forecast that never moves. If the forecast holds at the same date for three months while achieved rates are below plan, remaining durations are being trimmed to hold the date. The trend register exposes this: flat forecast, falling BEI, rising slippage on near-critical paths.
- Resetting the register at a baseline revision. The revision goes in as a flagged row. The movement series continues. Anything else is hiding history.
- No register at all, so every narrative starts from memory. "It was about 20 days last month, I think." That sentence loses arguments. Four hours to set the register up, ten minutes a month to maintain it.
⚖️ When you're challenged
"Completion only moved 4 days this month. Why are you making a fuss?" Because it moved 6 the month before and 9 before that, and the same activity has been driving it every time. Four days is not the story; three months of movement in one direction is. If we do nothing, the trend says another 25 to 30 days before topping out.
"Just report against the baseline. That's what the contract says." The baseline comparison is in the narrative and it always will be. The previous-update comparison is in addition, because it's the one that tells us what to do next month. Clause 8.3 asks for a programme consistent with actual progress — the trend is how I show that consistency.
"You're extrapolating. The network says 32 days and that's the forecast." The network is the forecast, agreed. But the network said 32 last month too, and the month before, while the site lost 8 days of structure cycle each month. When the network and the trend disagree by that much, one of them is wrong, and I'd rather find out which in this meeting than at handover.
"Why does the second critical path matter? It still has float." It had 22 days of float in June, 14 in July, 6 now. Two more months at that rate and it's the critical path, and it ends in a trade we haven't mobilised yet. That's the reason to act now while it's still cheap.
📄 Related pages
- Forecasting honestly — the remaining durations the trend is built on
- CPLI and BEI — the two indices that belong in the register
- Near-Critical Paths — why the second path's float trend matters
- Schedule Narrative — where the trend table lives
- P6 Schedule Comparison — finding the cause behind each movement
- Building a Recovery Plan — what to do once the trend is read
- Earned Schedule — the time-based EVM view of the same movement
- Baseline Approval and Control — how a revision is flagged in the register
✏️ Worked example
A mid-rise residential block in Sharjah, 6-day site calendar, contract completion 30 April. Three consecutive accepted updates:
| Data date | Contract completion | Forecast completion | Variance vs contract | Movement vs previous | Working days in period | Slippage ratio | BEI | CPLI | Driver | Cause tag |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 Jun | 30 Apr | 18 May | +15 | — | — | — | 0.91 | 0.97 | Structure L8 slab | Duration growth |
| 1 Jul | 30 Apr | 29 May | +24 | +9 | 25 | 0.36 | 0.88 | 0.95 | Structure L11 slab | Duration growth |
| 1 Aug | 30 Apr | 12 Jun | +36 | +12 | 26 | 0.46 | 0.84 | 0.93 | Structure L14 slab | Duration growth |
Near-critical paths (float at the contractual completion milestone):
| Path | 1 Jun | 1 Jul | 1 Aug |
|---|---|---|---|
| Façade unitised install | 21 | 15 | 8 |
| Lift installation | 33 | 30 | 29 |
| MEP first fix → finishes | 18 | 12 | 5 |
Reading it:
- The cause tag has been the same for three months: the structure cycle. Schedule Comparison on each driving slab shows remaining durations growing — achieved cycle 9 working days against 7 in the SBM.
- Slippage ratio is rising (0.36 → 0.46). The project is not holding; it is getting later faster.
- Eight floors remain. At 2 days lost per floor, the trend says roughly 16 more days before topping out, taking the forecast to late June. That agrees with the three-way check (remaining structure manhours ÷ achieved monthly output gives topping-out in the first week of October, consistent with a late-June completion).
- MEP-to-finishes float has fallen from 18 to 5 while the structure moved. Once structure recovers, this becomes the critical path — and it ends in a finishing subcontractor not yet mobilised.
What went in the narrative: the table above, a one-paragraph diagnosis naming the structure cycle and the achieved 9-day rate, the projected further movement, the near-critical warning, and a reference to the recovery options being prepared (see building-a-recovery-plan). No adjectives.
📖 References
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 1; Guidance Part B (records and programme updating)
- FIDIC Conditions of Contract for Construction, 1999, Cl 8.3, 8.6; 2017, Cl 8.3, 8.7 (check the edition in your contract)
- NEC3 / NEC4 Engineering and Construction Contract, Cl 32.1 (check the edition in your contract)
- DCMA 14-Point Schedule Assessment, Metrics 13 and 14
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 9
- AACE International RP 53R-06, Schedule Update Review – As Applied in Engineering, Procurement and Construction
- PMI Practice Standard for Scheduling, 2nd ed., schedule maintenance
- Oracle Primavera P6 Professional User Guide — Assign Baselines; Schedule Comparison; variance columns
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about slippage and trend analysis. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience