But curious how you structure resource loading when a 120-site 5G upgrade slips two weeks mid-sprint; I’m re-baselining in P6 and debating whether to crash integration or shift civil teams to backfill dependencies. Looking for proven patterns that hold budget while keeping commissioning on the critical path.
In P6, add a ‘Ready-for-Integration (RFI)’ milestone per site and re-sequence so civils chew through power/backhaul blockers, then only crash integration on nodes gating cluster acceptance. We did this on a 96-site build and, by batching turn-ups per ring, kept ‘commissioning on the critical path’ and shaved about 8% OT without blowing vendor minimums. If permits are the drag, crashing just parks techs, so run a 2-week rolling freeze on late scope and let optimization trail by a week — think Tetris, not whack-a-mole.
When our 128-site 5G upgrade slipped two weeks, we froze the next two integration windows as “gates” and used P6 to push civils into power/backhaul punch while pre‑staging configs so I&C only crashed the cluster lead sites. That kept commissioning on the critical path without spraying OT; set a 10‑day freeze lookahead (Start On or After on the integration WBS) so late sites auto‑roll to the next wave. If you want a quick gut-check on where crashing pays, PMI’s summary is decent: https://www.pmi.org/learning/library/schedule-crashing-fast-tracking-11119.
Quick example: we keep a 12‑site rolling buffer per cluster and run a ‘soft turn‑up’ 3–4 days ahead to pre‑load configs, validate alarms, and stage scripts, so the night‑of is just RF sweep and KPIs; in P6 I cap integrators at 85% Max Units/Time and level, shifting the slip to rigging where overtime is cheaper. If you don’t have solid script automation, @Riley’s resequencing‑first take is safer.