The Slipping Baseline
A 14-month ERP implementation has 620 tasks and 9 work packages. At month 6 the PM reports the project is 'on plan' because the finish date still reads 31 March. You notice that three work packages have had their remaining duration manually reduced by 20% twice in the last month, the baseline is unchanged, and 41 tasks are marked 100% complete but still carry remaining work. Two critical-path tasks have actual starts logged before their predecessors finished, and the resource calendar for the integration team shows a public holiday that was not applied. The steering committee meets in five days and wants a defensible status.
1. Diagnose why the finish date is misleading and describe the sequence of corrective actions you would take before the steering committee meeting.
Read the worked answer
The finish date is being held by three separate distortions, and each must be treated differently.
Remaining-duration compression. Reducing remaining duration without changing scope or logic is a silent schedule compression. It does not change the baseline, so variance analysis against baseline looks clean while the forecast quietly absorbs the pain. Restore remaining duration to a logic-derived value (duration minus actuals, with calendar applied), then re-forecast. If the compression was a legitimate attempt to model a faster approach, it belongs in a change request with a revised baseline, not an edit.
Percent-complete with remaining work. A task at 100% complete with remaining work is a data-integrity contradiction. Either the physical work is done (remaining work should be zero) or it is not (percent complete is overstated). Reconcile against timesheets and deliverable acceptance, then correct. This matters because earned value and physical percent complete feed the forecast.
Out-of-sequence progress. Actual starts logged before predecessors finish are legitimate in reality but corrupt the forward pass if the logic is not updated. Decide per task: was the predecessor actually finished (then update its actual finish), or is this true fast-tracking (then add a finish-to-start lag or a start-to-start relationship so the model reflects reality).
Before the meeting: run a schedule health check (out-of-sequence, hard constraints, negative float, missed mandatory dependencies), recalculate with the corrected holiday calendar, re-baseline only through change control, and present both the baseline finish and the forecast finish with the variance explained. Do not present a single 'on plan' date.
Sequence matters: fix data integrity first, then logic, then calendar, then recalculate, then report. Correcting the calendar after recalculating invalidates the result.
2. The sponsor argues that re-baselining now would 'hide the slippage.' How do you respond, and what governance mechanism do you propose?
Read the worked answer
The sponsor is right about the risk and wrong about the remedy. Re-baselining without a record does hide slippage; refusing to re-baseline at all hides it differently, because a baseline that no longer reflects a feasible plan stops being a useful control and becomes a number nobody trusts.
The resolution is to separate the two purposes. Keep the original baseline as the performance measurement baseline so earned value, variance-at-completion, and historical comparison remain honest. Create a current approved baseline (or a forecast/re-baseline layer) that reflects the corrected logic, calendar, and approved scope, and report both side by side: original baseline finish, approved current baseline finish, and forecast finish, with the delta attributed to specific causes (calendar correction, out-of-sequence logic, scope change, genuine slippage).
Governance: route the re-baseline through the change control board with a documented impact assessment (cost, resources, downstream dependencies), require sponsor sign-off above a defined threshold (for example, any change to a milestone or more than 10 working days to a critical-path finish), and log the reason code. Publish a variance waterfall so the committee can see exactly which causes moved the date.
This gives the sponsor what they actually want - accountability - while giving the team a plan they can execute against. The failure mode to avoid is re-baselining quietly at the work-package level, which is what created this situation.