By Rick Townsley, Ph.D.
Editor’s note: In this four-part series, contributor Rick Townsley offers a lively, if imaginative, look at an ISO 9001:2015 implementation at a single small business. In part one, we were introduced to The Pizza Shack restaurant and some various problems they were having with quality, customer service, and training, among other issues. In part two, Mario and Luigi begin to apply the principles of ISO 9001:2015 to improve. Here, in part three, they talk about the mission of the business and try out a new product. Any similarity to actual businesses are purely coincidental.
Some weeks later, Mario and Luigi meet in the back office for some follow-up talks and reflection. “Pop, have you ever thought about exactly what we do here?” asks Luigi.
“You’re kidding, right? We make pizzas. What kind of question is that?”
“It’s a good question,” Luigi responds, smiling, “Because we do more than just make pizzas. We’re satisfying a need (4.0, Context of the organization; 5.1.2, Customer focus; and 8.1, Operational planning and control). Why do our customers continue to come through that door?” (4.2, Understanding the needs and expectations of interested parties).
“Because we make good stuff with quick service at a reasonable price,” Mario quickly responds.
“Exactly. So how do we achieve these things? The answer is consistency—a great pizza every time. So how do we ensure consistency?” (4.4.1, Quality management system and it processes). Remember the example with Robert. He tries but maybe we need to help him (7.1, Resources; 7.1.6, Organizational knowledge; and 7.2, Competence). A good place to start might be to document a process for him to follow (8.2, Requirements for products and services), sort of like a recipe. Now don’t laugh, but I think we should document this process (7.5, Documented information; 5.1, Leadership and commitment; and 10, Improvement). We rely on you most of the time to make the pizzas or to supervise. This has, for the most part, worked out well, or Jack would have written us up for a finding during the audit (8.1, Operational planning and control). But what about the times you’re not here? I’ve noticed you’re slowing down a bit, as you should. You deserve it” (4.1, Understanding the organization and its context).
“What are talking about?”
“Well,” Luigi calmly replies, “let’s say that something was to change, for example, the oven temperature, the dough, the toppings, whatever. We would want to capture these changes without having to rely on you all the time (7.1.6, Organizational knowledge). We would need to know the name of each pizza recipe, who created the recipe, where to find it, the date it was created, and the revision (7.5.2, Creating and updating documented information). That’s you for now but at some point, that may change” (4.0, Context of the organization).
“Son, this is a pizza shop, not a science laboratory!” snorts an astonished Mario.
“Trust me on this Pop. It makes sense. Besides, how long will it take to pull together a type of recipe book? We got a new oven last month. It works a bit differently than our older ovens, right?”
“Yes,” replies Mario. “You have to lower the temperature a bit.”
“Has that been documented, Pop?” Luigi asks, already knowing the answer.
“Ahh, no, but I can do that” (8.2.4, Changes to requirements for products and services; and 184.108.40.206, Control of changes to documented information).
“Does this change anything else?”
“No, that’s all,” Mario replies (8.5.6, Control of changes).
“You know, Pop, as I said before, you’re not getting any younger. We can benefit from documented processes. We can ensure the same quality every time, every year, the same way you do it. Think about it Pop, this could be your legacy! (7.1.6, Organizational knowledge; and 10, Improvement). We should also consider a training matrix to ensure that nobody is left out (7.2, Competence), especially if we expand later (4.0, Context of the organization).
“I am a legend; I like it!” exclaims a proud Mario with chest puffed out.
Mario has an idea
“Oh, you know son, that reminds me,” Mario exclaims. “I’ve been thinking of a new pizza offering. Something different that people will like. Nothing too complex, something we can whip up in a hurry” (8.3.2, Design and development planning).
“OK, so what will we need?” asks Luigi.
“Well, first we will need a name,” replies Mario. “How does Atomic Pizza sound?”
“That depends on what’s in it; what makes this different from our other pizzas?”
“I wanted something that will be spicy and explode with flavor. Our customers will be lined up out our door to get this pizza!” Mario boasts
“OK, I’m writing this down Pop, please continue” (8.3.3, Design and development inputs).
“We’ll need extra oregano, hot peppers, sharp cheese and the crust—let’s not forget the crust,” explains Mario, almost salivating. “We’ll add garlic pepper to the dough. Yes, yes, I’m liking it. I’ll control it all!” (8.3.2, Design and development planning).
“Calm down there, Pop,” Luigi jumps in, “you sound like a crazy person.”
“I’ll try this out by offering free slices to the next 50 lucky people to come in that door. I’ll prove it’s as good as I imagined, you’ll see” (8.3.4, Design and development controls).
Later in the day, Luigi has an update. “Pop, the results are in: 35 people liked your Atomic Pizza and said they would buy it if it was offered, 10 people were indifferent and may or may not buy it, and five people scorched their tongues” (8.3.5, Design and development outputs).
“OK, we got a 70-percent approval rating. Not bad for something I never tried before.”
“Pop, did I mention that five people scorched their tongues?” replies Luigi, to put things in perspective.
“Yeah, so that’s only 10 percent,” Mario states, with less excitement.
“Really Pop? We can’t accept that,” replies Luigi in disgust (8.7, Control of nonconforming outputs; and 9.1.2, Customer satisfaction).
“OK, so I’ll look at toning it down a bit. I wasn’t planning on that outcome (8.3.5, Design and development outputs) when I put this together (8.3.3, Design and development inputs). I’ll cut back on the hot peppers, but I will not change my crust!”
“Just make sure you revise your recipe and discard the old one,” responds Luigi (8.3.6, Design and development changes). “Technically, Pop, we should consider the five unhappy customer responses as a complaint. After all, they were hoping for an enjoyable experience, not a trip to the O.R.”
“Stop exaggerating, no one went to the O.R.,” snaps Mario, “But I do agree I failed to meet some customer’s expectations even though the pizza was free (8.2.1, Customer communication). Go ahead and enter this in the complaint log and, I guess, we can document this as a nonconformity” (10.2 1, Nonconformity and corrective action).
“So Pop,” says Luigi, looking for confirmation, “to ensure I have all this documented, we’ll log this incident as a nonconformance based on some customer dissatisfaction. Your actions will be to modify the recipe to tone it down a bit to control and correct, right?” (10.2.1, Nonconformity and corrective action).
“That’s correct,” confirms Mario. “Maybe next time, we’ll try a new recipe out on our staff for input before serving it to our customers” (6.1, Actions to address risks and opportunities).
In part four, The Pizza Shack team ties up some loose ends and looks forward to a bright future.
About the author
Rick Townsley, Ph.D., is a Principal QA Engineer at Raytheon in Largo, FL. He holds a Ph.D. in business administration from Kennedy-Western University in Cheyenne, WY. A senior ASQ member, Townsley is an ASQ certified quality auditor, engineer, and manager of quality/organizational excellence. He is also an Exemplar Global QMS auditor.
©, Rick Townsley. All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission from the author: email@example.com.