Thomas James has a question that I’ve often wondered about as well:

I have to wonder, has every project I have ever worked on with LM (X-33, VentureStar, ET, CEV/Orion, among others) started from scratch with everything from numbering schemes to release processes to configuration management to data vaulting to drawing formats and standards to basic skill mix and team structures? You’d think that after so many decades that a lot of this stuff would have become routine by now — revised periodically as new technology becomes available, of course, but not built anew every time.

A counter argument to this — and one I used frequently when confronted with the All-Encompassing Michoud Excuse for Not Improving Processes: “That’s the way ET does it” — is that one ought to take advantage of the start of a new program to incorporate the lessons learned from other programs, thereby continuously improving the way business is done. Unfortunately, there doesn’t seem to be a middle ground between status quo and Year Zero when it comes to these things.

Every time we used to do a proposal at Rockwell/Boeing, and have to describe the systems engineering process, it seemed like we had to come with a new process flow description and graphic, as though we’d never done this before, instead of taking an existing one and tweaking it, and this applied all across the board–in risk mitigation and management, trade analyses, etc.

If I were running one of these multi-billion dollar corporations, I’d put someone in charge of boilerplate and legacy, so that there was a one-stop shop of best practices and material for use in both proposing and managing programs. Maybe they have one, and I was always unaware of it, but if that’s the case, that’s a big problem as well.