A Stalled Percent Complete on an 18-Month Infrastructure Program
At the month-6 status cycle of an 18-month infrastructure program, the contractor reports an SPI of 0.94 and a CPI of 1.02. The earthworks package shows 62% complete - identical to last month - although the plan called for 58% last month and 71% this month. Three activities show actual starts dated before their predecessors finished. The data date is 10 days behind the reporting cut-off because the site team submitted updates late. The contractor argues that an SPI below 1 is 'just a formula artifact' and that the project is fine because CPI is above 1. The sponsor wants a straight answer on whether the program is late.
1. Is the contractor right that SPI below 1 is a formula artifact? Assess the evidence and say what you would do about the stalled 62%.
Read the worked answer
On SPI
- SPI is planned value versus earned value at a point in time. It is sensitive to phasing: a program front-loaded with procurement can show SPI below 1 while physical work is on track, and a program behind on the driving path can show SPI near 1 if earned value accrues on non-critical work.
- So SPI alone is genuinely weak evidence - but that cuts both ways. It is not proof the project is fine; it is proof you need a duration-based view (earned schedule or schedule variance in days) plus direct critical-path status.
- CPI above 1 says nothing about time. Treating it as reassurance is a category error.
On the stalled 62%
- Percent complete that does not move while the plan advances is the classic signature of either a wrong remaining-duration estimate or a measurement that is not tied to physical output.
- Re-measure by verifiable units (cubic metres placed, poles set), not by elapsed time, cost booked, or supervisor judgment.
- Re-estimate remaining duration with the crew leads. If 62% complete is right but the remaining 38% takes as long as the first 62% did, the task is effectively at 62% forever and the forecast is wrong.
- Check whether the earthworks activities sit on the driving path - if so, the program is late regardless of the aggregate index.
2. Three activities started before their predecessors finished. What are the possible explanations, and how do you handle each in the schedule update?
Read the worked answer
Possible explanations
- The reported status is wrong - dates keyed incorrectly or progress claimed ahead of reality. Correct the status and address the reporting process.
- The logic was wrong - the field found a legitimate way to start early (partial release, area-by-area handover). The schedule did not reflect how the work can actually be built.
- Deliberate overlap without a modeled relationship - fast-tracking happening informally, with rework or hold-point risk that nobody has assessed.
Handling in the update
- Do not simply key the actual start and let the software produce out-of-sequence flags. Out-of-sequence progress distorts float and can hide the true driving path.
- For case 2, re-sequence the logic to reflect reality (e.g., split the predecessor into work-done and work-remaining, or use SS with the correct lag), document why, and record it as a logic change.
- For case 1, correct the record - a schedule built on inflated progress is worse than a late one.
- For case 3, treat it as informal fast-tracking: assess the risk it introduced, make it explicit in the logic, and note it in the schedule narrative.
Afterwards
- Re-run CPM and confirm the driving path; out-of-sequence conditions often mask that the real critical path has moved.
3. The data date is 10 days behind the reporting cut-off. What is the correct treatment, and what do you tell the sponsor?
Read the worked answer
Correct treatment
- The data date must represent the point in time to which all status is reported. It cannot be later than the latest reliable status, and it must never be set in the future to make the schedule look current.
- Two consistent choices:
- Hold the data date at the true status point, accept that the report covers a period 10 days old, and state that clearly. Trend integrity is preserved.
- Advance the data date only if the site team can genuinely status everything up to the later date; a partial update with a moved data date is the worst option, because the schedule then mixes fresh and stale status with no way to tell them apart.
- Fix the cause: agree a submission deadline working back from the reporting cut-off (e.g., status due 3 working days before the report), and make late submission an escalation item.
What the sponsor hears
- A direct answer: the driving path has slipped X days; earthworks is the exposed package; the reported SPI understates or overstates the slip for these specific reasons; here is the forecast finish and confidence.
- Report the data-quality caveat once, with the corrective action - not as a standing excuse.
- Never present a schedule as current when its status is 10 days stale; credibility is the scheduler's only real asset.