The Half-Step XER: What It Actually Proves

Two schedule updates come in a month apart. The finish date moved two weeks. The owner wants to know why. Is that real progress trouble, or did the contractor revise the plan between updates (new activities, changed logic, different durations) and let it ride under the same "update" label as everyone's actual progress? You cannot answer that by comparing the two updates directly. Too many things changed at once, and they all landed in the finish date together. This is the exact problem a half-step XER is built to pull apart.

What a half-step XER actually is

AACE 29R-03 calls the method MIP 3.4. Most schedulers just call it the half-step. The idea is simple, even though building one by hand is not: take the earlier update, keep everything about it exactly as it was, the logic, the durations, the constraints, the WBS, the activity names, and swap in only the progress fields from the later update. Actual start and finish dates. Remaining duration. Percent complete. Status. Nothing else moves.

What comes out is a third schedule sitting between the two real updates. It has the earlier update's plan and the later update's progress. Recalculate it, and whatever the finish date does is caused by progress alone. Any remaining gap between that recalculated half-step and the real later update is caused by something else: a logic change, a duration revision, an activity added or dropped.

That split is the whole point. Two updates a month apart usually differ in a dozen ways at once. The half-step isolates one variable at a time, so an analyst can say, with something to back it up, which part of a finish-date slip came from real progress and which part came from a plan change dressed up as one.

Why this is normally a slow, manual exercise

Building a half-step schedule by hand means opening both XERs, matching every activity by task ID, and copying four fields, actual start, actual finish, remaining duration, percent complete, from the later schedule onto the earlier one, row by row. Everything else in the earlier schedule has to stay untouched. Copy over a logic change by accident and the exercise is worthless: you are no longer isolating progress, you have just built a third messy schedule that nobody can fully explain.

It is also the kind of manual reconciliation that gets picked apart on cross-examination. If nobody but the analyst can reproduce exactly which rows were touched and why, the method is only as credible as the person who built it.

What the generator in Lens does

CPP Lens has a Half-Step XER tool under the CPP Forensic tab. Drop in a base schedule and an updated schedule, and it matches activities by task ID, then reports how many matched, how many exist only in the update, how many exist only in the base, and how many predecessor relationships carried over untouched.

The matching and the overlay both happen in your browser. Nothing gets uploaded for this step. That matters for the same reason it matters everywhere else in Lens: you can run this on a live dispute without sending your schedule anywhere.

What it does not do

A half-step XER is a piece of evidence, not a conclusion. It tells you what the finish date does when only progress changes and nothing else does. It does not tell you whose fault the remaining slip was, whether the logic changes stacked on top of it were justified, or what to do about any of it. That is still an analyst's job, reading the half-step result next to the real updates and the correspondence around them.

It is also built for the classic version of the method: one intermediate schedule between two updates. AACE 29R-03 also describes a more granular day-by-day variant for pulling apart concurrent delays inside a single update window. That is a heavier exercise, and still one an analyst builds by hand.