The Lean Thinker

April 11, 2012January 9, 2019

Learning vs Teaching

Coincidently my experience this week ties in nicely to the last post.

I have a couple of teams working to develop pull systems through their respective work areas.

The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.

An alternative approach is to have a small group of experts design the system.

Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.

What I am watching this week is more organic.

First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.

The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.

They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.

Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.

Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.

They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.

They are figuring out how to make it more robust, without making it cumbersome or too complicated.

They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.

The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.

What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.

This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.

It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.

Oh – and I’m really glad this process works because that saves me from having to know the answers.

April 10, 2012January 9, 2019

Learning vs. Knowing (or not)

PC once again left a provocative post in the Lean Thinker’s Community, and gave us a link to this Tim Harford TED talk that drives home the point that learning and improvement is more about rapidly discovering things that don’t work than about designing things that do.

Trial and Error

Tom Wujec makes the same point in the Marshmallow Challenge. In that video, Tom talks about how 5 year old kids out perform most adult groups in a problem solving / learning game. While the adults engage in a single cycle of “know-build-fail” the kids engage in multiple cycles of “try-fail-learn-try again.” In the improvement world, we call this process PDCA.

Harford’s key point is that learning only happens through a process of trial of large numbers of ideas, followed by the selection and further trials on the best ones.

Hmmm… that sounds a lot like the 3P process of “Seven Ideas” as well as “Set Based Design.”

March 12, 2012January 9, 2019

Don’t Outrun Your Headlights

I am finding good resonance with my management training sessions. Rather than doing an overview of the “tools of lean” I go in depth into the fundamental things that the leaders need to

Learn to do, and do.
Ensure are done.

in order to build this on a solid foundation.

But “resonance” seems to mean “in a hurry to get to the good stuff” and a temptation to skip some of the foundational work.

We need to start off in learning mode, working to build a foundation of stability and consistent execution.

Without consistent execution, all of the great plans are nothing but ideas. The first hoshin to work on is establishing a stable process of daily improvement. Once you have that, your improvement management process becomes an exercise in priorities and direction setting.

Without consistent execution, your improvement plan is application of brute force against the momentum of business as usual.

That isn’t “resistance to change” at work. It is “we barely have time to survive down here, so we’ll get to your improvements when we have time.”

You have to create that headroom first. Honestly, it is mostly about instilling confidence, both in themselves, and in you. They have to believe they can carry out the plan. They have to trust you to be consistent with your purpose and not cut their legs out by asking them to change course in the middle.

All of this takes practice. With the right kind of practice comes teambuilding. (That shouldn’t be a separate activity.)

Step by step. You can move quickly, but only if you embrace “smooth is fast.”

February 23, 2012January 20, 2025

Toyota Kata Seminar, Day3

The key points addressed today (Day 3) at the Toyota Kata seminar were:

The PDCA cycle – small experiments that the “learner” develops to advance toward the target condition.
The coaching cycle (or kata) – an introduction to the role of the coach, and how coaching is structured in practice.
A fairly brief discussion on the current experience with the implementation path for an organization.

Roles

Even though the book and course material are quite explicit, a couple of people in the room weren’t readily grasping this until today.

Who Is Being Coached?

In the Kata model, the first level of “learner” is the first line leader who has direct responsibility for the process, and the people who work in it.

On a production floor, this would be the area supervisor.

The core material of the course is how to plan and execute continuous improvement in your work group. This is called the “Improvement Kata”

The “Coaching Kata” is covered and demonstrated (quite well), but it is not the prime topic this week.

Who is doing the coaching?

The coach is nominally the direct supervisor of the person being coached.

To learn how to coach, one must first learn the game. Thus, no matter your role in the organization chart, you come to this seminar gain awareness of the role of your first line leaders.

Then you go home and practice the role some more. Once you have lived in their shoes, then you can turn around and expect them to do the same.

What is absolutely critical to understand here is that this is not a “kaizen event” model. This is a daily improvement model. The coaching cycle happens for a few minutes every day between front line supervisor and the immediate manager. It is a process for developing better supervisors. It cannot (or at least should not) be delegated.

Here is the crucial difference: In many kaizen events, the specialist staff workshop leader is the one directing the actions of the team. The area supervisor may be a member of the team, but she is often not the one actually guiding the effort. In this model, there is no “learner” because there is no deliberate process to improve the problem solving and leadership skills of the supervisor.

If the course has a weak point it is that we “learners” are organized in a way that LOOKS more like a traditional kaizen team, which shifts the instructor / coach more into a role that LOOKS like that of the traditional kaizen workshop leader. Thus, it is easy for a participant to slip into a well-engrained mindset about kaizen events. We have all “practiced” the kaizen event pattern many times. The “kata” pattern is new.

