The launch that was green until it was late
A worked project-recovery story showing how milestone evidence, dependency ownership and honest status can change the management conversation.
Decision this guide supports
How do you recover control when activity looks busy but the launch forecast is no longer credible?
Key takeaways
- High activity and high percentage complete can coexist with a weak forecast.
- Milestone acceptance criteria expose unfinished work earlier than task counts.
- A recovery plan becomes credible when it connects causes, decisions, owners and dated evidence.
The situation
Northstar Services planned to launch a customer portal in twelve weeks. The dashboard showed 82% complete and every workstream reported green. Developers were closing tickets, training slides were drafted and the launch announcement had a date.
But the plan grouped work by team and tracked activity rather than accepted outputs. Data migration, identity, support readiness and customer journeys each looked locally healthy. Nobody could show that they would work together on launch day.
The warning hidden in plain sight
The first end-to-end rehearsal was due in week ten, leaving two weeks to correct any cross-system failure. Its entry was a single milestone with no acceptance criteria. Three dependencies feeding it had owners, but their approval dates were not linked to the rehearsal.
When the migration lead asked for a decision on duplicate customer records, the issue entered a log. It did not change the milestone forecast or the overall RAG. The dashboard recorded the issue but failed to manage its consequence.
The project was reframed around evidence
- 1The team replaced percentage-complete reporting with five acceptance milestones: identity proven, priority journeys accepted, migration reconciled, operations ready and launch approved.
- 2Each milestone received acceptance criteria, an accountable owner and the dependencies required to pass.
- 3The migration decision was linked to the rehearsal and given a latest safe decision date.
- 4RAG definitions were reset: amber meant recovery remained within team authority; red meant the launch needed a sponsor decision.
- 5The one-page view showed current forecast, baseline, top exceptions and decisions rather than every task.
The uncomfortable decision
The evidence showed that the original launch date was no longer credible without accepting a material data-quality risk. The sponsor received three explicit options: launch on time with restricted migration scope, delay the full launch by three weeks, or run a controlled pilot with a smaller customer group.
The team recommended the pilot. That preserved learning and market momentum without pretending the full migration was ready. The project turned red for one reporting period because it was outside the original launch tolerance; the red status made the decision visible rather than describing failure.
What made the recovery plan credible
| Weak signal | Controlled replacement |
|---|---|
| 82% complete | Three of five acceptance milestones passed |
| Migration issue logged | Decision owner, deadline, options and launch impact linked |
| All workstreams green | Overall red because the launch tolerance was breached |
| Launch date shown once | Approved baseline and current forecast both visible |
| Rehearsal planned | Entry criteria, exit criteria and dependency dates agreed |
The outcome — and the limit of the story
In this teaching scenario, the pilot launches on the revised date, migration defects fall during the controlled period, and the full launch follows. The important result is not that every recovery ends neatly. It is that leadership chose an explicit trade-off while options were still available.
Real recoveries depend on context, contracts, regulation, architecture, team capacity and stakeholder appetite. The method does not guarantee success; it improves the quality and timing of decisions.
Questions to use on your own project
- Which milestone first proves that separate workstreams function together?
- What must be true for that milestone to be accepted?
- Which unresolved dependency has the earliest latest-safe decision date?
- Does the current status describe the outcome forecast or the team’s effort?
- What options remain if the current plan is no longer credible?
Sources & method
This guide is RuruPilot’s practical synthesis. Definitions and established control principles are grounded in the primary sources below; examples, operating conventions and recommendations are our interpretation unless stated otherwise.
- 1Schedule Assessment Guide: Best Practices for Project Schedules
U.S. Government Accountability Office. The scenario applies principles of logical sequencing, traceable dependencies, valid critical paths and schedule control.
- 2What is project management?
Association for Project Management. The scenario uses the project controls, risk, change and stakeholder responsibilities described by APM.
Talk it through
Want to apply this to your own project?
Tell us what you are facing. We can discuss project support, practical PM training, consultancy, or how RuruPilot could support your team.
Prefer email? Write to hello@macrocyra.com.