The sorter works. The orders are still waiting.
Picture a warehouse introducing an automated parcel sorter to get orders out sooner. In this hypothetical example, the tests go well: parcels move at the planned speed and arrive at the correct loading bays.
The loading team still has to move those parcels onto trucks. It has the same people, equipment and loading time as before. When the full workload arrives, the sorter sends parcels to the bays faster than the team can load them. The loading area fills up. Some orders miss dispatch and wait until the following day.
The warehouse has evidence that its sorter works. It does not yet have evidence that the complete operation can get orders out on time. Customers experience the second result.
In change management, readiness means checking whether the organization can carry out the new way of working. That includes the team receiving the new system’s output. A successful test of one part cannot establish the capacity of the next.
From the warehouse to Heathrow
The T5 account draws on the Transport Committee’s inquiry and the separate submissions from BAA and British Airways. The links alongside the findings identify whose account is being discussed.
This readiness gap was part of what went wrong when Heathrow Terminal 5 opened on March 27, 2008. The terminal had been delivered on time and within budget. Its opening nevertheless brought disruption across baggage, staff access and other operations. The Transport Committee identified insufficient owner–operator communication and poor training and testing as central problems. Transport Committee report, introduction
The warehouse and the airport share a specific handover: a system moves items to a team that must load them onto departing transport. Passing items through the system is only part of completing the customer’s journey.
BAA reported that, on opening day, bags entered the system faster than they could be loaded onto aircraft. The baggage system eventually gridlocked. Its account identifies a gap in the pre-opening trials: BAA supplementary evidence, July 2008
BAA told Parliament that trials processed 400,000 bags but assumed BA would move loaded containers to aircraft. The trials had not adequately established that capacity. BAA said input then outpaced aircraft loading and the baggage system gridlocked. BAA supplementary evidence, July 2008
HEATHROW TERMINAL 5 · BAA’S ACCOUNT
What the trials did not establish
TRIAL EVIDENCE
Bags through the system
BAA reported 400,000 bags in the test program.
COULD LOADING
KEEP PACE?
ASSUMED CAPACITY
Getting bags onto aircraft
British Airways’ capacity to complete this work was not adequately proven.
WHAT HAPPENED WHEN LOADING FELL BEHIND
Bags arrived faster than they could be loaded. The baggage system eventually gridlocked.
The lesson is not that testing was absent. It is that the evidence needed to cross an organizational boundary was incomplete. The useful question is what the receiving operation can complete, at the expected workload, with the people and equipment available.
The record is more complicated than one bottleneck
British Airways also reported software and configuration faults, delayed staff access and tasks taking longer than planned. It said building delays had reduced preparation time and narrowed some trials. In hindsight, BA said the opening move should have been delayed to complete testing and familiarization. British Airways evidence, May 2008
Those accounts should not be flattened into a claim that the technology was fine and staff were the problem. They describe interacting difficulties. More training cannot repair a configuration fault; repairing software does not establish that a loading team can keep pace.
This also changes how we investigate a problem. If loading is slow, ask what prevents the task from being completed: access to the workplace, available equipment, familiarity with the task, the information required or the volume arriving. Naming the slowest team is not an explanation of why it is struggling.
What changed afterward
BAA subsequently described joint daily performance reviews, closer baggage-team links, overload warnings and decision protocols. It reported a successful further flight transfer on June 5. BAA supplementary evidence, July 2008
BA separately reported postponing the next planned flight move while outstanding problems were addressed. British Airways evidence, May 2008
These are the participants’ reported corrections and results, not an independent test of each remedy. They show a move toward shared operational evidence and a willingness to change the transfer plan. They do not prove that one new meeting or warning would have prevented the original disruption.
What we should do before a similar launch
As change managers, we should work with the project team and business owners to follow a complete task across the teams involved. For the warehouse, that means following an order through sorting, loading and departure. Agree what must be true for that order to leave when promised, then look for evidence against those conditions.
Check what the next team can finish.
Use representative workload and the people, equipment and time expected at launch. Where a rehearsal or limited pilot is practical, include the receiving team’s task. If it is not practical, make the remaining uncertainty explicit and agree a proportionate alternative.
Show what happens when it cannot keep pace.
Decide how a growing queue will be noticed, who can respond and what response is available. For the warehouse, that might include slowing the sorter, changing loading arrangements or reducing the initial volume. These are options to assess, not assumed solutions.
Make the readiness decision shared and specific.
Bring the evidence and unresolved gaps to the project team, receiving organization, sponsor and ongoing owner. Confirm who can authorize the start, limit its scope or delay it. A change manager helps make that decision informed; the role does not automatically carry authority to make it.
Check the result during support.
After launch, compare what happens with what was expected. Watch whether orders leave on time, alongside queues and the problems people report. Assign actions and check whether they helped. A launch decision is the start of that observation, not the end of it.
Follow the task to its result
Keep this proportionate. A small internal change may need a short joint walkthrough rather than a large testing program. The scale of the check should reflect the consequences of failure and how easily the change can be reversed.
The central lesson is to test the handover as well as the tool. Before your next readiness review, choose one task, identify the team that must complete the next step and ask what evidence shows it can do so.
For the warehouse, the result is whether orders leave when promised. Following the full process helps us identify who is affected and check whether each team can complete its part when the new process goes live.