• Robert Weidner

Lessons From An Aircraft Carrier

The aircraft carrier displaced 94,000 tons of water as it separated the Atlantic Ocean in two halves, going far in excess of the 30 knots where the top speed becomes classified information. We went as fast as we could, and then turned as sharp as we could, to see if the ship would break. A torrent of water roared over the forward, top-side of our steel coffin. Some of my fellow sailors turned a greenish pale, and the wax on the deck began to strip in the places where they vomited. We all held on to some fixture that was welded or bolted firmly in place. This was a break from the norm... from our day-to-day tasks of swabbing the deck and running drills. This was the adventure we had signed up for.

Massive waves lapped over the bow of the ship, which looked to be sinking into the depths, before suddenly careening back up and out. Later, we would be informed that a whale had crossed our path during these high-speed maneuvers. The ship survived, the whale did not. Imagine a ship the size of the Empire State Building traveling faster than any speedboat you’ve ever ridden in, thrust forward by two nuclear reactors.

This was builder sea trials. We were fresh off a 10-year build cycle. The United States Navy was now conducting user acceptance testing prior to taking ownership of the vessel from Newport News Shipbuilding, after which it would be commissioned a United States Ship. We spent two weeks doing everything in our power to demonstrate that the ship wouldn’t be ready for the perils of war. But it was, and so were we, the first “plankowner” crew of the USS Harry S. Truman.

I remember the proud day when President Bill Clinton gave the keynote address at our commissioning ceremony. I had met him only a few hours earlier, crossing paths with his security detail in the hangar bay. I was in my dress white uniform, dispatched as a member of the working party assigned to carry the camera equipment for the event. It was a hot day – July 25, 1998 – and the anticipation was months in the making. Receiving orders to a pre-commissioned unit meant arduous duty, and arduous it had been. But our moment had finally arrived.

Six months later, we would return to the shipyard, where the Truman would be gutted and the rebuilding process would begin. We had not been bombed, either by enemy or friendly fire. We did not suffer a hull breach, combustion, radiation leak, or some other catastrophic failure. We did not have a hurricane ravage our ship and pin it to side of the pier, which is why naval units will sortie during inclement weather. No, the cause of our demise was none of these. Instead, we fell victim to bad planning.

A Nimitz-class aircraft carrier such as the Truman is built to specification, over the course of a decade. The shipbuilders had been contractually bound to requirements that were defined before the real work ever began. Progress was tracked in accordance with the iron triangle. Risk was mitigated and change requests minimized. The ship was delivered on time, seemingly within budget, and met the original, locked-in scope. The Project Management Institute would have considered this project a success. The real question however, is whether or not the ship delivered the value that was intended to the customer. Did the ship meet the market need it was trying to solve?

Sure, the Truman floated. We could go fast and turn at high speed. But could we fight in a war? Could we lead a battle group? As it turns out, we could barely communicate. Our equipment was outdated. The technology had advanced far beyond our capabilities. We didn’t even have a proper level of encryption.

The United States Navy accepted the ship, while knowing they would soon return to the shipyard for a complete overhaul. Throughout the next six months, every piece of electronic equipment onboard the ship was torn out and replaced. These additional enhancements would come at a significant cost to taxpayers, but they wouldn’t be considered a budget overrun. It was just the cost of how we did business. I remember thinking at the time, there must be a better way.

In 2001, 17 pioneers met at a three-day retreat in Snowbird, Utah, for some skiing. And to summarize a different way of designing products. Many of them were computer scientists, and had spent considerable time studying game theory. They recognized the current waterfall process for managing projects was based on the contract game, which uses predictive planning techniques, punishes change, limits transparency, and results in CYA behaviors. This group of experts wanted to shift from the contract game to the cooperative game, where the product development team uses adaptive planning techniques, embraces change, operates with radical transparency, and works together with their customers to evolve a product that will truly meet their needs.

These visionaries applied the umbrella term “Agile” to the sub-set of frameworks that used adaptive planning techniques and codified the values and principles in the Agile Manifesto. These frameworks are rooted in empirical process control, which has three pillars: transparency, inspection, and adaptation. If the state of the work is transparent, then the product can be adequately inspected. Based on the insight garnered from inspection, we can then choose to adapt the plan in accordance with what we’ve discovered. This method of validated learning helps the product emerge in lock-step with the market it’s being designed for, even if the market conditions should shift over time.

Agile isn’t just a revolution. It’s a response to a world full of volatility, uncertainty, complexity, and ambiguity… one that is spinning ever faster and in more directions than ever before. With the accelerating pace of technological innovation, disruption can come from anywhere. Business agility is how we embrace change to sense and respond to these emergent conditions.

The cost to build the USS Harry S. Truman was $4.5 billion dollars. How much could taxpayers have saved if the shipbuilders had used adaptive planning techniques rather than predictive ones? What if, instead of locking scope, they used capped time and materials, but left scope variable and simply focused on high value work throughout the build cycle? If the ship had been developed in collaboration, rather than through contract negotiation, what are the odds it would have better met the needs of the customer? In the end, it was a full year after our commissioning ceremony before we were battle ready.

According to the Standish Group CHAOS report (2015), large projects are six times more successful when they use Agile instead of Waterfall. Small to medium projects, which are easier to predict, are four times more successful with Agile. What’s the average cycle time for your products? How long before you get market feedback? The best way to mitigate risk is to increase transparency and reduce the time between inspections. If you want to ensure the product will solve a market problem, even as the market continues to evolve, then embrace adaptive, not predictive, planning techniques. In a VUCA world, it’s adapt or die.


(612) 750-5922

Twin Cities, MN, USA

© 2014-2019

Weidner, Robert.

All Rights Reserved.