Heathrow: An urgent and secret project that wowed the judges

Benjamin Hooper led the airport’s anti-drone project, winner of APM’s Overall Project of the Year 2020. How did the team do it? And what lessons did they learn about agility under pressure?

The objective of the 2019 Counter-Unmanned Aerial System (C-UAS) project at Heathrow Airport was to provide an immediate solution to the drone threat in Heathrow’s airspace. It was unknown how that was to be done and who would deliver it, but it had to be delivered at some level within days. To that end, Heathrow deployed a bespoke set of anti-drone systems, designed to block unmanned aerial vehicles from entering its airspace.

Designed by UK-based firm Operational Solutions Limited (OSL), the system detects and tracks drones in the surrounding airspace, with the ability to locate the drone pilot and show their location, using technology from several manufacturers. The fast and accurate detention of drones keeps passengers and staff safe and minimises delays. The system will continually be augmented as part of a new business case to maintain Heathrow’s world-leading advantage in C-UAS technology.

Never done before

Civilian airports typically do not have a drone detection system and are reliant on authorities like the police and military to provide capability to mitigate the impact of small unmanned aircraft systems. This is not just a UK phenomenon; it is a global trend for any critical national infrastructure. Unfortunately, with such a cheap and prolific new technology, it was necessary for Heathrow to engage its own solution while bringing traditional government groups along on the journey.

‘Heathrow Security’, including a team of intelligence specialists adept at working with a multitude of governmental and regulatory organisations, was the business case owner and defined the project. A selection of possible solution architects were engaged and, in the end, the winner was a civilian company with a strong military background and proof of success in various theatres of operation around the world. Once selected, a series of engagement and design workshops were held with all the relevant government, security and airspace bodies to define the threat, assess the current procedures taken by the airport operational managers and outline a roadmap to protecting the airspace.

Adapting the project process, fast!

An operational steering group was set up during the design phase. This brought together all of the key operators and regulatory stakeholders with the project and supplier to ensure the operational feedback of the system (in its initial deployment form) fed into the redesign. The project therefore made effective use of the live operational environment, turning risks into opportunities for stakeholder engagement and more effective delivery.

The operational team, as much as external stakeholder groups who would benefit from the system, had to feed directly into its design. The usual project processes, with design lock and scope change after investment decision and project implementation, could not be followed. If the project had followed such a structure, it would have failed, as it was necessary to iterate, receive operational feedback, cost control feedback then adapt. This was almost as true near the end of the project as at the start.

The project adaptation diagram, compared against a more standard benchmark project, is shown above. Note the position of the operational steering group, which was able to feed into the ‘define’ stage, as well as the fact that we started implementation as we started design to satisfy the ‘rapid deployment’ criteria. This was by far the biggest initial challenge and led to a few weeks of exceptionally long days and sleepless nights, followed by night testing and more long days for the project team.

Other project challenges included:

• Using an agile tailored approach within a traditional waterfall life cycle. Ultimately, it saved money and prevented design lock.
• Pressure to deliver initial deployment weeks ahead of schedule in time for summer resulted in alleviating critical path and learning key system lessons.
• Modular design enabled flexibility.
• Benchmarking was not available from anywhere to give accurate costs, so when controls started we had to gather data immediately; happily, it was accurate and available.
• The solution was scalable and also repeatable. It was a challenge to derive this for a multitude of different sensors from different suppliers.
• Application of new technologies to other projects; redefining Heathrow Airport standards was a challenge and is now a blessing.
• The use of drones in the testing regime liberated many other possibilities and benefits by highlighting new technology. However, to use drones at all in the airspace has been a challenging learning curve for many parts of the business, particularly aerodrome compliance and safety teams.
• Some suppliers didn’t work as well as others. The complex urban environment is very hard to model and predict. Some hardware that tested well in some environments performed very poorly when installed at the airport.
• Some technologies did not work as well as others in the Heathrow environment. OSL was critical in assessing this to tailor the solution with the use of the test, research and evaluation facility (TREF). Even then, a good performance at the TREF was no guarantee of performance in the airfield.
• It is difficult to execute a prioritised urgent project when key colleagues can’t be told what it is for.
• How to test something that has never been tested.
• How to convince people that such a huge change is a necessity.