This is the nature of the instructor coaching a group of “learners” rather than the 1:1 that is designed to happen in reality.

So, advice if you decide to attend: Be explicitly conscious that the structural limitations of the course, and deliberately work to overcome them in your mindset. This will help you grasp the material that you are there to learn.

That being said, I have a very explicit picture now of how I want shop floor supervisors to behave and lead. I have a pretty good idea of how to help them get there.

I’ve got an early flight, more later.

February 22, 2012January 20, 2025

From The Toyota Kata Seminar

I am taking the Toyota Kata seminar this week in Ann Arbor. There are two programs offered:

A one-day classroom overview of the concepts in Toyota Kata.
The one-day classroom overview followed by two days of practice on a shop floor, for a total of three days.

I am taking the three day version.

Impressions of Day 1

There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.

I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.

Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.

That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.

You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).

Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.

Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.

I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.

At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.

Insights from Day 2

Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.

The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:

Developing our “grasp of the current condition.” There is actually a quite well structured process for doing this fairly quickly, while still getting the information absolutely necessary to decide what the next appropriate target is.
Developing a target condition. Based on what we learned, where can this process be in terms its key characteristics and how it performs, in a short-term time frame. (A week in this case)

Key Points that are becoming more tangible for me:

The “Threshold of Knowledge” concept.

I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.

There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.

For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.

They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.

Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.

It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.

Another level of knowledge threshold is that held by the experienced practitioner.

Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.

An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.

But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.

They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.

The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.

So his job is to set another target condition: Expanding the threshold of knowledge of the team.

He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.

So the next level of knowledge threshold is that held by the team itself.

If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.

None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here. Smile

There is no Dogma in Tools

This is the third explicit approach I have been taught to do this.

The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.

Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.

Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.

The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.

One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)

Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.

I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.

What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.

The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.

I will become necessary, it just isn’t necessary now.

Target Conditions and PDCA Cycles

One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.

The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.

There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.

The last thing we want to do while messing with them is to starve them of material.

So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.

More tomorrow…

February 21, 2012January 9, 2019

Clearing the Problem / Solving the Problem

As I work with clients to get a “problem solving culture” embedded, one common challenge is the distinction between the short term work-around to remove the obstacle, and the long-term countermeasure that actually improves the process.

I addressed this at a conceptual level in the “Morning Market” post a while ago.

Last week I was working with a client who has begun using the work-around as their key insight into the issue they have to solve.

When the work flow is disrupted, they are careful to capture what they had to do in order to clear the problem and get the item back into the normal production flow.

“We had to wait for parts.”

“We had to rework _____.”

“We had to get on someone else’s login for enough security to do the task.”

“We had to find the ____.”

“We had to replace ___”

This is really valuable information. By appending “Why did…” in front of the statement, they have a fairly well defined starting point for getting to the bottom of the actual issue.

By making the containment action the first “Why?” they get off the containment-as-solution mindset.

It might not work for everyone, but it is working very well for them.

“Please continue.” Smile

February 18, 2012January 9, 2019

Smooth is Fast

When you are at the gemba, you are watching the work. We like to say you are “looking for waste” and list seven, or eight, or ten different categories of waste that you are supposed to look for.

I think it is simpler than that.

An ideal workflow is smooth.

The product moves smoothly, without starts and stops, without sudden changes in momentum.

The people move smoothly. Each of their motions engages the product and advances the work in some way.

Machines do not interfere with the smooth movement of product or people.

Information flows the same way. There is nothing in how it is stored, retrieved, or presented that causes people to break their smooth rhythm.

When you watch the work, try to visualize what smooth would look like. Smooth has no wasted motions, no excessive activities.

Anything that doesn’t look smooth is likely the result of an accommodation, an awkward operation, poor information presentation, poor computer screen layout and workflow.

Just another way of looking at it.

February 9, 2012January 9, 2019

Leadership and Challenges

This post rambles a bit, and wraps up a few concepts. It was, however, inspired by a recent interview of Mike Rother on Lean Nation. (See below)

One of the many good points that struck me was that you can’t rally around an ROI.

Yet companies try to do just that. They set something ROI or margin objectives, and wonder why everyone doesn’t pick them up and run with them.

Even companies that do issue a good challenge often come up wondering why the organization doesn’t align around it. Rother mentions one good reason: Nobody is there to coach them through meeting their part of the challenge.

