T5 disappointment - Heathrow part 1

A slightly off topic look at another industries problems...

Why should I blog about airports? – this blog is about the business of software development. Well I could argue that its all business and within remit but I’m still its stretching it a little.

The reason to blog about terminal 5 (T5) is because past I have held it up as an outstanding example of lean practices in action.

• Compare and contrast: Terminal 5 and Wembley Stadium
• Terminal 5 is Lean

T5 is part of Heathrow airport, and Heathrow is owned an operated by BAA. In the past I’ve talked about T5 in isolation but, as all good system thinkers know, we have to look outside the immediate to understand the whole.

I think there are some interesting lessons to be learned from the recent mess at T5 and at Heathrow in general over the last few years. Some of these lessons might just help software developers.

Lets start with the re-occurring horrors that are Heathrow airport – well talk about the T5 opening mess another day. Take some examples:

• Disruption and Flight backlogs
• Reoccurring delays
• Baggage handling problems and cancellations
• Knock on problems elsewhere
• General unhappiness with the airport - I agree, I live close enough to it to make it pointless trying to use another and the experience is ghastly.

The paradox at Heathrow is that while T5 has been an exemplar case-study in Lean Thinking the rest of Heathrow shows many of the faults of traditional thinking non-lean thinking.

Travelling through Heathrow is an exercise in queuing: Lean Thinking tells us how to manage queues. Heathrow is an operating at the absolute limit of capacity, therefore it is highly efficient but prone to disruption. The slightest problem and everything is messed up.

While BAA managers have claimed that the opening of T5 would solve the problems they ignored changes on the existing terminals that would make real improvements for passengers. They have looked for a single big fixed (T5) over a myriad of smaller fixes.

For example:
• Why not strip out some shops and provide more seating? Why not strip out some shops and make popular ones bigger? OK I know why, because they make more money, we’ll come to that.
• Why not copy Liverpool airport and give people the option to pay for fast-track security? People who have a genuine choice will be more accepting.
• Why not give free water bottles for people who have their water taken off them at security?
• Why make it worse for passengers with petty, pointless rules? - the one that caught me last year was taking a cup of coffee (bought airside) with me to the departure gate. This is not allowed. Why not?

(By the way: has anyone noticed the one place at Heathrow where you can’t by a Grande Cappuccino? – The baggage hall, waiting for a case which may, or may not, appear is devoid of shops. Yet it’s the place where I’m usually most gasping for a drink, chocolate or newspaper to read while I wait.)

Part of the reason BAA has gone for the one big fix is because the myriad of small fixes requires staff co-operation, and it turns out Heathrow is a bastion of confrontational management, highly unionised workforce and prescribed working practises.

Customers have very little choice: BAA control the three biggest airports in the London area. Once you are at the airport BAA control everything you can do – doubly once you get through security.

So what are the lessons for software developers?
• Lean/Agile has its limited: No matter how lean T5 construction was the rest of the airport is a disaster. One group doing lean will not automatically infect everyone else.
• Pay attention to your customers: if you treat them badly they will start to find ways to buy competitor products, or simply stop buying (travelling). Vendor lock-in will eventually be broken.
• Queues work, they make you more efficient but they reduced your ability to react and change. Nobody likes queues, they make us all miserable. The fact that many software queues are hidden is no better.
• Management need to co-operate with those who do the work. They need to accept that a million small solutions can be as worthy as one big one.
• Short term gain (all those shop rents) detracts from long term improvement and customer experience. Sometimes the bottom line has to take second place.

Fundamentally the economics of Heathrow (and BAA and BA) are just wrong. I might go into that some other time, for the moment I’ll refer you to the Economist. Their analysis and solution is spot on. The objectives of BAA, shop holders, Government security, airlines and passengers are at odds. Nobody seems to benefit.

Perhaps the biggest problem is the business models of BAA and British Airways (which dominated Heathrow and is dominated by the airport) are utterly dependent on squeezing as many people through the airport as possible. This is not good for our national economy – let along London – but because BAA and BA carry so much political clout they are able to keep the Heathrow economic-fantasy protected. Making Heathrow responsive to real economics (as we did with coal mines, ship yards, steel factories and car companies) would actually solve the problems.

So the last lesson: It’s the Economics, stupid.

Software companies, unlike Heathrow, live in the real economic world. In the short run a company may be able to run a business model which harms its customers but customers have choice. So you’ve got to get the economic incentives aligned. If you are developing software make sure your economics benefit everyone: what is good your customer should be good for you.