Project lessons from the world’s worst maritime oil spill

Deepwater Horizon, situated in the Gulf of Mexico, was a Transocean drilling rig that became famous not for being at the pinnacle of deep-water drilling technology, but for the 2010 blow-out that led to the sinking of the vessel and the worst maritime oil spill in history.

In 2010, as an offshore inspection team lead for Wood Group, I was deployed to complete a subsea riser inspection for the BP operations team of the Atlantis, another semi-submersible oil platform in the Gulf of Mexico. I found myself there on 20 April 2010.

Candle into inferno

It was early evening when our captain received the distress call from Deepwater Horizon. Even at a range of 30 nautical miles (typically one can only see 12nm from a vessel bridge), the fire was visible on the horizon like a distant burning candle. As we drew nearer, that candle grew into an inferno that raged up to 1,000ft above the derrick.

When dawn broke, it became apparent that we were the only BP vessel at the scene with a remotely operated underwater vehicle (ROV), and so we were busy relaying images to BP’s incident response team in Houston. Later, after working a 12-on 12-off shift pattern at the scene, I went on to do the same in the control room, relaying information from the ROV feeds and writing technical summaries for solutions teams, comms teams, legal and engineers.

As the vessel sank after 36 hours, and the last bits of oil fire extinguished on the surface, we put the ROV down one last time to find the wreck, which had smashed into the seabed a kilometre or so from the drill site.

A masterclass in agile

In the following months, I worked in ‘the Hive’ in Houston, where I was exposed to a plethora of project management scenarios and given a masterclass in agile approaches. The Hive at BP consisted of a central control room in which the operations team, subsea engineers and underwater ROV monitoring station sat, as well as various senior figures. Around the main cell were six other rooms or suites in which different teams worked 24/7 to engineer and design solutions to shut the oil well in.

As different solutions were tried and failed at the well site, the lessons learned were then reapplied throughout the Hive until a better iteration was found.

All solutions were created in a remarkably short time, not only by ‘crashing the schedule’ in the traditional APM Body of Knowledge sense, but also because there was an urgent drive to put a halt to the unfolding $65bn (depending on what you read) catastrophe.

If I were to pick three big lessons from my time in subsea engineering relating to live operational project environments, I would say:

1. Society often takes for granted the engineering marvels at the cutting edge of exploration

Deepwater Horizon was a complex mass of systems, processes, engineering excellence and safety controls working in unison – until it went wrong. I never take complex systems for granted and am never afraid to ask a room full of experts an apparently stupid question on a project if something is not easily understood.

2. A proper process needs only to be pulled off the shelf and executed to handle the unexpected

The emergency response to Deepwater Horizon was similar in conduct to others I have seen, including at Heathrow. But the size, scale and fluidity of it was at a scale that is hard to imagine. The cofferdam solution fabrication – a large steel structure the size of a small tower block, ready to be installed offshore within a day or two – was started as the fire was still burning, showing the speed and efficiency of the Hive mobilisation.

3. It is better to iterate and learn and be prepared to fail where there are no benchmarks

Solutions may work or fail in new technological applications. On one project I worked on, the design neglected to drill holes in a hollow steel structure that was destined for 1,300m of water depth. Hundreds of highly skilled engineers and technicians made up the international project team. Peer reviews, third-party compliance validators, fabrication teams and multi-stage quality teams signed off on the project. When installed, the structure started to collapse, crushed by the pressure of the sea around it. The result was six weeks with multiple construction vessels on standby while the structure was shipped back to its fabrication dock. Because of the years of design, validation, peer review and diligence, the project team had not prepared for failure; there was no contingency or secondary option to keep that part of the installation going.

Reflections on a catastrophe

Overall, it is difficult to draw positives from Deepwater Horizon. However, it will no doubt be the most aggressive cost-profile project I will ever experience. The expenditure was all used to effect in the best possible way at the time. The media saw the disaster as a failure of the companies involved, and it was, but the response was a resounding success story. More people have walked on the moon than the sea floor below 500m. So, working with depths over 1,500m, in engineering terms, you might as well be on the moon.

I like to think I took the experience and have applied lessons learned throughout my career. It certainly has led me to have a more relaxed demeanour in the workplace and at home. It moved my comfort zone to new extremes.

_{Image: curraheeshutter/Shutterstock.com}

---

You can listen to Ben's experiences with Deepwater Horizon and the award winning project at Heathrow on the APM Podcast, and look out for his article in the Spring issue of Project journal.