Chapter 14
Normal Data and
Team Norms
Guiding the Six Sigma Team
in the Analyze Stage
BY THE TIME YOUR SIX SIGMA TEAM REACHES THE ANALYZE STAGE, you’ve probably ironed out many of your personal problems and begun to work routinely by the norms set in its early ground rules. Respect for one another’s opinions now comes from working together and the fact that opinions are based on data. The project is becoming clearer as data comes in, and team members are willing to learn new tools to analyze the data.
This doesn’t mean that storming can’t reappear: it can, but now much of its energy will be focused on problems of analysis and impatience to find the cause of the problem being studied, rather than on the personalities of other team members. Nevertheless, there are ways to prevent the recurrence of storming at the same time the team moves its work along. These include:
1. Draw attention to progress the team’s already made.
2. Fix “low-hanging fruit” and build some momentum.
3. Revisit and update team ground rules.
4. Pay more attention to how the team works together.
Let’s look at these in more detail.
1. Draw Attention to Team Progress
“When a tree falls in the woods and there’s no one there to hear it, there isn’t any sound. I know. I was there in the woods when it fell.”
There are two kinds of progress the team should be making by the time it gets to Analyze. The first has to do with progress on the Six Sigma project and how to get the word out to others in the organization. The other has to do with the progress the team has made internally, evolving from a group of people into something resembling a team.
Project Progress: Update Your Storyboard
Updating your storyboard is important at every stage of DMAIC, but particularly so here. It is your work in this stage that determines what actions you’ll be taking in the next stage—actions that will likely affect many other people outside the team. Informing people of your progress in confirming (or disproving) causes will help them prepare for the upcoming changes.
2. Build Momentum by Fixing “Low-Hanging Fruit”
To paraphrase an old saying, “Nothing motivates a team like success.” If a Six Sigma team has to wait six months or longer before its sees some improvements in the process it’s working on, there’s likely to be a drop in motivation within the team. To prevent this decline, once data begins to throw some light on the process, the team needs to start fixing some of the obvious things in the process that need fixing, the so-called “low-hanging fruit.” Where these improvements can be made, teams gain a boost of energy to continue work on the “high-hanging fruit” that will probably be harder to pick off.
The risk, of course, is that in “fixing” obvious problems, the team will be tinkering with the overall process, and add to the variation in it, or otherwise muddy the analytical waters. To avoid making things worse by tinkering, the team should fix things that are obvious and that data show are really causing problems.
If a process map shows a bottleneck or a hand-off so tight it’s often missed, the team should make some improvements. The result will be a shortening of cycle time, and perhaps a reduction of defects due to missed hand-offs. Or a new person may not have trained on a particular procedure and is having problems making it work. They need to be trained. The risk of tinkering in such cases is slight. Measuring the impact is important, and overall the team can see some incremental improvement resulting from its efforts.
Major changes in the process should be avoided until essential data has been collected and carefully analyzed. Introducing major new procedures or computer software and the like will have to wait until the problems they might solve had been tracked to their origins.
3. Revisit and Update Team Ground Rules
The ground rules that the team needed in its early days of Defining a problem and project usually need to be revised and updated in the Analyze phase, if not earlier. For example, early rules on “respecting everyone’s opinions” will need to be revised as the team comes to rely more and more on the analysis of objective data. How can I respect the opinion of someone on the team who refuses to use data, or analyze it, and relies instead on bluff and bluster to get their way? The old ground rules need to be discussed, amended, and added to as the team matures.
This discussion is all the more important because debate around the meaning of data and how to proceed from it can get heated as the team moves toward implementing solutions for problems. As it begins to pinpoint the cause of problems, the team may have to add “No cow is sacred if it’s causing problems” to the list of ground rules. As the team gets closer to making actual changes in the organization, anxiety often begins to build up and otherwise cooperative team members may start drawing lines in the sand. Ground rules will help to prevent those lines from becoming high walls.
And just in case anyone has doubts about the importance of ground rules for the team, these should remain an item on each team meeting agenda. At each meeting, it’s worth a few minutes to discuss (not simply read out loud) one of the ground rules. If “Be on Time” is one of the original rules, it’s OK in Analyze to discuss why it’s imperative to be on time for meetings: it saves rework bringing latecomers up to speed, shows respect, gets things done on time, etc. These discussions prevent ground rules from becoming just formalities, and remind people that part of the Six Sigma culture is doing things according to agreed-upon processes. Ground rules are the measurable requirements for the Six Sigma team.
4. Pay More Attention to How the Team Works Together
The ultimate goal of the Six Sigma team is not simply to improve a process and increase customer satisfaction, important though these goals may be. Of even greater importance is the new way of doing things in your organization. The Six Sigma way is to gather data, analyze it and then learn from that analysis.
The Six Sigma team needs to learn about itself by studying its own activities and processes. How the team operates and how its members work with one another provide opportunities for learning that far too many teams ignore in their desire to solve problems and “get the project over.” If this is the mentality of many teams, it’s no wonder that things don’t really change for the better in most organizations.
How does the team learn about itself?
If the team has been using ground rules and evaluating each of its meetings, it will already have an informal “database” about itself. From time to time, the Black Belt should lead a discussion about this data, pointing out the things that have improved or gotten worse. The Black Belt should also call attention to the following actions when they appear, for they are signs of growing maturity in the team:
♦ Members of the team other than the Black Belt point out infractions of ground rules.
♦ Team members volunteer for assignments.
♦ Team members volunteer to assist other team members in completing their assignments.
♦ Team members willingly take over the facilitation of a meeting even though the Black Belt is present.
♦ People avoid the use of “I agree with what you said, but….” Instead, they genuinely try to build on what others have said or done.
♦ People stick to the point under discussion and avoid tangents.
All of these are signs that the group of people who came to the first meeting with their own interests and agendas are gradually evolving into a team with common purposes and methods.
Thinking about this evolution (or the lack of it!) will help the team learn about itself. The hope is that team members will carry these behaviors back into their “real” jobs and departments, and begin to change behaviors there, too. Where b.s. and bluster continue to rule meetings, we can’t expect to introduce tools like run charts and histograms successfully!
These improved team behaviors will be very important as the team moves into the challenging area of developing and implementing solutions for the problems it was chartered to solve. Improvement is the subject of the next chapter.
Troubleshooting and Problem Prevention for Analyze
Failure #1: The Team Bogs Down in the Paralysis of Analysis and Can’t Identify Root Causes of Problems and Unwelcome Variation
Why this happens: The tools to analyze the data collected range from simple comparative logic (“Does the data explain why we see this problem in Chicago and not in Los Angeles?”) all the way to measures of statistical probability and multivariate analysis. Some teams resist concluding that they have in fact discovered the major sources of variation in their process, and keep looking for “one more proof.” The team heaps up reams of statistical proof when it should be moving on to improvement.
How to prevent it: At the end of the day, statistics only offer us probable proof of the causal relationship between key variables and key outputs. These probabilities must be balanced by the common sense and experience of the team. Teams should only use enough statistical analysis to reach reasonable conclusions of cause, and then manage the risks of improvement. To paraphrase an old saying, “If the only tool you have is statistics, everything looks like a correlation coefficient.”
Failure #2: Jumping to Conclusions About Causes Before All the Data Is In
Why this happens: Of all the challenges facing Six Sigma team members, reaching this step without having already made up their minds about the cause of the problem/defect may be one of the toughest! After all, team members were most likely chosen because they have some relevant experience or knowledge about the process or problem—which means they’ve likely been living with the “defect” for some time, and naturally have their own theories about what’s going on. And in the long run, having well-informed ideas about causes is what’s going to lead to a permanent solution.
How to prevent it: While you can’t really prevent people from making up their minds early in the project, you can prevent their decisions from harming the project by insisting that the team have data to back up its conclusions. Remind the team that they will be asked by their Sponsor and others to show what led them to their conclusions. Make sure that you encourage open-minded thinking during brainstorming discussions, especially when it comes to creating a cause-and-effect diagram, for instance.