Eight workstreams, one deadline that won't move

A new rail operation had to be launched from scratch: a new operating contract, a new organisation, more than 80 people to recruit and train, and several business-critical IT systems to implement in parallel – all inside six months. The launch date was fixed. Passengers don't wait for a maintenance system to be finished a week late.

That situation exposes the most common mistake in large-scale launch projects: the workstreams – operations, vehicles, maintenance, IT, procurement, safety, communications – get planned as separate sub-projects with their own timelines, instead of as one whole under shared control. Each stream delivers against its own plan. Nobody sees the full picture until the dependencies between streams have already collided.

Why it breaks exactly when it's hardest to see

As long as every workstream reports green on its own, the programme looks like it's on track. The problem is that a delay in one stream – a safety clearance that drags on, an IT integration that isn't finished – rarely stays contained. It moves to the next: staff can't be trained on a system that isn't live, vehicles can't enter service without an approved maintenance setup, control room procedures can't be tested without a staffed organisation.

Without daily control across every stream, and without a clear decision structure for who gets to make the trade-off when something collides, these dependencies surface too late – often the same week as the launch. By then there's neither the time nor the authority left to fix them calmly.

What actually holds a zero-margin launch together

In the project behind this piece, full accountability sat with one team from day one, with daily control across every workstream: operations, vehicles, maintenance, IT, procurement, safety and communications. Follow-up and risk management ran continuously, tied to a clear decision structure with tight steering-committee reporting – not monthly status theatre, but a mechanism for making trade-offs the same day a risk was spotted.

The second decisive piece was that the final week was never treated as slack. It was scheduled as its own milestone: a full system test, a walkthrough with staff, and a live-operations simulation – a dress rehearsal for launch day before it counted for real. That's the difference between finding a fault at six in the morning on day one, and finding it in a simulation a week earlier, while it can still be fixed without a single passenger noticing.

The result of managing the whole, not the parts

Six months after kick-off, all 80-plus staff were recruited, trained and ready, the critical IT systems (including the EAM maintenance-planning system) were tested and implemented, and every safety approval was in place. The launch happened on schedule – no delays, no major service disruptions.

That isn't luck. It's what happens when you stop running eight separate sub-projects and start running one whole – with daily follow-up, a decision structure people actually use, and a dress rehearsal treated as a mandatory milestone, not an afterthought.

Concrete takeaway: If your project has a deadline that can't move and more than three workstreams that need to stay in sync, schedule a full-scale dress rehearsal as its own milestone – with time left afterwards to fix what breaks. Don't wait until day one to find out whether it holds.