Listen:
Check out all episodes on the My Favorite Mistake main page.
My guest for Episode #186 of the My Favorite Mistake podcast is John Grout. He is the former dean of the Campbell School of Business at Berry College in Rome, Georgia.
He’s the current Chair of the Technology, Entrepreneurship, and Data Analytics Department and the David C. Garrett Jr. Professor of Business Administration. John has overseen the development, approval, and implementation of Berry College’s Creative Technologies program and Berry’s makerspace, HackBerry Lab.
Dr. Grout has extensively researched mistake-proofing and published numerous articles on the topic. In 2004, John received the Shingo Prize for his paper, “The Human Side of Mistake-Proofing” with Douglas Stewart. John has also consulted with a wide variety of firms to help them mistake-proof their processes. Check out his website, www.MistakeProofing.com.
He’s also published “Mistake-Proofing the Design of Health Care Processes,” a book that’s freely available online.
In this episode, John shares his favorite mistake story about using early mistakes to learn and then win a tower-building exercise, ultimately defeating several “A students” in the process. From John's story, what does that teach us about learning from mistakes — early and often — in a way that propels us toward success? Why is this an entrepreneurship lesson (or a human lesson) and not just an engineering lesson?
We also talk about questions and topics, including:
- “Surprisingly, it’s the A students” who think they know how the world works
- Knowing vs. Experimenting?
- “It’s all about the scientific method” — Lean Startup
- PDCA = Plan Do Check Adjust
- Others didn’t observe and learn from your mistake?
- Spaghetti building – kindergartners vs. MBA
- TED talk — the god complex, trial and error
- Small tests of change = mistake mitigation method
- Chick-fil-A, ThedaCare, and rapid prototyping
- ThedaCare stories
- Adam Savage – Every Tool's a Hammer book
- How do you define mistakes? Strict definition vs common definition?
mistakes —
- (strict definition) conscious deliberation that leads to selecting the wrong intention.
- (common definition) synonym for error. For example, the term mistake-proofing uses the common definition since mistake-proofing is used more to prevent slips than mistakes (using strict definition)
- Errors – breaks down then into mistakes vs slips
- Mistake – do what you intended to do
- Slips — right intent but not executed well
- How do you define “mistake proofing”?? Or Slip-Proofing
- How do we decide if mistakes or slips are preventable? “Different vocabularies” for each…
- Why are checklists the “weakest form of mistake proofing”?
- Some recent examples you’ve seen of mistake proofing in everyday life?
- Be careful signs…
- “How can I make this process fail? Make it fail in a benign way…”
- The language around “mistake proofing” or “error proofing” vs. — is it a mistake to say things like “fool proofing” or “idiot proofing”??
Scroll down to find:
- Video of the episode
- Quotes
- How to subscribe
- Full transcript
Find John on social media:
Watch the Full Episode:
Quotes
Subscribe, Follow, Support, Rate, and Review!
Please follow, rate, and review via Apple Podcasts or Podchaser or your favorite app — that helps others find this content and you'll be sure to get future episodes as they are released weekly. You can also become a financial supporter of the show through Anchor.fm.
You can now sign up to get new episodes via email, to make sure you don't miss an episode.
This podcast is part of the Lean Communicators network.
Other Ways to Subscribe or Follow — Apps & Email
Automated Transcript (Likely Contains Mistakes)
Mark Graban:
Episode 186: Professor John Grout, former business school dean and researcher on mistake proofing.
John Grout:
Well, I'm glad you called it “my favorite mistake,” because my favorite mistake actually isn't my biggest or worst or any of that.
Mark Graban:
I'm Mark Graban. This is My Favorite Mistake. In this podcast, you'll hear business leaders and other really interesting people talking about their favorite mistakes because we all make mistakes, but what matters is learning from our mistakes instead of repeating them over and over again. So this is the place for honest reflection and conversation, personal growth, and professional success.
Visit our website at myfavoritemistakepodcast.com to learn more about John Grout, including a link to his free publication on mistake proofing in healthcare. Look for links in the show notes or go to markgraban.com/mistake. And now, on with the show.
Well, hi everybody. Welcome back to My Favorite Mistake. I'm Mark Graban. My guest today is Professor John Grout. He is the former dean of the Campbell School of Business at Berry College in Rome, Georgia. He's currently the chair of the Technology, Entrepreneurship and Data Analytics department, and he's the David C. Garrett Jr. Professor of Business Administration. John has overseen the development, approval, and implementation of Berry College's Creative Technologies program and Berry's makerspace, called Hackberry Labs. So before I tell you a little bit more about him, John, welcome to the podcast. How are you?
John Grout:
I'm doing great, Mark. Nice to be here.
Mark Graban:
Let me tell you a little bit more about John's background, and I think when you hear this, you'll know why I invited him to be here today. He's researched something called mistake proofing extensively. He's published numerous articles on mistake proofing. In 2004, John received the Shingo Prize for his paper called “The Human Side of Mistake Proofing.”
He's also consulted with a large variety of companies to mistake-proof their processes. And he also published an ebook that's freely available online. I'll link to it in the show notes. I recommend it whether you're working in healthcare or not. It's called Mistake-Proofing the Design of Healthcare Processes.
And his website is mistakeproofing.com. So, John, with the different things you've done in your career and different departments and things you've done, I'm curious to hear your story. What is your favorite mistake?
John Grout:
Well, I'm glad you called it my favorite mistake because my favorite mistake actually isn't my biggest or worst or any of that. My mistake was one that I actually try and commit whenever I can. The circumstance was that our Creative Technologies program was having a contest where we had PVC pipe, pool noodles, and zip ties, and we were supposed to create the tallest tower that we could. So, very similar to a lot of engineering exercises or team-building exercises that are out there.
I came to it—since it was out of my department and I'm department chair—thinking, “I'm just going to let them do it.” But there was a math professor and a physics professor who showed up with their teenage boys, and they were going to try this out. They said, “Oh, you should do it too.” And so I said, “All right.” So I jumped into it and started building. And within about half an hour, I had a structure that was about 18 feet tall. It was super simple because PVC pipes are 10-foot lengths. I had it up there and then started to add from there. What I found was that when I tried to take my tower and stand it up, it would bend, and those bends would invariably break all of the connections that I had for this tower.
Mark Graban:
So you were building it horizontally along the ground and then trying to tilt it up, is that right?
John Grout:
Exactly right. And very early on, I discovered that that did not work. And that's my favorite mistake: the idea that if you make a mistake early, it's low-cost, you can recover from it, and things turn out great. Now, I was actually trying to not win this competition because I don't think it's really proper to sponsor an event and then win it.
Now, one of my colleagues was administering the event, so I really didn't have any official responsibilities, but I felt like it would be way better if a student won the prize. The prizes were not glorious and fantastic; it wasn't anything like that, but I did feel like, “Certainly someone will beat this.” So I worked on my tower, found out that you couldn't stand it up, but rather you had to build it up. And so I got a couple of the lab assistants to help me pick the tower up, put the next section underneath it, and we did that twice. And we were up about 35 feet.
I thought that was a respectable showing but didn't want to blow the competition away. The problem was, no one else figured out that you couldn't build it horizontally and then stand it up. It was a three-hour exercise, and I was done in an hour and a half. Two and a half hours into the project, everyone was starting to think about standing up their projects, and they all broke—every single one of them.
And so they had a half hour to try and resolve the issues that they had found. I was really lucky because I made a mistake that helped me understand the material I was working with early in the process, and I tried to make it as simple as possible.
Mark Graban:
So an accidental victory that was born out of learning from an early mistake. That's such a great story for what we talk about here on the podcast all the time.
John Grout:
Yeah. It taught me, because we always talk about a design process where you build a prototype, you iterate, and you try and make mistakes early. We talk about it. And at that point, the program was relatively new, and I hadn't really understood the power of that methodology, which is that you try stuff and you try lots of stuff to see what's going to work and what's not going to work, and you do it at a scale where if it doesn't work, you don't care.
Mark Graban:
Yeah. And it seems like you could frame this as a design lesson or an engineering lesson. Since you're in the business school, I'm guessing you might agree this is also an entrepreneurship lesson. I can think of one of my recent guests, Emily Leering; she's a family therapist. She wanted to start a very specialized childcare program for kids and parents who needed mental health support. This was not intended to be the run-of-the-mill daycare. Well, the phone was ringing off the hook when she announced she had a daycare, but guess what? It was people wanting just basic, typical daycare. I think the one takeaway from her story was that she was starting this as a home-based business. The risk or the cost of then shutting it down, of realizing she wasn't finding what she thought her target market was, that was a far less costly mistake than if she had rented space. She might have felt trapped into trying to make that work, even if that wasn't what she wanted to do.
John Grout:
Yeah. And I think for lots of businesses, if you start it as a side hustle, that's the least risky way to do it. Now, I'm not saying that everything can be done that way, but if you can do it as a side hustle, that would be fantastic.
Mark Graban:
So, can you think of, without naming names, of course, students or people that you've mentored who were maybe being a little too stubborn and not recognizing that early mistake that could have saved them a lot of time and expense down the road?
John Grout:
Oh yeah. And surprisingly, it's the ‘A' students.
Mark Graban:
That's not surprising to me.
John Grout:
Well, I wish it weren't that way. The ‘A' students think they know how the world works. I had a young woman in one of my very early prototyping classes who wanted to use rainwater coming off the roof to generate electric power. She was going to put a little turbine on there and have it spin. And I said, “Okay, how much electricity do you think you're going to get, and how do you think that's going to work?”
And she says, “Oh, this will work fine.” I said, “I don't think the physics are there. I don't think that there's enough going on. And by the way, if this worked, why would it have never been done before?” Part of me says a lot of smart people have thought about everything in this world at one point or another. And so I think that we're pretty convinced at this point you can't take lead and make it into gold.
Mark Graban:
Sure.
John Grout:
And I said, “You know, I don't want to squelch people. I really think people ought to be able to learn for themselves.” And so I told this student, “You've got to get this up and running in the next week and a half and figure out if it works or not, because I don't think it's going to work.” Well, supply chain issues came up and she didn't do her initial “hello, world” experiment until 10 weeks into a 14-week semester. She finished with a project, but it was a completely different project. She pivoted entirely away, which she should have done in week two, but when you do it in week 10, it just doesn't end up looking nearly as good.
Mark Graban:
Yeah. And I think there's this definite trap. When I said I wasn't surprised that it's the ‘A' students, the ‘A' students are used to knowing the answers, right? It's one thing to understand how accounting works. We can know double-entry bookkeeping if we wanted to. But that knowing trap, I think this applies to continuous improvement or entrepreneurship. Knowing versus experimenting. What I hear you saying, in different words, is “Go test that hypothesis as soon as possible to validate or invalidate and move on or move forward or back off or adjust.” Right?
John Grout:
Yeah. So Eric Ries—there's a book called The Lean Startup. It's all about the scientific method. I actually gave that book to my college president, and he read it and he says, “Oh, I never understood how business and the scientific method went together at all. Now I get it.” And so it really helped us in terms of being able to communicate because he understood that we were using the philosophy of science to think about how we run businesses. And so that was a big help for us. But yeah, if you look at any self-improvement technique—if you look at the Lean Startup, if you look at the scientific method, if you look at lean manufacturing or PDCA or the DMAIC of Six Sigma—all of those at the end of the day involve having a theory, generating data, analyzing the data, and acting based on that data. Everything at some level that will lead to improvement is the scientific method. And what we're talking about is doing that cycle of learning much faster.
Mark Graban:
So then there's the cycle of learning that you described in that competition. I think it's interesting that it seems like the other groups… were you all working out in the same space where other groups theoretically could have watched you make that mistake and then learned from it?
John Grout:
Yeah, so we were in a quad, and the quad, like any college quad, had sidewalks running all across it, and everyone had a four-foot square taped off on the sidewalk. And so yeah, the furthest tower away from me would have been less than 50 yards. We could all see what each other were doing. And interestingly, when push came to shove in that last half hour, they all looked at mine, which had been standing there for an hour, and they said, “Let's do some of that.”
Mark Graban:
And so, some last-minute benchmarking.
John Grout:
They got close to my height, but they didn't quite overtake me. I kind of wish they had, but I wanted to have a good showing and have some student win, and I couldn't get there. And it's because I had some knowledge that they didn't have and actually developed some techniques for holding together PVC pipe that were only relevant in that particular circumstance that they had not developed.
Mark Graban:
But you used the word knowledge, and you developed—I mean, you learned that, right? You learned from your experiments. If everyone starts off at the same level of knowledge… I mean, maybe it goes back to Darwin: the business that is most adaptable to change, meaning the one that learns most quickly. Actually, this makes me think of Peter Senge and learning disciplines—that really the only differentiator is how quickly we learn.
John Grout:
Yeah, absolutely. And I have to say, it was a point of pride for me that I bested a really good math professor and a really good physics professor working together on what was going to be a beautiful, sophisticated tower. It was amazing. And they couldn't get it from horizontal to vertical. It fell apart.
Mark Graban:
And what you're describing sounds like a fun, larger outdoor activity, a variation of a similar competition using uncooked spaghetti and marshmallows as at least two of the main ingredients of that same challenge of building the largest tower you can in certain time constraints, right?
John Grout:
Oh yeah, absolutely. It was called the Grand Challenge, and I think that the organizer just scaled all that stuff up.
Mark Graban:
Yeah.
John Grout:
And it was a lot of fun.
Mark Graban:
And I think one of the takeaways in the write-ups I've seen of the spaghetti tower building competition is that—and this is probably true—kindergartners will outperform MBA students. And I have an MBA, so I'm not trying to throw stones outside of my field. But they said the kindergartners were not afraid to just try things and to make mistakes, whereas the MBA students had maybe this analysis paralysis of, “We are going to think our way to the right design and then build it,” as opposed to building, failing, learning, building again, moving on.
John Grout:
Yeah. So Tim Harford has a TED Talk from 2012 where he talks about the “God complex” and trial and error. And that's exactly what he's saying. He's saying, “Look, do trial and error. Don't think you know what's going on until you actually know what's going on.” And I would agree with that. It turned out to be very powerful for me on the Grand Challenge.
Mark Graban:
A final thought about that competition or that approach that again makes me think of entrepreneurship and even improvement within an organization is that doing these small tests of change is a way of mitigating or preventing larger mistakes. I'll just share one example, and I'm sure you've got examples to share. Let's say somebody in a hospital has an idea that involves buying something that they would have at every patient bed throughout the hospital. If they've made a bad decision, if they've made a mistake, it's the cost of that times 300, and they might have to eat the cost. I remember asking and challenging, “Well, what's a smaller test of change?” And they said, “Well, we could try it on one unit.” I'm like, “Well, could you go smaller?” And they're like, “We could buy one; we could see how it works on one bed and then maybe move on from there.” Because there were all sorts of risks of what we didn't know. Could this thing be cleaned? How durable would it be? Would people use it? It was meant to be a way of helping patients not let their glasses and their phone and things fall onto the floor. But I think that small test of change prevented the big mistake where then people feel stubborn, like, “Well, I can't admit that was a mistake.”
John Grout:
Right. You're too invested at that point. And that's a real problem. There's a hospital in Wisconsin that's part of ThedaCare—it may have changed names now; I think it was acquired—but they were in an old, old facility, and they actually tore two patient rooms out of the building, took it down to bare walls, and they put in one prototype room. It was just wallboard; there was no spackle. I mean, it was just really rough. But they then put in light fixtures, they put in the bed. They said, “We think we're going to have the bathroom over here on the headwall,” which makes it way better. And they had people—everybody in the hospital could come in—and there were papers all over the wall where you could say, “I like this,” or “I hate this,” and “Here's what we should do about it.” And so they had had everybody in the building tour this one patient room before they built any other patient rooms.
Mark Graban:
Yeah.
John Grout:
And when they said, “We hate this,” they could go in and change it because they had a couple of two-by-fours invested in it. And so to my mind, that's the way to go.
Mark Graban:
I've seen a lot of organizations—and this has spread into healthcare—doing what we might call rapid prototyping, using cardboard or foam core or something that's not concrete and drywall to test the layout of a facility. You can simulate; you can push a real hospital bed with a real person in it and make sure, “Can we actually get around that corner radius of the hallway?” If we have the workbench and an exam room set up, does our hypothesis of, “Well, now the provider doesn't have to turn their back to the patient”—you could go and test those things. It's far, far less expensive to change cardboard than it would be to rip down drywall and concrete. And we're less wedded to that idea when it's cheap.
John Grout:
Absolutely. In fact, Kaiser Permanente has a warehouse in an industrial part of Oakland where they do exactly that. They'll have whole offices mocked up inside this building. Chick-fil-A does this. They were bringing out a new facility in New York City, and none of their existing designs would match the cramped, expensive space in New York City. And so they built a foam core example of what they were going to build in New York City in a warehouse just off of their corporate headquarters, southwest of Atlanta. So, yeah, lots of people are doing little experiments first. And so I think my goal with students, we always call it “hello, world.”
Mark Graban:
Because it's a programming thing, right?
John Grout:
Yeah, it's a programming thing where if you're going to learn a programming language, the first thing you need to do is be able to write three lines of code, compile it and run it, and have it actually do something that you can predict in advance it will do, which is send a message to the screen that says, “hello, world.” And so, some kid comes up to me in the Creative Technologies program and says, “I want to build a hovercraft.” And you say, “Well, so tell me what your ‘hello, world' is going to be. What's your first project going to be, and how can you get it done in about a week or a week and a half?” Because if it takes longer than that, you'll never finish.
Mark Graban:
Yeah. So it could be a mistake to take on some sort of challenge like that. And again, I think maybe we're preventing big mistakes by making small mistakes. I think there's a good lesson there. ThedaCare, I think one other quick example, a story I've heard from them: they had an idea about the need to provide transportation to patients. The initial concept was, “Well, we're going to go buy a fleet of vans.” But somebody had the sense to say, “You know what, we could rent a couple of vans and see if anyone actually calls for them.” And then if the experiment didn't play out, you just stop the rental instead of being stuck with vans.
John Grout:
Yeah, that makes lots of sense. This is a little bit of a stretch, but I think of Adam Savage from MythBusters. He wrote a book that's called Every Tool's a Hammer. And in that book, he recommends that when you are wanting to try a new tool, you always buy the cheapest version of the tool that you possibly can, take it home, use it. If it breaks, you've learned something. If it works and you love it and it fits your workflow really well, then you go out and buy the best tool you possibly can. But at that point, you have an understanding of what “best” means to you.
Mark Graban:
And I think that physical hammer idea could apply to software. You're trying to solve some challenge in your business. You could go buy a software platform, but maybe you can start testing something quick and dirty. You realize it's not going to be scalable. Or you might build something in SharePoint and see if you can make the business process work around it. Would people even use it? And then go buy a better, fitter-for-use hammer, perhaps, in software.
John Grout:
Yeah. It really suggests that there is a disruptive option for enterprise resource planning systems because typically you have to invest so much upfront on those and then hope they work. It seems to me like if anybody brought something out that was, “Just try us out, and here's where you do it,” and then you could build it out slowly instead of having to flip a switch on the whole thing… My local hospital, they're switching over all of their electronic systems to something called Epic, and they're going to throw a switch one day and hope that their organization still works. And it's a big risk. If there were any way to do that where you didn't have to have this 100%, all-at-once cutover, it would be so much better and so much more comfortable, and you wouldn't have the horror stories that you hear.
Mark Graban:
So, John, let's talk about mistakes. As somebody who has studied and researched and written about this for so long, maybe we can kind of go through some definitions as you have on your website, like what you call the strict definition of the word “mistake” and then a more common definition. Can you talk us through those and your thoughts on that?
John Grout:
Yeah. I was lucky enough to get linked up with some folks who were doing cognitive psychology and looking at mistakes from a psychological perspective, and they call them errors. And then among errors, they divide them into mistakes and slips. Mistakes are those errors that you make where you deliberate about what to do, draw the wrong conclusion, and then you do what you've intended to do, but it doesn't turn out quite right. A doctor misdiagnosing a patient would be an example of a mistake. They then talk about slips. Slips are where you deliberate about what to do, and then in your execution, you've got the right intent, but you do the wrong execution, and that's a slip. So they break it out that way. Now, there are finer ways to do that, but it's a good starting place.
Mark Graban:
So another example might be the mistake of choosing to do a surgery that other surgeons might consider to be outdated, and then you do the wrong surgery really well, versus choosing what others might deem to be the correct surgery and then cutting the wrong ligament or something that was unintended in the process.
John Grout:
Yeah, exactly. That's the distinction. And I think it's really useful because your response is entirely different depending on which one you're doing. Ironically, when I study mistake proofing, which comes from the obscure Japanese quality control technique called poka-yoke, you're really working on slips, not on mistakes. And yet, when it was translated into English, they translated it “mistake proofing.” And once those cats are out of the bag, you really can't fix it.
Mark Graban:
So there's this hierarchy, and I'm glad you clarified that because what I hear you saying is error is the highest level in the taxonomy, and then that breaks down into mistakes or slips. I've heard—and I've probably actually used—”mistake proofing” and “error proofing” as synonyms, and that's probably not technically correct.
John Grout:
Well, I think that technically, mistake proofing shouldn't be about mistakes. I try not to be a stickler about those kinds of things. If you say “error proofing,” I go, “Oh, yeah, mistake proofing, poka-yoke, error proofing—all the same thing for me.” If you want to get down into the details of cognitive science, then yeah, there might be a difference there.
Mark Graban:
Now, there might be different settings where it's easier to prevent a slip and some settings where it's easier to prevent a mistake. Thinking of a surgery setting, you may have some sort of clinical review board that maybe helps prevent somebody from making the wrong clinical decision. But then once you're in the course of surgery, you might not be able to guard against or prevent the slip of, “Oh, my hand moved unexpectedly, and now I've cut the wrong ligament.” But you could slip-proof slips of somebody handing you the wrong size implant for a knee or somebody handing you the wrong medication to administer to a patient. It seems like it's maybe very situational. How do we decide? How do we think through if something is preventable or not?
John Grout:
Yeah. I think that you can make inroads both on mistakes and on slips. So if you make a mistake on the intent or if you make a mistake on the execution, I think there are ways to address both, but they're different vocabularies that you use. For slips, there are lots of ways to do it. The way you know that you've got a slip is that you know the answer in advance. And so if you know the answer—like, that's right or that's wrong—and you know it before you ever get started, that's something that you can mistake-proof, or it's a slip that can be resolved. Generally speaking, those are relatively easy to fix using some very traditional kinds of mistake-proofing tools. And so there's a bunch of examples in the book that you mentioned at the beginning of the podcast. If you want to know more about that, that book will walk you through it.
Mark Graban:
Yeah, and I think it's fun to think through real-world examples. You mentioned Chick-fil-A, and I'm trying to think… Chick-fil-A does this, I know for sure. In-N-Out does this. The food comes in a plastic tray, and they don't have to put up a sign that says, “Don't throw out the trays,” because the hole in the top of the garbage can is literally too small for that plastic tray to even fit. You can put your papers or food waste… I would call that good mistake proofing, as opposed to restaurants where I've been at where there's just a big open container, and then instead of saying, “Thank you for coming here,” it's like, “Don't throw away our baskets.”
John Grout:
Right, right. And of course, the feel is entirely different. It's also true that you have lots of situations in industry and elsewhere where you use checklists, and checklists are a mistake-proofing device, but they're like the weakest one ever. You go to Pella Windows, and they actually have a little board laid out where all of the different fasteners that go with the window go into that board. There's a bright light behind it so that if there's something not there, it blinks at you. And once all of the parts are there where you don't see the light, you flip the thing over into a funnel that puts it in a plastic bag, and away you go. That's a much more effective kind of surrogate for a checklist than just looking through a bag of hardware and checking off that they're all there. Because normally, workers will fill the bag and then go, “Check, check, check, check, check, check.”
Mark Graban:
Right. We've all seen…
John Grout:
And at that point, it's not doing its job.
Mark Graban:
I mean, I've had a checklist for running webinars and a checklist for podcasts. And where I've gotten in trouble is when, guess what? I didn't use the checklist. I thought I knew how to do this now without error. And then you get a little bit cocky and you think, “I don't need it,” and then oops. That's where I think in surgical circles, they really emphasize—they do this in aviation—you always use the checklist. No matter how many consecutive successful takeoffs you've had, always follow the checklist.
John Grout:
Right. And when they get into trouble, it's because they didn't follow the checklist. Now, the way to know if you have a good checklist on your hand is if it speeds you up. When I'm packing for a trip, I can spend a lot of time thinking, “Now, did I get everything? Do I have everything?” But if I use a checklist, I can go down the list. When I get to the bottom of the list, I go, “I am done.” And provided that after years of travel, that checklist has been refined… it's well done, and I have a lot of faith in it. And the only thing I have to attend to in terms of my own mental capacities is, “Is there anything unusual about this trip where I need to bring something that I normally don't bring?” And then I write that down, and when I'm done, I know I'm done. It means packing for almost any length trip is 15 minutes to a half an hour at the most.
Mark Graban:
Yeah, well, I think that's a really interesting point about, “A good checklist should speed you up,” because that's one of the concerns or the pushback you'll get. I think of the popularity of checklists or attempts at making them popular in healthcare—Dr. Atul Gawande's book, The Checklist Manifesto. And there's this concern of, “We don't have time to follow the checklist,” which is an odd argument. It's like, “Well, you don't have time to do it right?” That's a little bit troubling. But it sounds like it doesn't have to be either/or. You can have a good checklist that doesn't slow you down.
John Grout:
Right. And the longer the checklist, the more doomed to death it is. But Peter Pronovost did a lot of work in the state of Michigan that led up to Dr. Gawande's book. And he has really good, statewide evidence that if you think you don't need a checklist—at least in that case—he's really shown that that's not true, that the checklist makes a world of difference.
Mark Graban:
And I agree with you. Checklists are not the most effective, 100% effective form of mistake proofing. I think even weaker than a checklist is what I call the awareness signs or the “be carefuls” or the cautions. It's like, well, if those worked, we would hang signs in every operating room that said, “Be careful, don't operate on the wrong side of the patient.” But that sign… I wouldn't believe the hypothesis that that sign would help.
John Grout:
So that leads me to the conclusion that human performance can only be improved on a marginal basis. If you need a 5% improvement, you may be able to get that from a human being by telling them to be more careful. But it's going to be transient; it's going to wear out. Then you've got this Sisyphean task of trying to keep people aware all the time. And that's just not the way the human mind works. It is so much better to make a design change to allow that mistake to be revealed without trying to improve the person. If you can create a design feature that will help people understand that that's wrong, don't do it… that's going to work. It's a finite investment that's going to be made and be done, and you get to amortize it over however long you do that project. So it's very affordable, and it will be effective in the long term, whereas those signs that say “be more careful” will blur into the background of people's lives very quickly.
Mark Graban:
Yeah. I can think of maybe just one other example I would share. I think of error proofing within the realm of software. I have at least a couple of times booked a flight for the wrong date. It was probably more of a slip than it was the wrong intent. There are attempts, like, there'll be a screen that says, “Is this what you're intending to buy?” And it's very easy just to gloss over that and say, “Well, of course I'm buying what I clicked.” And then you find out maybe a week later, “Oh, I did that wrong.” And now you might be hit… well, they're not doing change fees right now, but the fare might be higher. There might be a penalty to that.
John Grout:
Yeah, could be very costly.
Mark Graban:
But I think a better form of error proofing, when I think of paying a credit card statement bill either on a website or an app, I've also made the slip of accidentally paying a bill three days late. Now I get hit with a late fee, and now I'm getting hit with interest charges when I was intending to pay it off on time. Part of me thinks, well, maybe it's not in the credit card companies' interest to prevent me from paying it late. But I think now, more recently, I think of different apps where it basically brings up a couple of very quick options of “pay now” or “pay on due date,” and then to pay on some other date might require a few extra steps. But I feel like that's at least better error proofing. Or maybe autopay would prevent that.
John Grout:
Absolutely. Oh, and by the way, when you want to delete a file, how often do you click the file name, you click delete, and then it says “yes” or “no”? And no one goes back and says, “Oh no, wait a minute, do I really want to get rid of that file?” You've already made that decision, and now you're just executing a schema, a subroutine that involves clicking the “yes” button.
Mark Graban:
Well, if it's delete, though, at least on most systems, there's a good “undelete.” The mistake, the slip I've made is the pop-up that says, “Do you want to save changes? Yes or no?” And I'll click “no,” and then those are lost forever. Oh yeah, why did I click in the wrong place? Such is the human condition.
John Grout:
But your intent is pretty well fixed at that point, and you're executing on that intent, and your deliberation was wrong. It's much harder to mistake-proof that.
Mark Graban:
But there might be a case, just thinking through, where let's say if there was a keyboard shortcut… these dialog boxes that pop up, often if you hit the return key, it chooses one. It's probably better to choose, if you were to hit the return key, for that to activate the “yes” to save, because then you could always cancel out of that. If the default, if hitting the return key was, “No, I don't want to save,” that might be unrecoverable.
John Grout:
Yeah. So one of the things that you find about good design is it's really hard to get right. Because there have been times when I've made a change to something, and I had an archival record, and I pulled it up, and I wanted to make a change for the new version, and I saved it under the archival file name. And then again, you've lost your data. So the trick is, you don't know if you really want to save the changes or if you don't want to save the changes. And so that one is much tougher. And a lot of these techniques are very subtle. Making a good mistake-proofing device ought to be easy, but you find that when you get into the nitty-gritty of it, it takes a lot of thought and a lot of care. And you really ought to experiment to see if it does exactly what you want it to do, because you can cause troubles as well as fix troubles. Now, if the trouble that you cause is much less than the trouble you're fixing, that's probably a good thing. I mean, I take aspirin even though I know that it could cause a stomach upset. It never has for me, and so I continue to use it. And it's way better than feeling the pain.
Mark Graban:
Yeah. And I think of maybe just one other example here. You think of, let's say, a gasoline pump for your car versus the diesel pump. People could go and try this. It's impossible to accidentally put diesel into a regular gasoline vehicle because the nozzle is bigger. You could accidentally put unleaded fuel into a diesel vehicle. But my understanding is that putting diesel into a gas engine would be far more harmful, so they've chosen to error-proof it in that direction.
John Grout:
Yeah. I once had a diesel Volkswagen that a young man who was a friend of mine wanted to borrow for the prom. It was back when the new Beetle was brand new, and it was just the thing. I had one, and he wanted to drive it. He drove a classic Beetle, which he traded us for 24 hours. And I said, “The one thing you may not do is fill this car up before you return it,” because I knew he was going to put gas in it, and it needed diesel. Although Land Rover had a fix for that where the larger-caliber diesel nozzle would actually open a clamshell that would keep the gas from flowing into the tank.
Mark Graban:
Oh.
John Grout:
So while you get a good engineer involved, there are lots of ways to fix the problem. Interestingly, oftentimes the way you fix the problem is by saying, “How can I make this process fail, but fail in a way that's benign instead of fail in a way that's terrible?” And at that point, all of your failure analysis techniques become a tool to invent something new. And that's kind of a fun process.
Mark Graban:
So I'll ask one more question before we wrap up. Just a recollection real quick: there was a period where my wife and I owned one diesel vehicle and one unleaded vehicle, and that caused a lot of mental stress of thinking… I managed to avoid that mistake, but I'm glad. Maybe an electric vehicle is in our future. But now we're back—no diesel, just unleaded fuel.
John Grout:
Yeah, it's just one less thing to worry about. So when you get your electric vehicle, then you can have range anxiety instead.
Mark Graban:
The mistake of thinking I plugged the charger in, but it was a slip, so I didn't really get it right.
John Grout:
So I happen to own a plug-in hybrid that's all-electric in the sense that there's no driveshaft in the vehicle; there are only electric motors. And everybody I talk to says sooner or later, you're going to forget to charge your car. It's going to happen. And so, yeah, it's an ongoing concern, although the same is true for your phone. I find that charging my electric car and charging my phone—it's the same process. And I happen to do them both at the same time because routine is another way of reducing error. Just getting it to be a subroutine that you call every night at 9:30: you plug in your phone, you plug in your car, you go to bed, if that's what you do at 9:30 at night.
Mark Graban:
So John, I want to ask one other question. This comes back to terminology again. Is it a mistake to use language… we hear people say these things: “foolproofing” or “idiot-proofing” or “dummy-proofing” is another one I've heard.
John Grout:
So I understand what all of those mean. I choose to translate those as “mistake proofing.” I'm not sure I would ever correct someone if they said “idiot-proofing.” But I think that in Japan, they started out with baka-yoke, which was foolproofing, and a worker took offense. And I just think we live in a world where offense is easily taken, and it's costly. If you don't cause offense, it's so much better. And so, have I seen the little signs that say, “If you foolproof something, the world will just come up with a better fool”? Yeah. It's a headwind I don't need. And so I choose not to correct people on that, but I also choose not to use those terms.
Mark Graban:
Sure, fair enough. So everybody makes mistakes, even professors, even professors who study mistakes and mistake proofing.
John Grout:
I'm not just a researcher; I am a customer, too.
Mark Graban:
Our guest again has been John Grout from Berry College in Rome, Georgia. I do recommend his website, mistakeproofing.com, and again, especially if you work in healthcare, check out the publication Mistake-Proofing the Design of Healthcare Processes. That's a PDF that you can find freely available online. So, John, thank you for those materials and thank you so much for being a guest today. It's been a lot of fun.
John Grout:
Well, thank you very much.