Inherited Schedule With a Hidden Critical Path
You take over a 26-week ERP cutover that is three weeks into execution. The schedule has a three-level WBS with 480 work packages. You find: 42% of activities are level-of-effort 'project management' and 'test support' spread evenly across the timeline; the calendar is a standard five-day week even though the plant shuts down for two weeks in August and most users are on that site; the critical path runs through a 15-day lag between 'data cleanse complete' and 'load to production', which the previous PM inserted for a year-end freeze window that no longer applies; a single 40-day activity represents all integration testing; and three workstreams share one database administrator who is allocated 60%. The sponsor has just asked you to pull the finish date in by four weeks by fast-tracking.
1. What is wrong with this WBS and schedule, and what would you fix first?
Read the worked answer
Diagnose before you touch dates, because most of the four weeks being demanded may be an artefact of how the schedule was built.
Structural problems.
- Level-of-effort overload. Level-of-effort activities should not be on the critical path or carry earned value as if they were discrete work. At 42% they inflate duration, hide real dependencies, and make progress measurement meaningless.
- The 15-day lag. Lags inserted as external constraints become invisible float killers and are usually the first place real compression exists. If the freeze no longer applies, delete the lag and re-run the path.
- The 40-day integration testing activity. This is unmeasurable and uncontrolled. Decompose it into test cycles with entry/exit criteria so progress and remaining duration can be assessed.
- Calendar error. A standard five-day calendar against a two-week plant shutdown produces a schedule that is wrong by at least two weeks on any site-dependent path. Fix the resource calendars first.
- Single 60% DBA. That is a resource constraint, not a duration. Model it and let levelling show where the real queue is.
Order of work. Rebuild the calendar, remove or justify lags, replace level-of-effort with discrete deliverables, decompose testing, then resource-load. Only after the schedule is credible does compression make sense - otherwise you are fast-tracking a fiction.
2. The sponsor wants four weeks. How do you evaluate fast-tracking versus crashing, and what would you commit to?
Read the worked answer
I would not commit to four weeks from a schedule I do not yet trust, and I would say so with evidence rather than with a refusal.
Remove constraint-driven duration first. The 15-day freeze lag is not a compression technique - if the constraint is gone, that is recovered time at no added risk. Similarly, calendar corrections may move the date in either direction; find out before promising anything.
Then evaluate the two levers against risk.
- Fast-tracking: overlap design and configuration, or UAT and training. It saves time only where the dependency is discretionary, and it transfers risk into rework. Testing overlapped with build on an ERP cutover is where defects escape to production, so I would overlap training with UAT (low coupling) and not overlap data migration with configuration.
- Crashing: add a second DBA for the migration window, or add test resources. It costs money and buys time only if the resource is genuinely on the critical path and can be added without a ramp-up penalty. Adding people to a 40-day undifferentiated testing block does not work; decomposing it first may.
What I would commit to: a re-baselined critical path within two weeks, a schedule risk analysis with a P50 and P80 date, and a specific compression proposal with cost and risk stated per option. Then a decision with the sponsor, not a promise made before the analysis.
3. Before you re-baseline, what governance and control changes do you need, and how do you keep the current status report honest in the meantime?
Read the worked answer
A re-baseline is a formal change, and doing it quietly destroys whatever credibility the plan has left.
Governance steps.
- Document the current baseline and the reasons for variance: calendar error, obsolete lag, level-of-effort structure, resource constraint. Facts, not blame.
- Raise a change request to re-baseline with the revised schedule, the cost impact, and the risk impact attached. The change control board or sponsor approves it; the PM does not self-authorise.
- Re-baseline once, at a clean point, and keep the old baseline for performance history.
- Update the schedule management plan so the same defects are not reintroduced: mandatory resource calendars, a rule that level-of-effort cannot be on the critical path, a lag justification log, and a decomposition standard for testing.
Interim reporting. Until the new baseline is approved, report against the old one and state clearly that the dates are unreliable and why. Do not show green because milestones have not yet slipped - that is exactly the reporting failure that got the project here. Report the 15-day lag finding, the DBA constraint, and the calendar gap as issues with owners and dates.
Also fix measurement. Replace percent-complete on level-of-effort with milestone and deliverable-based progress, so the next status report reflects work actually finished rather than time elapsed.