What lessons from LHR T5 for IT project managers?
March 29, 2008 - 15:01
Heathrow’s not-so-shiny Terminal 5 has been in the news a fair bit over the last few days, and for all the wrong reasons.
What lessons can we learn for projects of our own?
1. People are the most important part of any project
Initial reports suggest that the day one issues were less to do with technology and more to do with training, with baggage handlers not being properly trained in how to use their new baggage system. You ignore people in any project at your peril, and yet so many times training and communications are the first things to be slashed from a project plan when budgets get tough.
2. Avoid Big Bang launches if at all possible
Of course BA and BAA will argue that this wasn’t a Big Bang launch, with only 40,000 passengers passing through the terminal in its first day compared to the 82,000 it is designed to cope with. Nonetheless, their biggest trial day had only 2,000 people playing the part of passengers, and it’s a big jump to 40,000.
In my experience of IT projects, Big Bangs are to be avoided at all costs. Wherever possible look for ways to divide the big elements of the project into smaller tasks.
As an example, a few years ago I was involved in a project to upgrade an entire company’s core infrastructure to the latest Windows applications (Active Directory, Exchange 2003, etc.). The largest element of this project was upgrading all of the desktops in the company to new hardware and from Windows 2000 (or earlier) to Windows XP. Our original plan was to combine the upgrade of the desktop hardware and desktop operating system, but we quickly came to realise that it would leave way too much work to perform in the latter stages of the project, it would unecessarily delay some of the benefits to our end customers (faster desktop hardware), and it would hide problems until the last minute.
The one downside was that, on the face of it, it would cost more: two visits to every desk, rather than one. However, looking back at the project I am convinced the approach saved us money, as it meant far fewer implementation issues.
A much simpler example than Heathrow Terminal 5, but with similarities nonetheless. And BA has one or two implementation issues to deal with at the moment. I am sure that they considered moving a much smaller number of routes to T5 on day one. I wonder why they rejected that course of action? I suspect it was to do with cost: it would entail having more ground staff at the airport, with significant numbers of flights leaving from four out of the five terminals. So, they went with a solution that saw them move the majority of their Heathrow operation on one day and, presumably, leave them with lower costs for staffing and passenger transfers.
Of course, savings from less staff training and a larger-scale move will probably prove to be false economies once compensation has been paid to thousands of passengers and significant damage has been done to British Airway’s brand and share price.
3. If it can go wrong, it will
Some of the causes of BA’s problems on Thursday morning were ridiculously trivial for a £4.3bn project: insufficient parking spaces and security posts led to many baggage handlers being late to their posts.
Was anyone maintaining a risk log in this project? If so, were the right people involved in its compilation? Risk logs are often seen as one of the more annoying elements of project management bureacracy but, properly used, they can often be an incredibly valuable tool.
Have a risk log from day one; involve stakeholders from across the business in its compilation; have regular risk log reviews, ideally as dedicated meetings rather than tagged onto an existing meeting’s agenda; make sure every risk has an owner who is empowered to do something about it; learn lessons from previous projects (are you creating Lessons Learned reports?). I don’t know who compiled the risk log for BA’s move to T5 (or even if they had one), but I wonder if they had staff from the front line of baggage handling, car parking and security involved in its compilation?
And, for those events which even the best-managed risk log can’t forsee, have a contigency plan. Was moving flights back to some of the other terminals ever considered? You might argue that the change in terminals is confusing enough for passengers but, given the alternative between being bussed to another terminal, having their flight cancelled, or for their flight to depart without hold baggage, I know which option most passengers would choose.
Photo: Ben Terrett on Flickr. Used under licence.
Tags: air travel, IT, project management
Comments: 1
Comments
Comment from Terminal 5
Time: October 8, 2010, 9:40
Interesting article. I remember the controversy about T5 at the time, and was a bit apprehensive when I flew from there last week….despite the major problems having been a few years ago. It does seem that lessons have been learned,and generally travel through T5 was smooth. The only complaint is the check-in – they do seem to rely too much on self-service, with not enough staff on hand to deal with glitches when things go wrong.

Write a comment