A similar fallacy is trying to rally people around an abstract vision. I have experienced this a couple of times. A company tries to apply general education to people – lots of it – in the (vain) hope that once people “understand” then they will pick up the ball and run. But without consistent direction toward a limited objective that is easily articulated, people freeze up. “What do we work on?” There are too many choices.

Chip and Dan Heath discuss the importance of a rallying point in their book about culture change, Switch. They talk about “Pointing to the Destination” and “Scripting the Critical Moves.” When we talk about an aligning challenge, we are saying the same thing. Remember – in these initial stages you are trying to infuse a fundamental behavior and culture change. You can’t just tell people what it is and expect things to change tomorrow.

Classroom training may teach people the words, but it does little to accelerate the process of learning on the shop floor. That takes leadership.

The Process of Caring

Vance left a really good comment on the recent Travel Tales post. He said, in part:

Having worked in the airline business, it’s really a matter of having employees that CARE (most due to their own pride, not by management) We many times had weather and mis-connected passengers to deal with. It only took a few minutes of extra time to send a message to the destination station and let them know what to expect or which passenger was going to be disappointed to not get their bag. Today’s situation is exacerbated by under-staffing, stressed employees, passengers with sometimes unrealistic expectations, checked bag fees, etc it’s ugly and very little relief in sight.

He brings up some really interesting points. In most of the airline industry, like most industry in general, “caring” is thought of as something the people have to do.

“The employees don’t care” or even “management doesn’t care” are pretty common statements.

Let’s turn it around.

How was the original process designed?

Continuing on the theme from the original post, I would speculate that most players in the airline industry see themselves as providing transportation to people and their stuff.

The process design is, logically, going to center on what things have to happen to get people and their stuff from their point of entry into the system through to their point of exit at baggage claim. (the fact that the trip doesn’t actually end at baggage claim is another topic – one which has been discussed by Jim Womack in Lean Thinking, among other places.)

In traditional thinking, improvements in that process will involve making those things happen cheaper, usually by doing less.

What if, though, we start with a different question:

“What experience do we want the customer to have?”

Describe, first and foremost, the things the customer has to do to get herself and her stuff from the point of departure to (sadly) baggage claim. (Bonus points if beyond, but let’s not stretch the fantasy too far.)

Even better, act it out. Simulate it. Try it on. Work out the kinks, from the customer’s perspective.

Next, design the interface between your customer and your process. What does the customer-touching part of your process have to look like to deliver that experience?

(I often wonder if airline executives ever see their own web reservation systems.)

Now, only when you know what the “on stage” part of your process looks like can you design the rest of it – the back stage parts that make it all happen.

Economics come into play at this last stage. This is where you have to get creative. If the solution is too expensive, work on the back-stage part to make it cleaner and more streamlined. The customer facing part of the process is the target condition. Your problem solving works to deliver that experience in continuously better ways.

What does this have to do with “caring?”

Remember, this is from the customer’s perspective. When we say “our employees care” do we not really mean “our customer’s feel cared-about?” Since we started with the customer’s experience, if that is what is desired, it was built into the process specification from the beginning.

Once there is a process that we predict will result in customer’s feeling that people care about them, then your market surveys make sense. You are not soliciting complaints about things to fix, you are validating (or refuting) your design assumptions. Every bit of customer feedback will be a learning experience.

Don’t forget Murphy.

In a complex business like airline travel, sometimes luggage doesn’t get to baggage claim at the same time as the customer. It happens. But this is the time to really apply the above process design. What do you want the customer to experience when things go wrong?

Ironically, in the customer satisfaction world, a spectacular and surprising recovery actually generates more loyalty than flawless delivery of service. This is the moment for your company to shine.

Whatever happens, though, make sure it is something you would do on purpose rather than relying on chance or a random team member’s disposition. Build “caring” into the process itself, and you will embed it into the culture.

January 25, 2012January 9, 2019

Travel Tales

One of the advantages of having a business performance blog is I have a ready place to ~~rant~~ ~~complain~~ share my customer experiences with the air travel industry.

It all started Monday. I had a flight from Seattle to Raleigh-Durham NC, connecting in Newark. It was only a two day trip, so I was traveling pretty light.

As we were boarding the 737 the bins filled up fast and everyone forward of about Row 15 was required to check their bags all the way to the destination. “We apologize for the inconvenience” (after pointing out how it was the customers’ fault because they had offered a chance for people to volunteer to check their bags, and not enough people did.)

OK, I checked my bag through to RDU. (Forshadowing)

Once on board, the pilot let us know that there were air traffic control delays enroute, but we were going to pull away from the gate anyway, and park on the tarmac until cleared. (This, by the way, lets them get credit for an on-time departure.)

