SmartPM has put half-step delay analysis on a lot of project dashboards. Load two consecutive Primavera P6 updates and its Windows Half-Step method reports how far the completion date moved in that window, and splits the movement into what SmartPM calls experienced critical path delay (progress that fell short on the driving path), actual acceleration (progress that gained time) and planned impact (changes to the remaining plan that moved the finish).
That is genuinely useful. On a large program it turns a monthly argument about "why did the date move" into a table. We use SmartPM on a national general contractor's data center program, and it is often the fastest way to see where a month went wrong.
But a SmartPM half-step table is the start of an analysis, not the end of one. The software can only split what is in the two updates you gave it. When that result is about to support a time extension request, or an owner is about to use it to reject one, someone needs to check it against the native P6 files. Here is what we check.
1. Are the two updates clean?
A half-step analysis trusts the updates. If the end-of-window update has problems, the split inherits them:
- Actual dates after the data date, or progress recorded on activities whose predecessors have not started.
- Out-of-sequence progress handled differently from one update to the next (retained logic in one, progress override in the next).
- A data date that moved by more or less than the reporting period, which changes what counts as "in the window."
- Calendar or constraint changes made in the same update as progress.
Any of these can shift days between "experienced delay" and "planned impact." Before trusting the table, we open both XER files and confirm the progress is real and the scheduling options did not change.
2. What is inside "planned impact"?
Planned impact is the bucket for every non-progress change: added activities, deleted activities, changed durations, new logic, new constraints. SmartPM shows the total. A claim needs the contents.
A month with zero planned impact can still hide offsetting changes: a new owner-directed scope fragnet that added 20 days, and a compressed downstream duration that took 20 days back. The net is zero; the story is not. For a time extension request, the owner's added scope is the entitlement and the compression may be the contractor's mitigation. Both belong in the narrative, so we list the individual revisions behind each planned-impact number.
3. Does the window size hide concurrent delay?
Half-step results depend on the order in which changes are applied. With one large window, two delays that overlapped can be reported as one, or the second can look like it caused nothing because the first already moved the date. AACE Recommended Practice 29R-03 (MIP 3.4) addresses this by stepping through the period in smaller increments.
When a window contains more than one significant event, especially one from each side, we shorten the windows or step through the critical part of the period so concurrency is visible rather than buried.
4. Does the critical path in the table match the schedule?
SmartPM reports delay on the driving path as the software calculates it. We confirm that path in P6 itself, with the same scheduling options the project uses. If the project schedules on retained logic and the comparison effectively uses progress override, or if near-critical paths are within a few days, the "driving" activity in the table may not be the one that controlled the finish.
5. Can each delay day be tied to a cause and a party?
A half-step table tells you how much time moved and whether it came from progress or from revisions. It does not tell you why. A time extension request has to connect each block of experienced delay to an event: a late owner decision, a late delivery, a differing site condition, a predecessor trade. That connection comes from the project record (RFIs, daily reports, correspondence), not from the software.
Where this leaves a contractor, and an owner
For a contractor, a checked half-step result is strong support for a time extension request: it shows the delay was experienced in the work, not created by rewriting the schedule.
For an owner, the same check is how to review a contractor's request: are the "experienced" days really progress, or revisions labeled as progress? Did a compressed downstream duration hide the contractor's own delay?
CPM Pros does both. We use SmartPM, check its half-step results against the native P6 updates, and turn the result into a time extension request or a rebuttal that holds up. For the method itself, see The Half-Step: Telling Real Delay from Creative Scheduling.
Send the two updates (XER files) and the SmartPM output, and we will send back a written quote, typically within 3 business days.