Launch readiness isn’t decided on launch day. It’s decided in the weeks before, by whether the people who’ll do the work have actually practised it. Last week the UK’s Transport Committee published its report on the opening of Heathrow’s Terminal 5, and it reads like a checklist of what happens when they haven’t.
In my earlier post on staffing for a product launch you cannot forecast, the problem was a spike nobody could predict. Terminal 5 is the opposite case. The opening date was known years ahead. Everyone knew the crowds were coming, and everyone knew roughly how many. It still went wrong. The reasons it went wrong are the useful part for anyone who runs a support team, because none of them are about aircraft.
What happened on opening day at Terminal 5?
Terminal 5 opened on 27 March 2008. The Transport Committee’s report, published on 3 November, found serious failings by both BAA, which owns the airport, and British Airways, which operates the terminal. Problems showed up in the baggage system, in car parking and in security searches. According to The Register’s write-up of the report, the committee mostly blamed insufficient communication between the two companies, along with inadequate staff training and system testing. The chair called it a national embarrassment. That’s strong language from a select committee.
The scale is the part that sticks. British Airways told the committee that 23,205 bags needed manual sorting before they were returned to their owners, and 36,584 passengers were affected on the first day alone. When the baggage system failed, bags piled up to the point that some were moved by road to be sorted somewhere else. Those aren’t rounding errors. Every one of those bags is a person standing at a desk, asking someone a question that nobody had been trained to answer.
I’m not an aviation expert and I won’t pretend to be. What interests me is the pattern, because the same one shows up on a smaller scale in support launches everywhere. The date was real. The plan existed. The building was finished, more or less. What didn’t exist was enough practice by the people who’d be standing in front of the public when something broke. From the inside, that gap is easy to miss. Everyone is busy, everyone is competent, and nobody has actually done the thing yet.
Why does training fail even when everyone knows the date?
The committee’s finding that training for many workers was inadequate is the line I’d underline. It’s easy to read that as a complaint about effort. I think it’s closer to a lack of rehearsal. There’s a difference between being told how a system works and having used it under pressure with the lights on. A person can sit through a session on a baggage process and still freeze the first time a belt stops and 200 people are watching. A support agent can pass a product quiz and still not know what to say to a customer who’s angry about something the agent can’t see.
Two details in the report make the point better than I can. BA admitted it let building delays eat into the time set aside for testing and familiarisation. The date didn’t move, so the practice shrank to fit. And BAA suggested its test bags had been too uniform compared with real luggage. The trial passed because the trial was tidy. Real passengers don’t pack tidily, and real customers don’t ask tidy questions either.
That second one should worry every support manager. How many of our launch tests use the clean demo account, the obvious question and the agent who built the training deck? If your rehearsal only covers the cases you already understand, it’ll pass every time, and it’ll tell you nothing about opening day.
BA’s own people said the staff training hadn’t been thorough enough, and the opening should have been delayed to allow for proper testing. That’s an honest sentence. It’s also the sentence most project teams never say out loud, because the date has already been announced and somebody senior has already put it in a press release.
I used to think a firm launch date kept a team honest. It doesn’t. It keeps a team moving, which isn’t the same thing.
What did the owner and the operator not tell each other?
The report found that BAA and BA only started holding joint operations meetings after things began to go wrong. In other words, the two organisations that had to make the terminal work together didn’t sit in a room together until it didn’t. If you run support, you’ll recognise this. The product team knows what’s shipping. Support finds out when the tickets arrive. Sales promised something in a contract that engineering has never heard of. Each group does its own part well, and the gaps between the groups are where customers fall through.
The Terminal 5 version is a useful mirror because it involved two huge, competent organisations. Competence in each box doesn’t give you a working chain. Someone has to own the seam, and on most launches nobody does, because the seam isn’t on anybody’s org chart.
Here’s a practical test. Could you name, today, the person in each neighbouring team who’d call you at 9am on launch day, and the person you’d call back? If not, you’ve found your own version of the missing joint meeting. My earlier post on the escalation matrix is about exactly that list, and it’s worth writing before the date, not after.
The seam runs down to the front line too. A front-line agent who learns about a launch from a customer has already lost. So has one who’s told three days before that it’ll all be fine. Give the front line the same short briefing the leadership gets, and keep it honest: what’s launching, what’s known to be shaky, what to say when the shaky part fails and who to ring. People handle bad news well when they’ve been told to expect it. They handle it badly when it lands as a surprise on top of a queue.
Put one more thing in that briefing: permission. Tell agents they’re allowed to say “that’s a known problem and we’re working on it” without checking with anyone first. Agents who need approval to be honest will go quiet, and silence on a launch day sends customers back to the phone a second time, angrier than the first. I wrote about what that second call sounds like in dealing with irate customers.
What does a real launch readiness check look like?
Here’s the version I’d use for a support team heading into any launch, whether it’s a software release, a new product or a new office. Start by running the end-to-end path with real people. Not the happy path in a demo. Someone who has never seen the product tries to do what a customer will do, with an agent trying to help them, and you write down every place the agent says “I’m not sure.” That list is your training plan for the next two weeks.
Then test the failure, not only the success. Break the dependency on purpose and see what the customer sees, what the agent sees and what they say to each other. Use messy data, the odd account and the question nobody’s asked yet. That’s the lesson of the uniform test bags. Gary Klein’s project premortem in Harvard Business Review is a good way to find those failures before they find you: assume the launch has already gone badly, and ask everyone to write down why. People who’d never challenge a plan in a status meeting will happily explain how it died.
Next, rehearse the first hour. Walk the floor through a scripted bad hour at 8am, including the questions that have no answer yet. It feels theatrical. It works. While you’re at it, count the people who’ve actually practised, not the people who attended a briefing. If most of your front line hasn’t handled the scenario at least once, you’re not ready, whatever the project plan says.
Agree the go or no-go criteria in writing, and do it early. If training completion is below a line you set in advance, the date moves. Decide the line when nobody’s under pressure, because nobody draws an honest line the week before. Finally, put the neighbours in the room: product, engineering, sales and operations, together, before the date, with the same checklist. Agree in advance which numbers you’ll watch on the day. My post on choosing the right KPI for a launch has the short version of that list.
None of this is complicated. It’s all just easy to cut when the date is fixed and the budget’s gone.
How do you move a date without losing face?
This is the real obstacle. The Terminal 5 opening had been publicly scheduled for years, and moving it would have been embarrassing. Having read the committee’s conclusion, the embarrassment of a delay looks small next to the embarrassment of 23,205 bags in a sorting hall and a select committee using the word national.
If you’re the person who has to raise the flag, bring numbers, not worry. “Eleven of our 40 agents have handled the new process” is easier to act on than “I don’t feel ready.” Offer an option, not just a no. A phased opening, a limited first week or a smaller first audience can protect the date and the customers at the same time. Put the cost of the delay next to the cost of the failure, side by side. Most leaders will choose the smaller number when they can see both. And write it down. A short note that says what you flagged and when isn’t a threat. It’s what lets the next review be about facts instead of memory.
The phased start is the underused option. It doesn’t need the whole organisation to blink. You open to a fraction of the demand, learn what breaks and raise the volume as the answers come in. In April, British Airways pushed back moving its long-haul flights into Terminal 5 by at least a month, so it got to a staged approach in the end. It just learned that lesson in public instead of in a rehearsal.
So here’s what I’d do on Monday. Look at the next launch your team has on the calendar and ask one question: how many of the people who’ll face customers on day one have done the real thing under realistic conditions? Count them. Put the number next to the headcount. Then pick the one failure that would hurt most and rehearse it with the neighbouring team in the room.
A launch plan tells you what should happen. A rehearsal tells you what will.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
