By now most people have heard about the disaster of the OceanGate Titan, the underwater submersible that imploded on its way down to the Titanic wreck site carrying five billionaires on a tourist mission. I’m genuinely surprised about how little the project management community is talking about this, because the lessons appear to be vast.
Although the cause is not conclusively known at the time of this writing, it appears to most outside experts that the carbon fibre hull catastrophically failed due to the water pressure at depth. The owner of the company, Stockton Rush, was responsible for the design and construction of the vessel. Unfortunately, he was also killed in the disaster. As the details have emerged, one thing is clear:
OceanGate was agile. In fact, OceanGate was very, very agile.
They delivered product quickly, in iterations. The submersible was water tested, sent to the shop, and back into the water in record speed, carrying paying customers to depths many people appear to have winced at prior to the disaster. It used innovative material from the airplane industry that had never been used in submersibles before. Mr. Rush famously avoided certification of the sub to industry standards because it hindered innovation.
They valued responding to change over following a plan. They delivered product to paying customers early and often. They used the number of dives as the primary measure of progress.
Virtually all of the agile boxes were checked.
Agile and Project Risk
The elephant in the room is called project risk. As I see it, the consequence (severity) of failure is inversely related to the appropriateness of agile project management methodology. Consequence is one of the two components of project risk (the other being the probability of occurrence).
That is, the higher the risk of failure, the less agile the project should be.
This can be clearly seen in the first of the twelve Agile Principles, which states:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile Principle #3 is also revealing:
- Deliver working software frequently…with a preference to the shorter timescale
Agile Principle #7 keeps it going:
- Working software is the primary measure of progress
Notwithstanding that Agile remains a good project management method for software projects, the Agile army have pursued the adoption of Agile throughout all industries with considerable zeal.
You see, in software development, where agile project management originated, the consequence of failure is almost always extremely low. The software development industry is on the far end of the spectrum on this. The severity of buggy or incomplete software code is rarely a consideration that makes or breaks a project. Software just doesn’t put very many people’s lives in danger.
This fact is openly trumpeted by software investors. During the social media / web-based software boom it was thought that the risk of turning a few customers off due to incomplete code was offset by the industry-leader status that was gained by being first-in. Venture capitalists were lining up to give entrepreneurs the money to get there, while coaching them in the methods of “fake it til you make it.”
In contrast, almost every industry in which my engineering company does business counts serious injury or death as a consequence when things go wrong. Perhaps my judgment is clouded on this, because an engineering company might tend toward more risky projects. But most software developers I know think that a paying customer can be the final tester of the code, which is not normal in most industries.
Unfortunately, OceanGate is far from an isolated case of people trying to apply Silicon Valley methods to non-software projects. Theranos comes to mind, among others surely that have yet to experience spectacular failures with deadly consequences.
All this leads me to the old project management “knowledge area” (I can see the eyes rolling already) of Risk Management.
Risk consists of both probability and severity. When the latter (severity) of project failure is high, such as with the OceanGate Titan, the potential risk events must be identified, analyzed, and mitigation measures completed, or risk response strategies identified and implemented. Or perhaps the risk event is acceptable as long as stakeholders are informed. But all of these were parts of the old knowledge area. The OceanGate Titan should have designed, tested, and certified its hull prior to accepting its first paying customer, a decidedly unagile thing to do.
As another thought exercise, if I have to get my kids to the dentist, making sure that they put on their clothes is a task which must be successfully completed or else the project will not be a success. It can, and probably should, be done in iterations. However, if the journey to the dentist involved parachuting from the top of a mountain and fording a fast moving river, then you bet I’d need plenty of planning, budgeting and analysis, because there wouldn’t be any second chances. Planning your “first iteration” with just enough resources would not be the best strategy.
Another good example is Elon Musk’s newest company, SpaceX. The similarities to OceanGate are striking in terms of risk severity, taking people up instead of down (to space versus the deep sea). Here’s another thought exercise. If you were about to travel to space in a SpaceX vehicle, would you want to have the following buzz words repeated by the SpaceX team with the excitement and fervor that they are in the Agile project management industry:
- Deliver early and often
- Working product over extensive documentation
- Respond to change rather than follow a plan
- Develop just enough to get the job done
- Align development with business needs
Elon Musk’s background is in software development. Clearly he had to change his thinking at some point when he realized people can die doing this, else he would have had his own OceanGate moment by now.
Clearly the old “knowledge area” of Risk Management is not subservient to the Agile Project Management methodology. Rather, it is above it.
I am not against Agile, universally. In fact, OceanGate’s project, a submersible that required a deeper dive than previous submarines with a different purpose (tourism rather than military or research) is precisely the type of innovative project that agile is best suited for. The iterative development and testing environment, together with retrospective meetings and corresponding project adjustments, is exactly what projects like the OceanGate Titan should do. The Titan should have been water tested, revised, water tested again, and so on, in a testing environment where the consequences of failure were low.
But that’s where there’s a missing piece. If the Agile methodology is placed on a level above Project Risk Management instead of being subservient to it, in the end the severity of failure results in a situation where you must be absolutely certain the first time. You only have one chance to get it right. Iteration is a good idea to get there, but Agile’s insistence on putting partially complete or just-enough product into the customer’s hands quickly, and then building on it, is not good project management practice when risk of failure is high.
I would argue that every project has always been a series of sub-projects that deliver a coherent whole. Pre-agile project management always contained project “phases” that work together to deliver an overall project. Schedules, budgets, planning, stakeholder analysis, and risk analysis, all of the old knowledge areas, are relevant and some have greater value on a sub-project, and some on the overall project, level. Agile also works great on a sub-project level, but every project phase contains its own risks and potentially advantageous project methodologies.
In that sense, traditional project management and agile project management mostly overlap.
Finally, at the risk of jumping to conclusions, I think we can all agree that OceanGate’s primary mistake appears to be the releasing of finished product to the market too soon, prior to sufficient testing and certification.
Maybe Mr. Rush did not have the money to do it properly. Clearly in hindsight, he had two options: Either find the resources to get the sub certified correctly, or abandon the project. Floating an uncertified submersible was not one of them.
It follows that making the decision between those two options required identification of potential risk events, risk analysis, engineering work, and budgeting. In essence, alot of planning. A most unagile thing to do.
Lastly, even if OceanGate was part of a larger company, the same go/no-go planning logic would have applied for project funding decisions.
The project management community needs to learn from OceanGate and realize the pitfalls of Agile when risk of project failure is high.
Leave a Reply