That wasn’t too bad, only about 10 minutes. “We apologize for the delay.”

As we got to about the Great Lakes, the plane banks left. And banks. And banks. The shadow is gliding over the engine cowling, and returns to its previous position, the plane levels off. Yup, we just did what they call a “racetrack.”

Then we do another.

And another.

And some more.

We land at precisely the time my connecting flight is scheduled to depart. Not gonna make it. “There will be an agent waiting at the gate. We apologize for the inconvenience.”

Well – maybe everything is delayed, and I can still make the connecting flight. It wouldn’t be the first time I have lucked out that way.

Nope. Well, not quite. It hasn’t left because the plane never left RDU. Flight cancelled. “Head down to Customer Service at Gate 105.”

Wait in line, pretty surprised actually. Rebooked on a 7:32 flight, delayed to 9:51. Ugh. Got a few hours in the airport. “What about my luggage?” “It will be on the plane with you,” I was assured. More foreshadowing.

9:51 comes and goes. No plane. We’re told the inbound plane is enroute. OK.

I am having a nice chat with the pilot for our eventual flight to RDU. He is actually quite interested in the TPS. “Can you do this with airlines?” he asks, half seriously. He asks for a card. I know enough about aviation to have a very articulate conversation with a pilot about planes, flying, and the business, so that was nice. “No, I am not a pilot,” I answer his question, “but working at Boeing Flight Test for five years, you learn a thing or two about how airplanes work. I know what all the noises are.” He smiles.

Woo hoo. A plane shows up. Bombardier –8 Q400. We board.

And wait.

11:15pm The (other) pilot gets on the P.A. and explains that they are overweight and working on how to handle it. He goes on to explain that due to the fog earlier in RDU, they have extra fuel on board. Further, the alternate airport is back at Newark. (Which means they need enough fuel for a round trip PLUS the reserve.) We wait. 11:45. A passenger (two, actually) volunteer on their own to be “bumped” to a flight tomorrow. Apparently that “solves the problem.” But the pilot had mentioned that part of the excessive load was “excess baggage from an earlier flight.”

“We apologize for the delay.”

“We are just as frustrated as you are.”

I should mention at this point one of the games that gets played here. By declaring the departure airport as the alternate airport, the airline can either land the plane at RDU with enough fuel for the return trip, or return it all the way to Newark and avoid a deadhead ferry flight from an alternate landing if they can’t make it into RDU.

At midnight the propeller begins to turn.

It is about a 90 minute flight.

I glance out the window and notice the propeller spinner is now white at the tip. Leading edge of the wing also turning white. In my brain fogged state I start thinking about this airline’s last accident.

We land at RDU at 1:40 or so. The airport is pretty much buttoned up except for us.

Head down to baggage claim. A few bags come out, then the sign flashes from “unloading” to “completed.” There are twenty people still waiting.

I was one of them. It seems that a lot of the passengers on the plane were the ones whose baggage was left behind because it was just bags from an earlier flight.

Our little cluster heads over to the airline’s baggage office. There are two people there, and it clear from their body language (and verbal language for that matter) that this was not in their plans for the evening. We customers with no baggage have, apparently, really inconvenienced them.

It turns out that, of the two, only one of them “can operate the computer.” so they are processing one person at a time, with a cycle time of roughly 10 minutes per person.

The non-computer one comes out. People ask her when they can expect their luggage to get here. She, in an annoyed “I already-told-you-I-can’t-do-anything” tone carefully explains that only her computer-literate co-worker can find out, and only when they scan the ticket and search for things on the computer.

She asks if we would like the 800 number. Sure. She goes into the office and comes out with the number written on a scrap of paper and reads it off while people try to type it into their phones. (Tape it up on the window? Nah.)

I manage to get through, “All of our representatives are currently serving other customers.” (Yes, I can actually SEE them right now.) “The wait time is approximately TWENTY minutes.” I am reminded multiple times that all I need to do is go to www.(Houston based airline name).com, click here, click there, enter this, enter that, and I can do all of this myself. Not exactly helpful in an airport terminal at 2:15am.

A human answers. She asks for my case number. Huh? I have the baggage claim number. It seems she is actually there to handle follow-up rather than initial calls. Nevertheless, she is very helpful, takes my information, and offers to authorize me to spend $75 if I need to buy something for my client meeting in the morning. “Thank you,” I say sincerely, and laugh with her that there isn’t a lot I can buy at 2:30 in the morning.

Head for the rental car counter. I still have a 90 minute drive ahead of me.

