Heathrow Terminal 5 – The Agile Terminal?

I was looking through some back issues of Director magazine today, and stumbled across an article that was written in March 2008 entitled Terminal 5 Comes Alive.  It is an interesting read that discusses the leadership approach taken when BAA built Terminal 5 at London’s Heathrow Airport.

The first thing that struck me are some of the numbers.  The total cost of the project was £4.3 billion.  There were 147 sub-projects, clustered into 18 main projects.  These in turn fell under four project components – civils, rail and tunnels, buildings, and systems.  The 8,000 people who worked on the project were moved around by 60 buses, ate in 18 canteens, and used 18,000km of toilet roll!  At its height, the project was costing £3-£4 million per day.  A huge project, by all counts.

The article talks about the dismal record that most large construction projects have, and cites the Jubilee Line extension (London Underground), the Millennium Dome and the British Library as a few examples.  Yet Terminal 5, vast project that it was, managed to stay on time and budget.  Incredible.

As I read the rest of the article, I started to recognise many of the values that are a key part of agile software development philosophy.  Sharon Doherty, the article’s author, calls out three key ingredients for success: an intelligent client, integrated teams, and courageous and determined leaders.

Collaboration over Contract Negotiation: BAA created the T5 Agreement, a contract that saw most of the risk fall on BAA’s shoulders, with incentive plans devised to reward exceptional performance across stakeholder teams.  This meant that stakeholders were not continually covering themselves against potential risks, and in fact were encouraged to find ways to ensure “exceptional performance”.

The article quotes one construction firm employee as saying (emphasis mine) “we received incentives to perform at exceptional levels, which normally meant having to work with other teams in a more collaborative way, solving problems together and worrying about getting the job finished”.  Another passage of the article describes people working “in the spirit of collaborative problem-solving instead of protecting their company interests; and always working to deliver, at a minimum, industry best practice and striving to achieve exceptional performance”.

Sharon summarizes the key leadership lessons as:

1. Think Big Picture: the whole project was complex and lengthy with a changing set of stakeholders.  Keeping the big picture in mind at all times was crucial.
2. Engender And Operate With Vigilant Trust.
3. Drive For Success Despite The Odds: the date and budget were set early on, and very made public.  The commitment was made.  Everyone knew that they had to hit those targets, and worked together in times of trouble to ensure they did.
4. Keep Stakeholders On-Side And Aligned With Objectives: the T5 Agreement went a long way to creating an environment where this could happen.
5. Get The Best Out Of The Integrated Team: they created a “one team” mentality across all of the contractors.

Seeing some of the key agile software development philosophies that make so much sense to me applied at a scale I can barely comprehend and in a totally different industry just further underscores my belief in the way I choose to approach software development projects – common sense really does work.