The Fort Wort Star-Telegram has a pre-postmortem on the F-35 schedule delays. As usual, it comes down to a fundamental lack of realism on the front end, in terms of technology risk, schedule and cost, and change management in process, as engineers were dedicated to re-working the Marines’ F-35B STOVL variant for weight creep:
By early 2003, as engineers at Lockheed and other contractors worked out more than 50,000 detailed computer drawings for individual parts and structures, the software predicted that the basic airplane would be too heavy for the Marines’ version to carry out its assigned missions. Lockheed and the Pentagon decided the best way to attack the weight problem was to redesign the airplane from end-to-end…
(Costs) soared and delays snowballed. Suppliers had already bought machines and tools, hired and trained people, and were beginning to produce parts.They had no choice, for the most part, but to shut down and wait for new drawings.
Then, getting the supply chain back up to speed proved problematic. Lockheed and its partners were often demanding parts but slow in delivering new designs to the suppliers. Managing and coordinating all the changes turned into a quagmire, according to some former Lockheed employees, with one hand not knowing what the other was doing and top management often unaware of how badly the process was snarled.
“We had a period where we had a large amount of changes,” Burbage said. “It was like a rat going through a snake.”
It’s worth keeping in mind that these are some of our country’s most successful industries, run by effective leadership employing brilliant engineers. This isn’t the B team.
But it’s also worth keeping in mind that major weapons systems take so long to bring from CONOPS to deployment that probably none of these folks have done anything remotely so complex and difficult as creating a fresh airplane from loosely crafted requirements to “shadows on the ramp” before at the same experience level. You could almost spend your entire working career moving up the ladder in a program like F-35. A fresh-faced scrub out of college could start as an associate or intern to a low-level IPT and 15 or 20 years later be in charge of his own engineering team without ever having really understood the puts and takes performed by his predecessors – to him, they’re just “facts of life” to deal with. By the time LMCO is next awarded a new development contract, all of the senior engineers and management personnel from F-35 may have retired, taking all of their war wounds and battle scars with them.
Managing engineering changes on a developmental program is crucial, and it’s an important part of the systems engineer’s role to ensure that the effects of changes so sub-assembly a.2 are reflected in the behavior of interfacing assembly b, for example. Hard though engineering change management might be, we largely have a handle on that.
Managing the change in personnel as you move through program maturity? I’m not so sure about that.