It would also possibly have a role to play in coach classes where the seats are allowed to recline farther back than the typical seat in a US-based airline. In fact, my experience has been that Airbus coach seats (especially on European airlines and on overseas flights of US-based carriers) recline much farther than Boeing coach class seats.

So your thought could be another valid reason to put the seats forward. Though, at least in coach class, on Boeing aircraft and/or on US-based based aircraft of any manufacturer, the coach seats don’t go back so far that they would be a hazard in a crash for either the seats’ occupants nor the people behind the reclined seats.

Personally, in coach, I don’t see that an upright seat provides that much benefit in a crash situation when you are probably hugging your knees.

A non-reclined seat might better position your body for the impact of a landing.

What’s not well explained in the MDD, but is found in some of the details and in the front-matter, (and is also in the SCAMPI Lead Appraiser Body of Knowledge), is the reality that appraising against a model is an exercise in working from an abstraction to concrete and back to abstraction.

Unfortunately, since this is really hard to do, most people choose to simplify the SCAMPI so that it’s an exercise in pathological box-checking. Reducing the search for model-based process improvement to nothing more than seeing whether or not “typical work products” found in the examples of CMMI exist, irrespective of whether or not those artifacts actually benefit the projects or demonstrate that they improve the organization.
This dilution of the SCAMPI purpose is a serious sore point for me. I’m working with the SEI to figure out how to address it.

I agree with your argument that Process =/ Procedure, and I think that original post should have read..”the fittest instances of the process (i.e Procedures) survive to be labeled as examples of Bureaucracy, since they do not (and cannot) adapt immediately to late variations in their environment”.

When you say “Appraisals look at outputs and must make the determination about the outcomes that will result from them”
I am a bit confused, because this part is not explicit in the SCAMPI Method description, or did I miss something ?

Your use of word combinations indicates that perhaps English is not your native language.

It seems that we might be separated by some of the nuance in terminology.

However, we are very close. So, to make sure we understand each other, I’ll re-phrase your comment in my own words.

Yes, the engineer might follow a process to create the design. A viable design that someone can build from is the outcome.

The specific format of that design is the “tangible artifact” of that design. In other words, the output.

The intrinsic characteristics of the design are the outcome. It would take a trained person to look at the output and see the intrinsic outcome within it.

Appraisals look at outputs and must make the determination about the outcomes that will result from them.

In other words, processes result in outcomes, and many processes are executed via context-specific procedures. In some cases, the process is sufficient to generate the desired outcome, in many other cases, merely following the process is not enough, and procedures are necessary to reduce variation in the process outcome.

Also, I forgot to thank you for de-lurking yourself and contributing to the conversation.

What then are Appraisals supposed to do….?

Evaluate/appraise processes (which create outcomes – intangible) based on the existence of procedural outputs (tangible)

Is this appropriate….

If we slightly enhance your definition of procedure to say, a procedure is a context-specific instance of how to carry out a process for a very specific output, then I’d agree.

Though, your follow-on comment about processes becoming bureaucracy again superimposes the definition of process onto procedure.

I am desperately trying to make process and procedure distinct from one another. I am trying, also, to see to it that we use the terms to mean very different things. Using “process” when we mean “procedure” is a source of continued pain for many organizations.

As a reiteration:

Processes produce outcomes, and

Procedures produce outputs.

There’s a great discussion on this topic going on over at the Agile Project Management Yahoo! Group.
This message is a recent post, from which you can see the discussion: http://finance.groups.yahoo.com/group/agileprojectmanagement/message/10570