A submarine modernization program

The shape of the work

A modernization availability is a scheduled period in which a vessel is taken apart, brought up to a new standard, and put back together — with the whole schedule downstream of it waiting. Every day of overrun is a day something else does not happen.

The one on this page ran to approximately $200 million, involved an approximately thirty-person technical team, and finished approximately two months early.

Why it was hard

Three things were scarce at once, and they could not be traded against each other. The work was fixed by what the vessel needed. The people qualified to do the work were a small set, and qualification is not something you can accelerate. And the window was bounded at both ends by commitments that belonged to other organizations.

That combination is what makes program leadership a technical job rather than an administrative one. A schedule built by someone who does not understand the work produces sequencing that looks efficient and cannot be executed; the constraint that binds is usually not the one on the chart.

What I owned

The technical team and the technical execution of the availability: what got worked, in what order, by whom, and what got escalated when the answer was not available at my level.

One week in

I took the billet with no turnover. The officer I relieved had already gone, so I picked the job up cold, near the end of the availability, and spent the first week finding out what I had inherited.

What I had inherited was a communications systems modernization that had been dormant for about two years — equipment shut down and left that way — and had just been woken up for testing with external vendors aboard. A lot of the tests were failing. It had also, by then, become the critical path: everything else was ready, and this was what the schedule was waiting on.

The meeting where that became official had the shipyard’s leadership, the ship’s leadership and the vendors in one room. It was loud. Nobody left it with a path forward, which is worth stating plainly, because it is the part that generalizes: the volume in that room and the understanding in it were unrelated quantities.

Decision points

Four things competed for the same finite capacity: the schedule, the technical work itself, the coordination between organizations, and operational readiness. They could not all be optimized, and no one of them could be allowed to win outright.

Decision 01Find out what is broken before reporting what is broken

A failing test is not a finding. It is at least three different findings wearing the same clothes — the part is dead, or the part is fine and the test procedure is wrong, or the procedure is right and it is being run wrong. Each has a different fix, a different owner and a different cost. The only thing they have in common is the red light.

What the room wanted was an answer that afternoon. I had been in the job under a week and did not have one.

Choice

go back to the boat and isolate the fault before escalating anything — working it through with my chief, my leading petty officer, and the vendors who were actually putting hands on the equipment.

Trade

days on the critical path, spent appearing to do nothing at the moment the organization most wanted to see motion — and a second trip to leadership carrying a different story than the one the first meeting had been building toward.

It resolved to the least interesting of the three. The equipment had sat unpowered for two years and a number of components had failed in place. Which meant the thing holding up the availability was not an engineering problem at all.

Decision 02When the answer is not engineering, stop engineering it

A failed component is a supply problem, and supply problems are not solved by understanding the system better. They are solved by a document moving through a chain of people. I was the wrong kind of qualified for it, and it was the only thing that mattered.

The mechanism is a casualty report — a message stating that a shortfall is degrading the unit’s ability to do its job, which is what moves the request up the priority order. Filing one took several hands, and the chain was not moving at the speed the critical path needed.

Choice

learn the process well enough to run it myself, and carry each message to the last step I was permitted to take.

Trade

the nights, aboard until nine or ten getting the captain’s signature — and the honest fact that this is not a fix. Doing another function’s job gets you the part. It does not make the next one arrive any faster, and a program that depends on someone doing this has a defect it has not addressed.

Decision 03Decide what has to work, and what only has to be documented

Then the estimates came back, and some of them were long enough to be irrelevant to the schedule. The supply system had worked exactly as designed, and the design was not going to make the date.

At that point two moves remain and neither one is procurement. Get what you need from a unit that already has it — which is a real cost, carried by someone else, and it was given generously. Or stop needing it: separate what must work before the boat can go from what can be accepted in a different configuration, and get that second list formally approved rather than quietly tolerated.

Choice

split the remaining failures into “must work to get underway” and “acceptable as documented,” and run each on its own path. Some items required departure from specification documentation; the required outcomes passed and no schedule impact occurred.

Trade

this is the decision on the page most capable of being wrong, because acceptable is a judgment made in advance about a situation that has not happened yet — and the only thing that makes it a decision rather than a hope is that someone with the authority to own it signed for it.

Decision 04Optimize the availability, not the workstream

Every specialty has a locally rational answer, and a program made of locally rational answers finishes late. The technical judgment that matters at this level is knowing when a workstream’s correct-in-isolation plan is wrong for the availability.

Choice

hold the team to the availability outcome rather than to each group’s own measure of a good week. That is only possible if you understand the work well enough to say why — a schedule built by someone who does not understand the technical content produces sequencing that looks efficient and cannot be executed.

Trade

friction, repeatedly, with people who were not wrong about their own piece.

What changed

We came off the critical path. The unit got underway on schedule and completed its planned sea trials, and the availability finished approximately two months ahead of its plan. That is the fact worth publishing, and it is stated as a variance against a plan rather than as an adjective about the outcome.

Afterward, training and assessment work across four geographically distributed centers — the same coordination problem with the shipyard removed and distance added, and a separate effort from the availability above.

A note on what is not here

This case carries no hull, class, unit, shipyard, program office, contract identifier, person, location, or calendar date. None of that would tell a hiring reader anything about how the work was led, and facts of that kind compose: three individually harmless details on one page can add up to something none of them said alone.

The episode above is narrated at the altitude its facts were released at, and the altitude is the point rather than an omission. It says nothing about what any equipment does, nothing about the condition of any unit other than in the past tense, and nothing that generalizes from the components on this availability to the supply of parts for anything else. Those are the sentences that would make the story vivid, and they are the ones that should not be published.

What is here was released for publication by me, at program level. It is not independently verifiable, and this page does not pretend otherwise.