Systems Engineering vs Rapid Prototyping or "Someone reads this Blog!"

It appears as if Eric R. Hedman, a frequent contributor to the thespacereview.com website has been reading this blog judging by his most recent article. (Incidentally his articles are always extremely clear and thoughtfully written. I enjoy reading them enormously.)

"From the start the Ares 1 development is different then almost any other project on the planet. Not only is it being designed to carry the Orion capsule into orbit, it is part of a much larger, less clearly defined project. It is also being developed in a metaphoric fishbowl, being observed from all sides by people with radically varying interests and backgrounds."

...definitely an improvement on my clumsy style. Good thing he didn't put in a link to my original post. I just went back and fixed a couple of spelling and punctuation errors. :)
(and quite frankly my original post reads to me now as just plain grumpy, see end of this post below)

Anyhow he says the same thing as I wrote two posts ago about the Ares 1 project being the first to be subject to so much independent scrutiny.

One could also interprete his emphasis in the article about the importance of good management in a project to be a counter to my comment about modern systems engineering techniques as practiced by NASA. But more likely it just ties in with the main thrust of his article that NASA need to be more open with the public and congress about their decision making process so that they can show they haven't picked up and run with a particular solution without doing their homework.

I'm actually not sure myself if I would want to throw out systems engineering altogether as embodied by MIL-STD-498 or equivalent processes. Nevertheless in my experience the overhead in man hours spent maintaining rafts of documentation ought to add much greater value than it usually does. In many cases adding additional paperwork to the design process cuts the actual engineering output by half, or even more. The net result is that two systems could have been designed and built for the same price as one that was built with the benefit of thorough systems engineering, and both of them done in half the time.
If this is the case, why not build an initial prototype of the system first, get the customer to check if it is what they want, then build a second with the customers requests incorporated?
Modern rapid prototyping methods do better than this. The customer can be integrated into the development process and their input constantly sought to ensure the product is what they wanted in the first place. Not all documentation is thrown out. Top level requirements and build configuration tracking will always be of utmost importance, and various design documents such as 3D models are maintained according to their relevance.

There are some problems however with applying such approaches to an organization such as NASA. First rapid prototyping results in a different type of system, partly because of the demands of incremental testing on the configuration. It results in White Knight-SpaceShipOne or a VTVL as opposed to a sounding rocket. The systems also seem to be a little bit lighter in functionality, more idiosyncratic and lower tech, but that may be just my impression. Second it would be hard to integrate a system built using rapid prototyping into a larger system developed using a detailed requirements flowdown approach. Third it can result in occasional embarrassing failures during the development process which just look bad, bad, bad in a multibillion dollar publicly funded project. Fourthly there may be limits to the size of project that can be taken on using rapid prototyping, although to some extent this problem is mitigated because rapid prototyping itself tends to reduce the size of the project. Fifthly the process really does depend on good management and without adequate supervision it could be very hard to tell when the project becomes unstuck, and finally, it probably doesn't do as well at passing on knowledge from one generation of engineers to the next .

In conclusion there are pros and cons with any approach we use to make new stuff and of course we shouldn't automatically blame processes when things go wrong. However with so much at stake, if expensive and time consuming processes are incapable of saving a project that takes a wrong turn we should nevertheless be asking if the processes are worth having in the first place

Oh, and by the way, I actually do want to see NASA succeed spectacularly and not just to prove they went to the moon the first time. I was probably in a lousy mood when I wrote that part because my newborn son kept me awake as he usually does for an hour or so every morning between 2 and 4am:(

(I'm getting used to it now - I think)