Mapping NASA's Current Dysfunctionality

See also We Have Met the Enemy and He Is Us PowerPoint (NY Times).

There's probably something wrong with me, but I LIKE this slide (might be better as a wallchart, though). The alternative to this slide is not a simpler slide, it's a 20+ page document identifying all those linkages, and even if you read it in detail, you'd probably still never be able to visualize it any better than is done here. To my mind, oversimplification is at least as big a problem as too much complexity: "everything should be made as simple as possible, but not simpler." No one, having seen this slide and thought about it for a bit can then say "it's easy -- just do X." And that in itself is a victory for comprehension.

In response to the NYTimes article, NASA is much worse than the military in this regard. When you go back and look at the simplicity and accuracy of slides from the 60s and 70s you can only marvel and be envious at the same time. They had basically one shot to provide key data to decision makers since slides were hard to produce and print. Now, the vast majority of young engineers at NASA are "power point rangers," making and word-smithing charts according to the shifting whims of their managers and "stakeholders" all day. I can't tell you how many years I wasted as one such power point ranger. "Death to Powerpoint!"

Folks can laugh (and they rightly should at the lunar architecture chart shared by Paul). However, nullstring seems to get it. And the "it" you need to "get" is relational knowledge in a dynamic operating environment.

There are many names for it (Entity-Relationship Diagram, Subject Matter Ontology, Knowledge Framework, etc.). And while General McChrystal may not fully understand it (yet), the larger DoD organization certainly does understand it. DoD understands it so well, that they require this type of relational mapping as part of their DoD Architecture Framework (DODAF) requirement that is levied on all new major acquisitions. Not only that, but the latest version of DODAF (V2.0) requires such modeling be done at the "Enterprise Operations" level. What that means is that no longer can the DoD just rely on contractors to do this type of mapping for the products the DOD procures from them. Instead, now the DOD itself must begin converting "tribal knowledge" or disjointed, standalone, document-based knowledge of operations into this type of relational representation.

And this is one of the major failings that NASA, as an integrated organization (if one considers it is even this), exhibits. The NASA organization does not "get it" either. This is not to say there are no people in NASA who understand this technique. I know for a fact that there are. The problem is those people who do understand it are not empowered. During the CEV proposal period, I saw that parts of NASA were dabbling in this with the adoption of one relational architecture tool in Cradle. But it was clear they were viewing it more as a "new tool fad" than as a fundamentally different (and much more efficient) way of doing systems engineering. As such, after downselect and thru the Orion program, it remained a dabbling, new fad type of capability. It was never rolled out to ALL members of the development team and MANDATED as the way that all teams do business.

The relational knowledge map is a central part of Model Based Systems Engineering (MBSE). The premise of which can be stated as: In the past, we had lots of smart people who had mental models of how the entire, large, complex system came together and worked. Those people understood how the system was used (operational architecture), what the system does (functional architecture), and what the system was and where it operated (physical architecture and operating environment). As things become more complex, you can no longer rely on people having mental models, because the more those people's mental models of relationships diverge, the higher the probability of failure when it comes time to integrate and test the system. MBSE changes the practice of the old days by mandating an extant system model be built, and maintained, and ALL disciplines in the development and operation enterprises use and refer to that model as they carry out their jobs. Such a model becomes a common vision and common agreement that avoids the need for relying on one or a few key minds and their mental models.

There are few people who know how to do this "right." Most systems engineers are still stuck in the "write a bunch of shall statements and put them into a bunch of documents" paradigm. That is old, no longer effective, and will not serve the complexities of the problems we, as a society, are now trying to solve. The old ways will NOT work any more. And unless NASA fundamentally reforms itself along these lines, they will continue to fail just as Constellation failed.

I can see people thinking "oh that's terrible" but what the hell, if that's how things work, then you might as well document it. If it really doesn't make sense, then it should be revised.

I recently updated the process flow diagram (a state diagram or finite state machine basically) for the specialized client and case system I designed for my company and it turns out it looks pretty hairy too. It looks a little less hairball-like with fewer branches and due to the way I drew it. It has lots of states and lots of branches between them. Guess what, it works like it's supposed to, it's flexible, and saves people a ton of time and keeps the company organized. They really don't know there is this elaborate diagram representing the flow process for a case and I guess they don't need to. The diagram saves me time as a developer.

It was a funny remark but I don't think it shows DoD or NASA are dysfunctional. Complex projects are bound to look like that and it's good of them to formalize the process. I have to agree with nullstring and Ray on this one.

The company that produced the chart is called PA Consulting, they are well known over here for loosing confidential data (http://www.itpro.co.uk/605661/all-84-000-prisoner-details-lost-on-unencrypted-memory-stick).

As for NASA's version of the chart.. well, you'd have to redesign it every few weeks simply because of the changes going on with the new "vision" for space.

NASA's dysfunctionality does not require a chart for explanation, it can be summed up in a single sentence.

A vast majority of middle and senior management is incompetent for the jobs for which they are assigned because people are selected for positions based on friendship and popularity instead of EXPERIENCE.

We have ops people running design organizations, program and project managers of billion-dollar projects who have ZERO prior experience, and systems engineers who don't even know what the term means.

It's that simple, no chart necessary.

Agree that NASA does a poor job of developing people to be program managers but this constant bashing of ops people and Cxp sounds more like a personal problem rather then a rational arguement.

Where would any NASA person get the experience running billon dollar projects? They don't exist. Unless you go outside of NASA for your project managers then anyone you choose from inside our agency was and is going to have ZERO experience. So stop blaming this on one group and place this blame squrely where it belongs, on all of NASA.

http://www.thedailyshow.com/watch/thu-april-29-2010/afghanistan-stability-chart

so it depicts the forest and the trees, it's complicated, probably needs a bunch o defense contractors, "just do it" is a marketing slogan, and.......so where's Darth Vader?

dancin in the moonlight, everybody's feelin warm and bright