Six Sigma Pizza - Pie 6

So far...

We have started the story of a pizza outlet and his owner, Ben. We discussed the problem areas - broadly the top line problem and bottom line problems. We had conducted a survey of focused group (students), collected their feedback, applied Kano Model to prioritise their requirements. In the previous chapter, we started converting the requirements from customer language to our process language.

We reached the stage of identifying points that are Critical to Customer Satisfaction (CtS) aka the Drivers.

Now

Why measure?

I could see some of the participants are feeling hungry, as tempted by the service manager's animated explanations of tasty pizza.

Since Ben was quite focused on the next step, I started cajoling my appetite to wait for another 10 minutes.

"As we understood earlier, it is somewhere here we miss out what the customer wants. We try to make things better without knowing how it could be ‘measured’ and our perceptions vary. But the mantra of problem-solving is

In God We Trust; Others Bring Data

So, we need to move from our perceptions to something measurable. What can we measure in this scenario?” I threw an open question.

People shared their thoughts -

“Measure how much steam comes out of pizza”

“Sufficiently hot pizza at the serving table”

“How long does the pizza steam after serving”

“Thickness of base”

“How much time the pizza was baked - because, with rapid heating, the outer layer gets heated quickly and such pizzas will cool down quickly as well”

Critical to Quality (CtQ)

We wrote down all the things that refer to the steaming pizza and could be ‘measured’. For the driver of Steaming Pizzas, we derived two CtQs namely, Sufficiently hot Pizzas at the time of service and Thorough (with respect to baking time) baking. “Now, these two factors to be further drilled down to Critical to Quality or CtQ attributes”.

By that time, Ben realised that we are due for our most awaited lunch break and asked, "Hey guys, don't you want to have fresh pizzas, with bubbling cheese? I asked them to get our lunch ready by 1.30."

This signalled a lot of relief to most of them. But none of us was seriously interested to point out that we are going to miss the fresh pizzas because of Ben. We agreed to make the break a short as possible.

Project y

When we came back, we started to explore further. We cross-checked all the CtQs for their relevance and validity.

We asked questions like ‘if we improve the temperature of pizza just before serving, will it meet the need of steaming pizza?’, if we find out the right brand of cheese, will it improve the 'bubbliness' (?!) or the melt-flow of cheese?’ and so on.

Then I started “Now we come to the most important point in the drill down exercise".

"What? one more lunch break?" Anand opened up a laughter.

I tried to get them back on track and continued, "Now we need to convert all our CtQs into Project ys. From this point onwards, we are going to focus on these project ys. Because this is what we are trying to achieve in coming 3 to 4 months of time. If we could achieve what we plan with respect to project y, we can see our business problems are getting reduced.

“What is this project y? And why is it called project y?” Ben expressed everyone’s concern.

Let me explain. I drew a tree.

This is a beautiful mango tree which you planted 7 years back. Its fruits are so tasty and juicy. It was giving you numerous fruits till last year.

But suddenly this year, the size of fruits became smaller, they looked unhealthy and tasted sour. You are wondering what has happened to the tree. Then you observe that the branches were also grown weak, the bark is peeling off and the truck is infected.

You started applying pesticides and chemicals on the fruits, on the branches and the trunk - thinking that there were problems. But your problem persisted.

You then began to inquire the neighbouring farmers and one of them told that your root could have been infected. When you worked on the root problem, you start to see the benefits.

Similarly, our business problems are just symptoms, whereas the real cause of symptoms is different.

During the initial phase of problematic conditions, we start working on the symptoms thinking that they were the problems. When they persist, either we intensify the treatment or withdraw our efforts.

But, the DMAIC methodology helps us to understand the relationship between the problem (symptoms) and the factors (root causes) giving those problems. We try to establish the relationship between the problem and its causes with a simple mathematical equation,

y = f (x1, x2, ...xn)

Where ‘y’ is a part of the main problem and x’s are the factors causing ‘y’.

In our case, we will verify each of CtQs for whether they directly represent one single parameter that could be measured during the process. If the CtQ qualifies the test, we will consider it as one of our project ys.

If the CtQ is not a single process parameter and/or if it could not be directly measured during the process, we will split the CtQ into multiple project y’s.

Remember, DMAIC is a point optimisation tool. The narrower the scope (project ‘y’), higher will be the intensity of benefits.

As we came to the end of the day, I proposed a homework for them to think of all the possible metrics that could cover the CtQs listed in the table and called the day.

We met the next day with a lot of tasks to complete. People had come with their homework done and Anand had already filled up the table wth the list of project 'y' he collected from the team.

I appreciated him and the team for their commitment and involvement in organisation's betterment. We spent another couple of hours to discuss and the updated table looked like this -

Project selection for 1st Wave of Implementation

Then I continued,

"Now we have as many as 10 to 12 project y’s to be attended. If we have a deeper look into them and apply some of your business expertise, we can easily figure of top 3 to 4 project y’s that will have the maximum impact on the problem".

"We will choose them as our projects for the first wave of the improvement initiative".

Without prolonging the suspense of Waves and with my understanding about their inquisitiveness, I told them "generally the improvement initiatives will be managed as ‘waves’. As we just saw, an organisation could not handle more than 4 or 5 projects at a given point in time".

"It is also important that the six sigma projects to deliver breakthrough improvements. For that, the teams should have absolute clarity on what are they going to do and laser focus on the projects".

"And this is what you mentioned as the pie of the 16-inch pizza, earlier. Am I right?" Asked Ben.

I really got moved by the attention to details of Ben and his entire team. I gestured him a 'hats-off' and continued.

"To achieve these we recommend 2 points to take care.

1. To have only top priority pain areas to a number of 3 to 4 at a time and
2. To scope them right - to right-size the expectation from initial waves.

"That means, we could not solve all the problem at once and we could not solve all the aspect of one problem at once. Hence, we undertake projects in waves. One wave means one set of projects".

Next

Will see how the Pareto principle is applied using the Pareto chart and its usefulness in project selection. We will also see various ways of arriving at a right set of projects that will help the organisation to improve its processes more rapidly and effectively.