Critical Path Under Pressure
Granite Foods is replacing its ERP and has a 14-week baseline plan:
| ID | Task | Duration | Depends on |
|---|---|---|---|
| A | Data audit | 3 wk | - |
| B | Vendor configuration | 4 wk | A |
| C | Interface build | 5 wk | A |
| D | Migration dry run | 2 wk | B, C |
| E | User acceptance testing | 3 wk | D |
| F | Training | 2 wk | C |
| G | Go-live cutover | 1 wk | E, F |
The vendor has now stated that user acceptance testing cannot start later than week 13 or its testing team is unavailable until the next quarter. The interface developer is available only 60% of the time. The CFO wants "two weeks of buffer added to every single task."
1. Identify the critical path, total duration, and float. What happens if the interface build runs two weeks long?
Read the worked answer
Forward pass from week 0:
- A: 0–3
- B: 3–7
- C: 3–8
- D: starts after both B (7) and C (8) → 8–10
- E: 10–13
- F: after C → 8–10
- G: after E (13) and F (10) → 13–14
Critical path: A → C → D → E → G = 3 + 5 + 2 + 3 + 1 = 14 weeks.
Float: B ends week 7 but D cannot start until week 8, so B has 1 week of float. F ends week 10 but G cannot start until week 13, so F has 3 weeks of float.
If C takes 7 weeks: C ends week 10, D starts week 10, E runs 10–13... wait, D now runs 10–12, E 12–15, G 15–16. The whole project moves to 16 weeks - a two-week slip on C is a two-week slip on go-live, because C has zero float. B's float grows to 3 weeks; F's stays at 3.
The sharper problem: in the baseline, UAT starts exactly in week 10 and the vendor's constraint is week 13 - and UAT itself takes 3 weeks. UAT has zero float against the vendor's drop-dead start. Any critical-path slip breaches it, so this constraint, not the go-live date, is the real deadline to manage.
2. How should the PM plan for the 60%-available developer and respond to the CFO's per-task buffer request?
Read the worked answer
The 60% developer. Availability is a capacity problem, not an optimism problem, so model it honestly: five weeks of effort at 60% availability is roughly 8.3 calendar weeks. Options, in order of preference:
- Level the resource - schedule C so this person is not simultaneously on other work, or split C into interfaces by system so the highest-risk integration starts first.
- Add a second developer for part of C, accepting a ramp-up and coordination cost.
- Re-sequence - start C on the interfaces not dependent on the partner system.
What not to do is schedule five weeks of work into five calendar weeks and hope. That is the plan failing before it starts.
The CFO's per-task buffer. Adding two weeks to every task fails for well-known reasons: padding is absorbed (work expands to fill the time), it obscures which task is actually at risk, and it inflates the plan without protecting the end date. Instead:
- Keep task estimates honest and hold a single schedule buffer at the end of the critical chain, sized by risk - commonly 15–30% of critical-path duration, so roughly 2–4 weeks here.
- Add smaller feeding buffers where the non-critical paths (B, F) join the critical path.
- Re-baseline with the sponsor and record the change in the change log.
This gives the CFO the protection they actually want - a date that holds - rather than the illusion of it.
3. List the top risks for this plan with a response strategy and owner for each.
Read the worked answer
Risk register (top items)
| Risk | Impact | Response type | Action | Owner |
|---|---|---|---|---|
| SSO/interface complexity exceeds 5-week estimate | Critical-path slip; misses vendor UAT window | Mitigate | Time-boxed technical spike in week 1; split interfaces by system; identify fallback manual process | Interface lead |
| Vendor testing team unavailable after week 13 | Go-live pushed a full quarter | Avoid / Transfer | Contractually confirm the window in writing; build a 5-working-day UAT start buffer; pre-agree a backup test partner | PM + Procurement |
| Interface developer only 60% available | C stretches to ~8 weeks | Mitigate | Negotiate dedicated time with functional manager; add second developer | PM + Functional manager |
| Data audit reveals dirty master data | D expands; dry run repeats | Mitigate | Early data profiling sample; define data-quality acceptance thresholds before dry run | Data lead |
| Training (F) squeezed near go-live | Adoption failure after a technically clean cutover | Accept (with buffer) | Use F's 3 weeks of float deliberately; do not consume it early | Change/training lead |
| Scope additions during UAT | Rework, re-testing | Control | Change control board; every request gets impact analysis before approval | PM |
Two points matter as much as the list: every risk has a named owner, and the responses are matched to the type of risk - schedule risk from unknowns is mitigated by buying information early, not by adding padding.