For Example

If you do any sort of training, you’ve probably struggled to come up with good examples to drive a concept home. Nothing crystallizes difficult material like the perfect example to make it all real. Every train-the-trainer workshop you’ve ever been to has doubtless spent time worrying about this. And if you’ve ever been through the experience of having one of your carefully constructed examples picked apart at the front of a training room, you’ll know that it’s important to think hard in advance about examples you are going to present. Very hard. Because having your example unraveled is not pleasant, especially when a few dozen sets of eyes are watching you every step of the way.

Many trainers confuse analogies with examples. Personally, I try never to rely on analogies to prove a point. Why? Because by definition, situations that are analogous are different. Same with similes and metaphors. If you find yourself arguing some point by saying “a project is like running a race…”, I guarantee half of your audience is thinking “no, it’s not”. And they are right. Projects are not races. They aren’t fruit either, and they can’t be “low hanging” or “sweet”. And managing using Cpk is nothing like parking a car in a garage. I could go on, but I probably don’t have to. I’m sure you’ve seen all the classic PowerPoint slides just like I have. Points made this way are inherently weak because if pushed, analogies cannot possibly hold. Even a mild inquisitor can undo you. Sure, use these devices to illuminate and enrich understanding, but don’t base your arguments on them. You need a more solid foundation.

Handpicked Content:   Alstom

Which brings us back to examples. Examples have a weakness too, which is that they are inherently specific. For every example that fits your argument, there will be another example that does not. So selection of illustrative examples in the context of training becomes very important. Not only do your examples have to be clear, concise, and obviously linked to the concepts in your material, but they have to be persuasive enough that folks can easily generalize from the specific to the general. That’s a tall order.

If you ask most audiences, they will tell you that they want examples that are clearly related to their work. Put another way, they want examples that are almost the same as what they will have to do in real life. Fair enough, but as a trainer, it is practically impossible to deliver those kinds of examples unless you have a lot of prep time, a very homogeneous audience, and a big library of examples to work from. If you are teaching a lot of classes in a row, or if the folks in those classes are working on different things, or if you are treading new ground, forget about it. There’s not enough hours in a day to do it right!

Handpicked Content:   Documentation Dilemma

Happily, there is a way around this problem. One so blindingly obvious that a lot of people miss it. Eliminate the examples altogether and work on projects live, in class. Make all the points you need to make in real time, using actual situations being encountered right now. Go straight from presentation of the concept to application in a real situation. Know your project portfolio like the back of your hand, and rely heavily on project reviews to back up your points. This is old news to folks who run kaizen events, where the journey from theory to application is often measured in minutes. But for whatever reason it seldom seems to happen in longer Six Sigma training courses. Too, bad because it’s an extremely powerful way to make points. Not instructor friendly at all, but much more powerful in the long run than prattling on about making cookies to explain interactions.

The downside to this approach is that, in the short term, folks in the class don’t like it very much. People want the comfort of easy, familiar examples. Skip those examples and your scores on end-of-class surveys will plummet. Be prepared for that. You might even lose a few people entirely. Possibly those already on the low end of the distribution, and probably those that aren’t doing project work like they should. But who you should be catering to anyway? And is the job to change behavior and deliver results, or make participants feel good?

Comments 4

  1. Ron Pereira

    Hmmm… I am not sure I agree with you on this.

    I do agree real world action is the best way to teach but I personally have found great benefit from using examples like the "parking a car in a garage" example to explain the difference between Cp and Cpk. Or my favorite is to talk golf with Cp and Cpk.

    I make these into funny stories that come to me as I teach and must admit (knocking on wood as I have a class next week) to never having this fail on me.

    Sure there are always a few knuckle heads… but you just need to turn all Socratic on them and start asking them questions when they ask you one. That usually keeps them in check.

  2. Andrew Downard


    I completely understand what you are saying. I’ve used the same stories. (Well, not the SAME ones, but you know what I mean.) And it’s true, they never fail to make heads nod. People like them. They smile. And done well, they do lead down the path to understanding.

    But analogies and fun stories are neither necessary nor sufficient to getting work done on real projects. And if they aren’t necessary or sufficient, why spend time on them? Given the choice, I’d far prefer to make the same points using real data from an actual project. Might I introduce a topic with a light-hearted analogy? Yes. But only if that was the appetizer, preceding a more substantial main course.

    It is true that this isn’t always possible. And it is true that some training is more about making folks feel good as they leave the room than progressing on projects. In those cases, I’ll trot out the fun stories every time.

    My point isn’t that analogies are bad, but rather that they are not nearly as good as the real thing. My suggestion is that as trainers we use real examples as a first option, and resort to analogies only where and when we absolutely have to. It’s less fun and harder to teach, but much more beneficial in the long run, in my experience.


  3. ripstaur

    Many of the concepts we teach in quality are very counter-intuitive for most people. In fact, some of them are completely counter to what most people view as “common sense.” In fact, many of these concepts may be directly contrary to what they were taught in business or other schools. Because of this, approaching the basic concepts from as many angles as possible helps students with a broad variety of backgrounds and experiences grasp the ideas and synthesize them. Analogies are useful for this, because they tend to show the concepts broadly using examples that everyone can recognize.

    Once they begin to see the concepts, a hands-on exercise can accelerate the learning. Then you can either present a real-world example or check for understanding by having them come up with real-world examples (or both).

    The problem I have run into with only using real-world examples is that they are only real-world for some students. Some students are intuitive enough to see someone else’s example and tie it to their work. Many are not, especially if the real-world example is their first look at the concept.

    I ran into this in the military, where we started out with nothing but Auto Industry examples…everyone protested those. As we began to develop real-world Navy stories, we would incorporate them into our classes, but it inevitably came down to “…but that’s a carrier example, I work on destroyers,” so we’d find a destroyer example, and they’d say “but that’s an engineering example, I work in weapons,” and we’d find a weapons example, and they’d say “but that’s a gunnery example, I work in missiles” and on and on and on.

  4. Andrew Downard


    You’re making my point for me. The inexorable conclusion of the process you describe (which is exactly what I have experienced in more than one industry) is that we need to work on real projects. Examples and analogies don’t cut it. Sure, use them to introduce basic concepts. I agree with that. But move from there to working on actual projects being worked on in real time by the people being trained. It’s a much more powerful approach, and neatly side-steps the problematic progression you have described.

    Sure, people will still say "that project is different than my project." But they’ll only say that until it is their turn to be the one in the spotlight. And in a class of suitable duration (as GB and BB classes usually are), a good instructor should be able to find a way to put everyone in the spotlight at least once.


Leave a Reply