The only thing in the “Emerald Aisle” is a big pickup truck. I don’t feel like taking it, so I go into the office. A very nice gentleman at the National counter is surprised about the number of people showing up all of a sudden, I explain a late arrival. He asks if I want an SUV, I said sure, he tells me where it is.

I get in, start it up, punch in my hotel address into my phone (I LOVE Android GPS), and start out. Once I clear the gate, there is a 20 mph speed limit, and one of those radar signs that says how fast you are going. I see the sign, and immediately slow down. My speedometer is dropping down under 40, as the radar sign is dropping down under 20. Huh? Take a good look through the foggy brain. Kilometers Per Hour. Yup. I have a Canadian vehicle. So driving through rural North Carolina having to run metric conversion in my head. No big deal, but the final irony.

I arrive at the hotel at 4:30. The night clerk is on the phone, “Just a minute sir, they are doing an night audit.” I mention that I have been on the road for 22 hours. She takes the hint and interrupts the auditor to check me in.

4:45, I get to the room, take a shower, and settle down for my 75 minute nap before meeting my client in the lobby at 7am for a great day on site.

Good news – the suitcase showed up the next day.

Of all of the places that I have “gotten ahead of my luggage” this was actually the least exotic. The last three were Berlin, Glasgow and Tunis. Danville, VA just doesn’t seem that exciting by comparison.

So this was 20 hours of hearing airline employees begin every other statement with “we apologize.” (Except the baggage claim people who were quite UNapologetic). I suppose this was catching up with the law of averages for a series of very smooth and uneventful travel adventures lately.

What if a key airline performance metric was how many times their employees use the words “we apologize” during a given day? If they actually meant it, the number should steadily decline.

Smile

Hopefully the flight home will be less of an adventure.

All humor aside, this experience revealed a couple of obvious breakdown points.

First, I normally try to avoid any connection in the NYC area. The airspace is just too crowded for things to work under less than ideal conditions. But faced with the client’s requirement to use their travel booking, and unable to gerrymander arrival / departure times to force a decent fare-competitive alternative out of the system, I kinda had to take this one.

Let’s talk about the baggage thing. At the departure airport, we have the aircraft service process that loads fuel, calculates weights, generally gets the plane ready for a safe flight within regulatory guidelines (and consistent with airline economic objectives).

We have a separate process that takes luggage with “RDU” tags and loads them onto a plane headed for RDU.

And yet another process for getting the passengers manifested and loaded.

I surmise that there are three separate processes here because there were ample opportunities for cross-process communication that obviously did not happen.

The pilot was apparently surprised by the overweight condition. Yet the airline knew, hours before the plane even arrived at the airport:

How much fuel they planned to load.
How many passengers they planned to load.
How much luggage (and, if they really wanted to, the weight of that luggage) they planned to load.

What if they started to work the problem of overweight condition before just tossing the problem into laps of the newly arrived flight crew?

Based on the way the pilot spoke of the “excess baggage” it was not clear to him, or the gate agent, that the “excess baggage” belonged to the “excess customers” that were on the plane. I am not sure if that knowledge would have made any difference if they knew they were flying people without their bags, but at the minimum it would have set up a far more appropriate process at RDU.

As you recall, the baggage office at RDU was surprised (and apparently annoyed) that all of these passengers showed up, and now they were understaffed to deal with them.

Imagine, if you would, an alternate scenario.

The airline KNOWS which passengers are on board the plane. They KNOW which bags are on board the plane. (This is a true statement.)

What if their system cross-correlated bags with passengers.

What if, upon flagging the condition where they had a passenger in a seat, but no luggage in the hold, they notified the baggage office at the destination airport.

What if, upon receiving this information, the airline’s employees, using information they already have in their system, traced the bags and made plans.

What if, upon arrival at the destination airport, those passengers were greeted by name. What if “Mr Rosenthal, we are sorry, but your luggage didn’t make the flight. It is still in Newark. If you let us know where you are staying, we will get it here on the first available flight in the morning and have it delivered. Is there anything else you need?”

The net effect would have been the same, the airline would have done what they ended up doing anyway, except the customers would have received a little empathy. No extra cost, just a little more service. The baggage claim people could have gone home two hours earlier, and although inconvenienced, the customers might be left with the impression that somebody actually cared.

But, for those of you who remember the old Saturday Night Live Steve Martin Theodoric of York skits – First the soliloquy about how wonderful a situation could be then the punchline: “Naaaaaaah.” as he returned to his medieval ways.

Oh – and I finished reading the Liker book I have been discussing, so look for a couple of more write-ups and then an actual review as I get some keyboard time.