A while back, just before it opened (and I stress that), I eulogised about the new Terminal 5 building at Heathrow. What happened after that became an embarrassment of national proportions. My embarrassment was as of nothing to the pain people in the centre of it went through in the first couple of weeks after opening.
So I've been thinking about the original business case for the darned thing.
Let's say you are the CEO of an organisation and the business case for a strategically important project crosses your desk. It looks good. One of your best project managers has signed up to deliver it. Everything seems to check out.
You may be shocked to know that less than one in five such projects realise any of their benefits at all. And if your project realises as much as 80% of the expected benefit, then you are doing very well indeed.
Part of the reason is that most of the management focus goes on the project itself. Traditionally business thinking has emphasised management of the project; focusing on delivering the required solution within time, cost and quality. Business schools and consultants across the West have stressed this for years, like some mantra. This has achieved some improvement to the project success rate; organisations are getting better at project management.
Something is still fundamentally wrong. So what is the problem?
Mainly this: we manage to the stuff (the deliverable) and ease up too soon. Small project investments right up to very large, public ones, like Terminal 5, make the same basic blunder: they overlook the engagement of key people, neglect leading the transition to new operations, and fail to persist until their target values of measurable benefit are realised. Terminal 5, as a project, was a magnificent success. I can testify to that, having used it. But the switch to the new capability was an unmitigated disaster with significant damage to British Airways and BAA.
There is a growing realisation that when it comes to business transformation, projects and their timely delivery are necessary, but not sufficient.
1. Engaging stakeholders - influencing those outside, or on the periphery of, the project; reducing resistance to change by negotiation, influencing and collaboration; helping all involved to understand the need and purpose of the project’s outputs.
2. Leading transition - where operational leaders prepare people, handle the transition from the old regime to the new. This involves the challenging chemistry of engaging hearts and minds, planning and managing tasks to achieve an operational outcome, and then keeping on until old ways are forever abandoned and new behaviours and skills are the now embedded change.
Working back from strategic goals and the realisation of the benefits that would achieve them, we soon realise that we need more than the outputs projects can deliver. We need to ensure that operations are not disrupted but are enhanced. This requires a tactical leadership of operations that can take people through the trauma of change, identifying and adding the necessary operational initiatives that the project would be unlikely either to identify or do. Benefits are most often not realised simply because there are missing links of business changes beyond projects, such as setting up the temporary support that operational teams need in order to make the radical switch from old to new.
In turn, working back from these operational changes, the co-operation of people who would otherwise see themselves as ‘victims’ becomes vital. We could have operatives positive and enthusiastic about the change, contributing creative ideas to improve the outcomes, but only if operational leaders have the courage to engage them early enough in the right manner. Traditionally, the culture of projects has been such that they have appeared ‘silos of communication’, inward-looking, with operational people regarded more as an interference. The reason one major European programme in a manufacturing company was still-born is best illustrated by how the French pilot site described the UK-based project: “Fortress ….” (where you can fill in the dots with the town’s name). What does that say about the need for earlier stakeholder engagement?
Moreover, if such value is added after the project, then why are 60% of project business cases never reviewed after they gain approval? In fact, research shows 70% are never reviewed after project implementation. The practice seems to be that business cases are simply a mechanism to gain approval and funding; after that you can forget them. Could your business case improve during and after a project? Of course it could! Strategy changes; the business environment is volatile. For example, rising energy costs can have interesting effects on your project portfolio and the way projects are prioritised. But how would you know?
On a recent BBC Radio 4 interview a senior manager from the UK high street banks’ clearing system was asked about a major performance transformation, where the time to transfer monies between accounts will be shortened from two days to two hours. The interviewer asked why the whole system didn’t go over to it immediately, rather than going through a phased implementation. The answer was something like this: “We don’t want another T5.”
That’s interesting. The story of Terminal 5’s operational meltdown from day one is now becoming a catchphrase for this fundamental business lesson.
Maybe one of the longer term benefits of Terminal 5 for the UK economy is that we will now all have a care to think beyond project delivery. “We don’t want a T5.”
So, next time you are asked to write a project business case or approve one, what will you do?