Deep blue to big blue

The business case was at the extreme, even when compared with my career in offshore oil and gas. The exposure to such a deep range of stakeholders, from government to regulatory bodies and tech start-ups, has opened my eyes to the world of R&D and emerging technology, which I truly believe will transform many aspects of life in the coming decade.

The excitement of the project has redirected my career aspirations onto a whole new path, yet in some way links to my old career working with remote-controlled sub-sea robots, processes and systems. I will be forever grateful to Heathrow and the team there that pulled me into a room that day for that ‘urgent, secret’ project that transitioned me from the deep blue to the big blue.

5 top tips for highly pressurised projects

1. Succeeding in adversity is rewarding, so enjoy the experience of a genuine high-pressure project!

2. Don’t expect to get it right first time. If there are no benchmarks available for your project, then you are setting them. Wrong decisions made early can be salvaged, but ‘right’ decisions made late cannot. Have a plan and be prepared to fail well and come back stronger. Ensure the recovery (or next iteration) has enough schedule float as well as cost (or risk) to accommodate.

3. NASA’s lessons learnt bible on project management says: “A project manager should visit everyone who is building anything for their project at least once, should know all the managers on their project, and know the integration team members. People like to know that the project manager is interested in their work, and the best proof is for the manager to visit them and see first-hand what they are doing.” By doing this you will garner better engagement from project team members, learn a lot more about what is happening and spot risks and opportunities.

4. Suppliers, engineers, creatives, architects and designers all have the potential to propose wonderful solutions. But keeping them focused on the simplest solution is often the best way to ensure it’s repeatable, scalable and hopefully modular.

5. Comms is key. By conveying the vision, objective and accomplishment of your project to the correct audience, you will not only achieve better outcomes, but also learn about other projects, professionals and business case synergies where efficiencies will be found.

Blow-out! How my experience on Deepwater Horizon helped me

In 2010, I found myself working on the Deepwater Horizon emergency response team following the oil rig explosion and spill in the Gulf of Mexico. I started on the scene during the fire and sinking, a scenario of relative chaos and little control. It was a highly reactionary and non-procedural string of events where we operated exclusively outside of standards but used them as a baseline guide.

There is no manual for how to approach a 60,000-tonne burning rig connected to the seabed by its riser and spinning out of control. But there are manuals for fires at sea, coordination of effort, launching a remotely operated vehicle and blow-out preventor emergency shut-in. Working in the incident management facility at Westlake Plaza in Houston after being demobilised (when the vessel had settled on the seabed), I was exposed to the largest-scale masterclass in iterative agile project management I am ever likely to experience.

At Westlake Plaza, different teams worked 24/7 to engineer and design solutions to shut the oil well in. When a design reached maturity, it would be assessed and presented. If it was not peer-reviewed to be viable, then the team would start a new idea from scratch. If viable, it would pass assessment and be handed to the operations team.

Solutions included ‘the cofferdam tower’, ‘the junk shot’, ‘the top hat’, ‘the RIT’ and ‘the sucker’, to name a few. All ultimately failed, but had some level of success; the lessons learned were taken, then reapplied until a better iteration was found.

Everything was done in a remarkably short time, not only by ‘crashing the schedule’, but because there was a true sense of purpose to stop, as soon as possible, the unfolding $65bn catastrophe (depending on what you read). With Heathrow’s anti-drone project, when my programme colleague and business case architect pulled me into a room with the project managers of our suppliers and told us we had to get this going in two weeks, we had that same sense of urgency and combined purpose. In collaboration with a range of Heathrow’s traditional supplier partners, we were able to engineer the same sort of modular, fail-fast scenario. The true essence of iterative agility.

Ben spoke to The APM Podcast (www.apm.org.uk/resources/the-apm-podcast) about his experience of working on this APM award-winning project, as well as his time on Deepwater Horizon

THIS ARTICLE IS BROUGHT TO YOU FROM THE SPRING 2021 ISSUE OF PROJECT JOURNAL, WHICH IS FREE FOR APM MEMBERS.