A starting point for a discussion on marrying Agile methods and CMMI.Seat-backs and tray-tables . . .
Posted by Hillel on Dec 18, 2008 in Bureaucracy, Bureaucratic, FAA, Policy, Procedure, Process, airline | 8 comments
A few weeks ago, I blogged about a frustrating incident in an organization created a bureaucratic procedural approach to achieve the desired policy outcome rather than to create a process that would empower the people performing the activity to ensure that the policy was met in the most efficient manner.
That post caused a series of interactions with someone who took issue with my post and assumed the position to defend the procedure I was annoyed with. I believe we left the matter at a point of agreeing to disagree.
Perhaps this post will cause a different group to take issue with me, but many more people are likely to relate to the content so I can convey the topic of policy-process-procedure in a different way.
A few days ago I found myself in an airline row with 3 seats to myself from the aisle to the window. As a frequent flyer I automatically ensure that my seat-back is forward and my tray-table is "in its upright and locked position" at all the expected points in the flight profile. But this time, when it came to landing, it got me thinking (again) about the policy-to-procedure "food chain". Something seemed a bit over-kill-ish and I wasn’t sure at first why.
In particular I was ruminating on the requirement to put your tray-tables up and bring your seats backs forward during ground operations, take-off and landing. Why?
So I started with the question: what could this requirement be fulfilling?
That’s easy: Safety!
But then: what is it about safety that this specific requirement fulfills?
That’s easy too: Avoiding injury in case of getting tossed about in the cabin plus the need for people to be able to get out of the plane in case of emergency.
OK. But still: what’s going on that would lead to someone getting injured and/or being impeded from getting out of the plane in an emergency?
And that is when I realized what’s going on.
The requirement to put our seat-backs forward and our tray-tables up *is* over-kill in certain situations. Well, the tray-tables part really is NEVER over-kill. That’s *always* a good idea. But, specifically, I was thinking about the seat-backs part as sometimes over-kill.
Like in the situation I found myself in.
Airlines have to comply with the FAA’s regulations and create their own policies to do so. In fairness, I have not read the FAA’s regulation on this, but since I am learning to fly, I’m generally familiar with the way in which flight regulations go. Where it concerns passengers, the regulation is about safety, and it isn’t up to the FAA to tell airlines exactly how to make that happen. Airlines don’t have to give you seats that recline, or tray tables to put your things onto.
So the airlines come up with policies to ensure they comply with the regulations. And, then the airlines come up with processes to execute the policies and procedures to perform the processes. Or, often, they just skip the process part and jump right into procedures.
You see, bringing up our seat-backs is a procedure intended to ensure a policy (and a regulation) is fulfilled. But the policy (and the regulation) can be fulfilled in other ways. Yet the airlines don’t provide flight crews with any other way and as a result, passengers are (sometimes) inconvenienced.
Had the airlines created processes instead of procedures, then bringing up our seat-backs would be a function of whether or not anyone would actually be impeded by having our seat-backs reclined. In the situation a few mornings ago, not only did I have an entire (half) row to myself, but the half row behind me was empty. With no one next to me, no one behind me and an exit row several rows away, I could have left my seat all-the-way back and not bothered anyone’s attempt to get out of the plane in an emergency, I could have rested more comfortably during landing, and I wouldn’t have wasted a flight attendant’s time asking me to put my seat up (which didn’t happen since I did it anyway — but I’m just sayin’).
However, I’m not about to advocate for a change to airline policy on this point. Really, there are many other factors to consider, and six seats with only one passenger in them isn’t common anymore so the likelihood of not needing to put-up our set-backs is rare. The procedure is nearly 100% appropriate and for the less than 1% of instances where a better process would have helped, it’s entirely NOT worth it. I’ll suffer.
In all honesty it wasn’t a big deal at all. In fact the observation was merely mental gymnastics for me, but it did serve as good fodder to help explain the difference between policy, process, and procedure.
Hillel
My professional passion is to build high performance organizations out of companies motivated to be lean, agile, and achieve world-class results. My best clients are companies who have the courage, leadership, insight, foresight and discipline to be the best places to work, the best value to their customers and the best performing for their shareholders. I take a tough love approach and, frankly, have little patience for executives who *want* these things but expect to achieve them without putting in any effort or making any changes.
8 Responses to “Seat-backs and tray-tables . . .”
This site.
The opinions expressed here are the authors' and contributors' and do not express a position on the subject from the Software Engineering Institute (SEI) or any company or SEI Partner affiliated with the SEI.
Your Host
Hillel Glazer
Principal & CEO Entinex, Inc.
Email me.-
Hi,
I have been a long time anonymous reader of your blog.
I would like to join issue with you now regarding this dichotomy between Process and Procedure (we will leave Policy out for now)
A procedure is one instance of a process, and by the law of natural selection the fittest instances of the process survive to be labeled as examples of Bureaucracy, since they do not (and cannot) adapt immediately to late variations in their environment.
While it will lead to stray instances of frustration, I think it is OK overall
Hi Simon,
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
Taking this forward(in a different direction)… then a design engineer would follow a design process to develop the design (outcome), and follow a design procedure to create a tangible artifact called the Design Document(Output)
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….
Hi Simon,
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.
Hi,
You were right about English not being my native language
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 ?
Hi Simon,
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.
Just a thought …
A non-reclined seat might better position your body for the impact of a landing.
Yes, a reclined seat could have an effect on what would happen in a hard (or worse) landing. This would be especially true of seats in higher classes than coach. In particular this would be true of whoever is sitting behind a reclined seat. On this I would 100% agree to be a necessary precaution.
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.