toc

Team LiB
Next Section

Rath & Strong's Six Sigma Team Pocket Guide
Rath & Strong's Six Sigma Team Pocket Guide
by Mary Federico and Renee Beaty ISBN:0071417567
McGraw-Hill © 2003 (176 pages)

This guide explains the non-technical skills necessary to make Six Sigma really work: how to get a new team started, lead Six Sigma team meetings, avoid the causes of failure for a Six Sigma project, and how to plan the people side of a Six Sigma project.

Table of Contents
 | Rath & Strong’s Six Sigma Team Pocket Guide
 | Introduction | - | Why Team and Influence Skills Are Required to Make Six Sigma Projects Work
 | Part I - Getting the Six Sigma Project Team Started
 | Chapter 1 | - | The Role of the Project Team Leader
 | Chapter 2 | - | The Role of the Project Team Member
 | Chapter 3 | - | What to Do at the First Six Sigma Project Team Meeting
 | Chapter 4 | - | How to Establish Project Team Goals, Roles, and Procedures
 | Part II - Team Skills Needed to Successfully Complete a Six Sigma Project
 | Chapter 5 | - | How to Have an Effective Project Team Meeting
 | Chapter 6 | - | How to Make Decisions on the Project Team
 | Chapter 7 | - | Three Ways to Handle Project Team Conflict, and When Each Works Best
 | Chapter 8 | - | How to Deal with Difficult Project Team Members
 | Chapter 9 | - | How to Figure Out What's Wrong When the Team Isn't Working Well or Loses Momentum
 | Part III - Getting Buy-in for Your Project
 | Chapter 10 | - | The “Politics“ of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team
 | Chapter 11 | - | Five Ways to Influence People to Cooperate with Your Six Sigma Project
 | Chapter 12 | - | How to Communicate with People Whose Help You Need
 | Chapter 13 | - | How to Be a Better Listener So That People Will Want to Help You
 | Chapter 14 | - | How to Avoid the Pitfalls of E-Mail on Six Sigma Projects
 | Chapter 15 | - | How to Make an Effective Presentation About Your Six Sigma Project
 | Chapter 16 | - | What to Do When You're Not Getting Cooperation
 | Chapter 17 | - | Sample Plans for Getting Buy-in
 | Conclusion | - | Final Thoughts on Using This Pocket Guide
 | List of Tools
 | List of Sidebars

Team LiB
Next Section


backcover

Team LiB

Back Cover

Why are an alarming number of Six Sigma projects failing? The answer has nothing to do with the technical and statistical tools of Six Sigma—it’s the soft side: lack of team skills, internal politics, and bad communication. Your organization can overcome these fatal problems with Rath & Strong’s Six Sigma Team Pocket Guide.

This handy guide shows every project team leader and team member how to:

  • Avoid the leading causes of project failure
  • Get crucial buy-in and cooperation from managers and employees
  • Establish clear team goals, roles, and procedures
  • Lead or participate in productive team meetings
  • Plan the people/team side of a Six Sigma project

Team LiB


Rath & Strong's Six Sigma Team Pocket Guide

Team LiB

Rath & Strong’s Six Sigma Team Pocket Guide

Mary Federico
Renee Beaty

Copyright © 2003 by The McGraw-Hill Companies, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher.

1 2 3 4 5 6 7 8 9 0 2VKP/2VKP 0 9 8 7 6 5 4 3

ISBN 0-07-141756-7

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that neither the author nor the publisher is engaged in rendering legal, accounting, or other professional service. If legal advice or other expert assistance is required, the services of a competent professional person should be sought.

—From a Declaration of Principles jointly
adopted by a Committee of the American Bar
Association and a Committee of Publishers

McGraw-Hill books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please write to the Director of Special Sales, McGraw-Hill, 2 Penn Plaza, New York, NY 10128. Or contact your local bookstore.

To all our Aon colleagues and friends who died in the World Trade Center on September 11, 2001. May they rest in peace.


Introduction: Why Team and Influence Skills Are Required to Make Six Sigma Projects Work

Our experience in helping companies implement Six Sigma has led us to an inescapable conclusion:

Having excellent technical skills and the best technical solution is not enough to ensure successful completion of your Six Sigma projects.

By “successful completion,” we mean:

  • The process owner has accepted and implemented the improvement

  • The project has been through the control phase

  • The project realized the anticipated financial and/or effectiveness gains

  • The project was completed in a reasonable period of time, with minimum adverse effect on the team

It’s not as easy as It sounds.

We asked experienced Black Belts, Master Black Belts, and other Six Sigma experts to describe the non-technical issues that get in the way of successful completion of their projects. Here’s what we heard:

Getting team members to show up for meetings

  • Maintaining momentum on the team and keeping the team focused

  • Getting data from people

  • Gaining cooperation and support from various stakeholders

  • Convincing process owners to approve the change

In describing their ability to deal with these challenges, Six Sigma experts told us that they find these issues more challenging than those in the technical area (such as DMAIC or statistics) feel less well-prepared to deal with the issues


You can't force cooperation and support, and you can't do the entire project by yourself, so what can you do?

Team LiB

You can’t force cooperation and support, and you can’t do the entire project by yourself, so what can you do?

You can develop skills that will help you successfully

  • lead or participate in project teams

  • influence others whose help you need

The checklists, worksheets, and other job aids in this Pocket Guide are designed to help you accomplish this. Just as you’ve become familiar with the DMAIC process and (if you’re a Black Belt or Green Belt) the statistical tools, you should do the same with the tools in this guide. See what’s available and what’s appropriate, and be ready to use the right tool at the right time.


What if your organization's leaders are not doing everything you believe is necessary to make the Six Sigma initiative a success?

Team LiB

What if your organization’s leaders are not doing everything you believe is necessary to make the Six Sigma initiative a success?

What senior leaders do or don’t do has a huge effect on the success of Six Sigma, but you probably have little control over those leaders. This Pocket Guide focuses on the areas that are under your control. If you follow the guide’s advice on making your team effective and on -dealing with your project stakeholders, you’ll be maximizing your chances of success.


How to Use This Pocket Guide

Here are some some possible alternatives for getting started with the Pocket Guide:

  1. If you’re about to start work on a DMAIC team, refer to Part 1: Getting the Six Sigma Project Team Started. Begin by reading the chapters appropriate to your role as a team leader or member.

  2. If you’re in the midst of the project, consider what’s concerning you the most. Look through the table of contents and job aids for topics that seem relevant, and read those chapters first.

  3. Identify a specific problem that you’re having on your team, and turn to the Six Sigma Team Problem-Solving Grid. See if your problem is listed under the DMAIC phase you’re currently in, or under the “All Phases” section. If so, refer to the chapters identified as addressing that problem.

  4. Start with Chapter 10 (The “Politics” of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team), and identify, analyze, and create a plan for your Six Sigma Project stakeholders. As you work through this planning exercise, read the chapters referenced in the instructions.

  5. Browse through the entire guide in chapter order, so that you gain some familiarity with the approaches. Come back to the guide when you need it, for some “just in time” help.

Good luck with your project!


Part I: Getting the Six Sigma Project Team Started

Chapter List

Chapter 1: The Role of the Project Team Leader
Chapter 2: The Role of the Project Team Member
Chapter 3: What to Do at the First Six Sigma Project Team Meeting
Chapter 4: How to Establish Project Team Goals, Roles, and Procedures


Chapter 1: The Role of the Project Team Leader

The team leader (who may be a Black Belt, or someone working closely with a BB or MBB) has overall responsibility for making sure the work of the team gets done. Those responsibilities start before the team comes together, and continue after the team has disbanded.

Before

The team leader gets the team started. Tool 1-1 outlines what the team leader should do to prepare for the first meeting. For some projects, the team leader may be asked to select or recommend members of the project team. Tool 1-2 gives principles and guidelines for selecting team members.

Team Leader Checklist: What To Do Before The First Six Sigma Project Team Meeting

Tool 1-1.
Start example
Click To expand
End example

Team Leader Guidelines: How to Select the Right Project Team Members

Tool 1-2.
Start example
Click To expand
End example


During

The team leader keeps the team on track, acts as the primary point of contact to the rest of the organization, and works to gain stakeholder commitment to the project. (Refer to Chapters 3, 4, 5, 10, and 11 for help in these areas.)

Tools 1-3 and 1-4 give you ideas for the agenda for the first team meeting and some icebreaking ideas to get the meeting started.

Sample Agenda: First Six Sigma Project Team Meeting

Tool 1-3.
Start example
Click To expand
End example

Team Meeting Icebreakers

Tool 1-4.
Start example
Click To expand
End example


After

The team leader ensures that the team’s work is documented, hands the project off to the process owner, and debriefs the Project Sponsor/Champion.


Reality Check

One Black Belt we worked with was given the task of reducing mortgage approval process time from over a month to 24 hours. She knew the task was possible because several competitors were already approving loans within 24 hours, and other divisions of her own bank were close to meeting that goal. Before the first meeting she assembled and organized all the best practices she could find.

The team she had been assigned was made up of representatives from loan processing and underwriting, so at the first meeting, she assigned implementation of each of the best practices to an appropriate team member. The team members seemed cooperative and nobody objected to their assignment, so the Black Belt was surprised that little or no progress had been made by the time the team met again, and that the pattern continued over the next few meetings.

She decided to suspend the project for one meeting and discuss why things weren’t going so well. The team members were quiet at first, but soon issues began to surface. There had been no written charter for the team, so the team members weren’t sure if they were supposed to help design the new process or just do what the Black Belt told them. Some of them had never even met her, and they weren’t really sure what kind of power she had in the organization. All of the team members knew that the biggest delays in the approval process came because the sales force didn’t always get all the documentation up front, yet there was nobody from Sales on the team. Finally, a few members admitted that they were afraid they would be eliminating their own jobs if they improved the process.

The Black Belt asked the project sponsor to step into the meeting, and together they drafted a team charter that outlined the benefits for all in improving approval time. The sponsor was able to reassure the team that there was plenty of sales volume and that, while some jobs might change, everyone would still be needed. Representatives from Sales, Customer Service, and MIS were added to the team. The team eventually reached its goal, but more than a month was lost because the team leader didn’t take the time up front to use the Team Leader Checklist: What to Do Before the First Six Sigma Project Team Meeting and the Sample Agenda: First Six Sigma Project Team Meeting.


Chapter 2: The Role of the Project Team Member

The team members are responsible for making sure the work of the team gets done. Those responsibilities start before the team comes together, and continue after the team has disbanded.

Before

Members come to the meeting prepared. Tool 2-1 outlines what team members should do to get ready for the first meeting.

Team Member Checklist: What to Do Before the First Six Sigma Project Team Meeting

Tool 2-1.
Start example
Click To expand
End example


During

The team members participate in meetings, contribute knowledge/expertise, carry out assignments, and help gain organizational commitment to the project. (Refer to Chapters 3, 4, 5, 10, and 11 for help in these areas.)


After

Members may continue to work on the process in its improved form, and may be asked to help the team leader debrief the project sponsor/champion.

Team members are selected because of the diverse skills and knowledge they bring to the task at hand. While it is important that each member clearly understands his or her role on the team, roles tend to shift and become less rigidly defined as the team progresses. The effective functioning of the team is the responsibility of every team member, not just the team leader or Black Belt.


Reality Check

Over lunch one day, we were listening to a friend complain that he had been asked to be part of a Six Sigma team, and that he’d had to reschedule work in order to attend the project kickoff meeting the following week. The banter was lighthearted, but it became clear that he resented being asked to take on additional work when he already had more than enough to do.

When we asked for details about the project, and why the Black Belt who was leading the team might want him to join, we learned that he didn’t have any of this information. Nor did he know what kind of time commitment was involved... though he felt sure that it would be a huge inconvenience. Our suggestion, “Why don’t you speak to the Black Belt and get more information?” doesn’t seem like rocket science, but it honestly hadn’t occurred to our friend.

The next day our friend was able to track down the Black Belt and discuss the project. He learned from the draft team charter that the team would be working on problems with the customer invoicing process.

As it turned out, our friend had an interest in ensuring that this process worked well. He supervised a group that deals directly with customer complaints ... many of which involve invoice problems. Further, he had previously worked in the accounts receivable department in a company that had a nearly flawless invoicing process.

As he talked with the Black Belt, it became clear to our friend that he could play a dual role on the team: as a representative of the Voice of the Customer and as a source of ideas on invoicing best practices. He and the Black Belt also negotiated the amount of time our friend would need to commit to the team. Our friend went to his boss with a good case for off-loading some of his work. He joined the team and was able to make a significant contribution to the project’s success.

If our friend had used the Team Member Checklist: What to Do Before the First Six Sigma Project Team Meeting, he wouldn’t have waited passively for his involvement to be made clear. He would have approached the team leader to find out what was expected of him so he could carve out a role that made sense.


Chapter 3: What to Do at the First Six Sigma Project Team Meeting

Key Principles

What happens at the first project team meeting sets the stage for how the team performs throughout the entire DMAIC project ... and everyone on the team is responsible for getting the team off to a good start.

Taking time to solicit the “Voice of the Team” before you launch into the project tasks is a good way to avoid the Six Sigma professionals’ biggest first team meeting mistake (see page 18) and to achieve these important objectives:

  • Identifying who on the team can (and would like to) handle different project tasks, which increases the likelihood that members will actually do those tasks.

  • Aligning members’ personal and business goals with the goals of the team, which makes members more likely to commit to the work of the team and therefore to show up for meetings and complete assignments.

  • Reducing members’ needs to restate and reestablish their credentials during subsequent team meetings, which saves meeting time.

  • Giving members an opportunity to get to know each other, which builds trust, the key feature of effective teams.

Team Leader Checklist: Running the First Six Sigma Project Team Meeting

Tool 3-1.
Start example
Click To expand

Note: This follows the draft agenda in Chapter 1, Tool 1-3, page 6.

End example

Team Member Checklist: Participating in the First Six Sigma Project Team Meeting

Tool 3-2.
Start example
Click To expand
End example


Six Sigma Professionals' Biggest First Team Meeting Mistake

Team LiB

Six Sigma Professionals’ Biggest First Team Meeting Mistake

At the first team meeting, leaders tend to want to get to work on project tasks immediately. Sometimes team leaders who might be willing to spend time building the team are pressured by members to “get on with it.” As a result, little time is spent giving members the chance to get to know each other, build trust, voice expectations/goals, establish credentials, discuss desired roles, raise concerns, etc. That approach is viewed as a waste of time instead of as a necessary warm-up step in creating a high-performance team. When the team starts to have problems later, everyone gets frustrated and things can come to a halt.

Why Does This Happen?

It’s easy to see what happens when you don’t accomplish task-related work at a meeting: you still have to do it and you can start to fall behind on your project schedule. It happens immediately and the connection is obvious. Since there’s so much to do, and nobody wants to waste time, the need to go, go, go becomes overwhelming. Who has time for this “touchy-feely” stuff, right?

It’s much harder to see what happens when you don’t take the time to build the team. Sometimes the effect is not seen for a while. And most people don’t recognize the connection between not spending time building a team and subsequent problems with that team, such as people not attending meetings, tasks not getting done, time wasted in pointless discussions, inability to make decisions, people behaving badly, etc.

What Can You Do to Avoid This Problem?

It’s unlikely that you’ll be able to do your own DOE to prove cause and effect, so take our word for it: studies have shown that time spent on teambuilding pays off in team effectiveness. Resist the temptation to push for a lot of task-related work at the first meeting. Concentrate instead on soliciting the “Voice of the Team” and establishing the foundation you’ll need to successfully complete your Six Sigma project. Remember: when it comes to creating a successful team, it’s “pay me now or pay me later”!


Reality Check

One of the best first Six Sigma team meetings we’ve ever seen took place at a company in serious financial trouble. The team was under tremendous pressure to take cost out of their process, and everyone was aware that some positions would be eliminated, with people redeployed to do work that was more focused on the company’s current financial “fires.”

The team leader used the Team Leader Checklist: Running the First Six Sigma Project Team Meeting, scheduled half a day for the first meeting, and kicked it off with lunch. There was no budget, so the lunch was potluck, held in the common room of the team leader’s condo. It served as a great icebreaker to just let people chat over an informal meal, away from the tension at the office. After a brief review of the team’s charter, the team leader asked everyone to imagine what their work lives would be like if the project were a success, and then to share their ideas with the group. Some of the responses included speculation about being laid off (a possibility) or being redeployed to other positions after the project (the most likely outcome). Talking about these potential events openly eased the tension, and a few members could even see the some positive aspects to taking on new challenges. People began to discuss their skills and experiences, in light of both the needs of the project team and the possible job changes after the project.

After discussing their own potential futures, members were able to think about how their project work would affect others in the organization. They drew up an initial draft list of those whose support they would need in order for the project to succeed and how those people might react to the project.

By the end of the meeting, the team did not have a project plan with milestones and due dates. What they did have was commitment from the members to the project and to each other, and the start of a stakeholder plan. They got to this point not only because the team leader used the Team Leader Checklist, but also because the members followed the actions suggested in the Team Member Checklist. Had the leader tried to force detailed project planning or had the team resisted following his lead in discussing their goals, expectations, etc., the outcome would likely have been much different.


Chapter 4: How to Establish Project Team Goals, Roles, and Procedures

To be effective, the Six Sigma project teams must establish clear and agreed-upon goals, roles, and procedures.

What to Do:

The Goals, Roles, and Procedures Pyramid (page 22) tells you that to establish an effective team, you should start at the top and work your way down:

  1. First, make sure everyone understands and agrees on what goal the team is trying to achieve. You already started working on this in your first team meeting, when you discussed the project charter.

  2. Next, make sure that everyone on the team has a role to play in achieving the goal. You made progress in the first team meeting when team members discussed how they could contribute to the project.

  3. Last, establish the procedures that will help the team do its work. Some of these may have come up in your first meeting, but you need to formalize them now.

Refer to the guidelines in Tools 4-1 to 4-4 (pages 23-26) for more detail.

Goals, Roles, and Procedures Pyramid

Click To expand

Guidelines: Establishing Project Team Goals

Tool 4-1.
Start example
Click To expand
End example

Guidelines: Establishing Project Team Roles

Tool 4-2.
Start example
Click To expand
End example

Guidelines: Establishing Project Team Procedures

Tool 4-3.
Start example
Click To expand
End example

Guidelines: Establishing Project Team Interpersonal Relationships

Tool 4-4.
Start example
Click To expand
End example


Reality Check

At the end of the last chapter we described a project team charged with cost reductions that might result in the elimination of some jobs and creation of new jobs. The team started by imagining what the company would be like if the team were successful. The members were also asked to imagine what their own work lives would be like. It wasn’t surprising that members expressed some serious conflict between the team goals and their personal goals.

They spent several hours talking about how to resolve the conflict, exploring what they might do if their current jobs were eliminated and they had to take on new responsibilities. A number of team members had spent many years in their current jobs and considered themselves experts, so it was difficult for them to imagine starting over in new positions. Eventually, all of the team members felt comfortable with the possibility and saw the team’s success as their best hope of ensuring a future. A few members even got excited about the prospect of taking on new responsibilities. This is an excellent example of the team following the Guidelines: Establishing Project Team Goals.

The disclosure of what each member hoped to achieve as a result of the project led to some interesting discussions of the roles each would play. The team leader, whose position was not likely to change, decided to take a lower-key role and let some of the members who hoped to take on new roles be more visible with senior management.

Another member, toying with the idea of forming a training department, took on the task of designing and delivering training. The team did a good job of following the Guidelines: Establishing Project Team Roles.

Because the team members had disclosed so much to each other, their procedures were somewhat different from previous teams. They met off-site and agreed to a strict privacy code regarding personal information shared in the meeting. One member took minutes on a laptop during the meeting, and the team reviewed the minutes before they were shared outside the team. Finally, they agreed to use consensus to reach any decisions that might result in the elimination of jobs. The task was still difficult, but attending to the Guidelines: Establishing Project Team Procedures allowed the team to be successful.


Part II: Team Skills Needed to Successfully Complete a Six Sigma Project

Chapter List

Chapter 5: How to Have an Effective Project Team Meeting
Chapter 6: How to Make Decisions on the Project Team
Chapter 7: Three Ways to Handle Project Team Conflict, and When Each Works Best
Chapter 8: How to Deal with Difficult Project Team Members
Chapter 9: How to Figure Out What’s Wrong When the Team Isn’t Working Well or Loses Momentum


Chapter 5: How to Have an Effective Project Team Meeting

Overview

Following good meeting management procedures can have a highly positive effect on your project:

  • People will be more willing to attend meetings that run smoothly.

  • The team will feel a sense of accomplishment that increases commitment and willingness to do project work.


What to Do:

  • Take time to plan the meeting (see Tools 5-1, 5-2, 5-3).

Checklist: Planning the Project Team Meeting

Tool 5-1.
Start example
Click To expand
End example

Sample Agenda Worksheet: Project Meeting

Tool 5-2.
Start example
Click To expand
End example

Agenda Guidelines

Tool 5-3.
Start example
Click To expand
End example

  • Follow guidelines for running an effective meeting (see Tool 5-4).

Checklist: Running the Project Team Meeting

Tool 5-4.
Start example
Click To expand
Click To expand
End example

  • Don’t forget to follow up after the meeting (see Tool 5-5).

Checklist: Following up After the Project Team Meeting

Tool 5-5.
Start example
Click To expand
End example


Reality Check

Whenever we teach meeting management in the Rath & Strong “Team and Influence Skills Workshop,” we feel we should apologize for telling people what they already know. Who hasn’t heard that you should have an agenda? Keep a task list? Record decisions?

Then we break the class up into teams and ask them to work on a Six Sigma-related task that has relevance in their organization (for example, how to attract and retain Black Belts). Even though the teams know that they are being videotaped (for instructional purposes), and even though we have just finished discussing the need for meeting management, the teams go into their next meeting without an agenda, and no one writes anything down.

They spend the first half of the next meeting trying to remember what they agreed to at the last meeting. Usually, at least in workshops, people are willing to try using these techniques once they see how inefficient their meetings are. To our surprise, participants routinely rate this section as highly valuable. People often ask for extra copies of the Checklist: Running the Project Team Meeting to take to use in their Six Sigma project team meetings and their parent/ teacher organizations, condo boards, and neighborhood committees. They complain about leaving their team meetings unsure whether decisions have been made because the group is allowed to move on in the agenda (if there even is an agenda) without specifically dispensing with the current agenda item.

The simple Checklists for Planning, Running, and Following up After the Project Team Meeting described here save endless hours, but teams often resist using them. We’ve seen the best results when the team leader (or some other member of the team) makes a running joke out of sticking to the structure until it becomes second nature to the entire group.


Chapter 6: How to Make Decisions on the Project Team

Overview

Using good decision-making procedures can have a highly positive effect on your project:

  • You’ll be more efficient.

  • Team members will be more committed to the course of action, and thus more willing to do the project work.


What to Do:

  1. Select and apply the most time-efficient decision-making approach that will also meet the needs for technical quality and acceptance (see Tool 6-1).

  2. When using the group approach, choose the decision-making tools that make the most sense for the situation (see Tool 6-2).

  3. Resist the temptation to overuse consensus (see Tool 6-3).

Checklist: Selecting a Decision-Making Approach

Tool 6-1.
Start example
Click To expand
End example

Checklist: Selecting Group Decision-Making Tools

Tool 6-2.
Start example
Click To expand
End example

Notes: Making Project Team Decisions Through Consensus

Tool 6-3.
Start example
Click To expand
End example


Reality Check

Adam, a project team leader we’ve known for years, is so concerned with being clear about the decision style his Six Sigma team will be using for different issues that he makes a chart. This allows the team to see which decisions he intends to make himself, which will be delegated, which will be consultative and who will be consulted, and which need to be made by the group. He uses the Checklist: Selecting a Decision-Making Approach with the group and records each team member’s preferences for the approach to a particular decision item.

Adam started this practice after a number of difficult project meetings in which nothing seemed to be getting done. Finally, his team decided to enlighten him on why things were getting stalled, and told him that he wasn’t listening to them. Adam was flabbergasted. He had always prided himself on listening carefully to the evidence presented before making a decision.

The problem was, Adam was making consultative decisions (listening to each argument, then making the decision himself) while his team thought they were making consensus decisions. (Please see Notes: Making Project Team Decisions Through Consensus.) As a result, the team was confused about what had been decided vs. what was still under discussion, and they began to get annoyed about what appeared to be Adam’s high-handed attitude.

After giving Adam feedback on his decision-making approach, the team went through the checklists for some of their pending and recent decisions. As it turned out, a consultative style was perfectly appropriate for most of the decisions Adam was making, and the team was happy to operate that way once the decision-making strategy was clear. Adam’s approach allowed the team to spend less time on less critical decisions, and reinforced the importance of allowing lots of time for those decisions for which a true consensus was needed.


Chapter 7: Three Ways to Handle Project Team Conflict, and When Each Works Best

Overview

Following good conflict-management procedures can have a highly positive effect on your project:

  • You’ll be able to reduce the disruptive effects of interpersonal conflict, making members more willing to participate on the team.

  • At the same time, you’ll allow the task-related conflict that comes from productive differences of opinion—differences that can help you come up with better solutions.


What to Do:

  1. Refer to Tool 7-1 and select the most appropriate approach for the conflict situation.

Checklist: Conflict Management Approaches

Tool 7-1.
Start example
Click To expand
Click To expand
End example

  2. If you are dealing with an interpersonal conflict (“You don’t seem to care what will happen to my department” ... “You always take her side” ... “Can’t you ever shut up?”), rather than a task-related conflict (i.e., members disagree on elements of the project), you may have a problem with goals, roles, or procedures. Refer to Chapter 9 for additional guidance.

  3. Resist the urge to settle for compromising when a consensus is possible and appropriate (see “Notes” on page 50).


Notes on Handling Team Conflict Through Compromising vs. Consensus-Seeking

Key Principle:

Seeing consensus is characterized by presenting one’s own concerns, while also listening to and respecting the other person’s concerns. In seeking a consensus, you are looking to solve your conflict in a way that will satisfy both parties’ concerns. The more checks you have in the “Hold out” section of the Checklist: Conflict Management Approaches, the more likely that the issue makes it worth struggling to satisfy the concerns of both parties.

This is in contrast to compromising, in which you give up something to get something. While the result of compromising may feel fair to the parties in conflict, usually one or both parties had to give up something that they thought was important. Compromise may be the most expedient way to settle the conflict if one or more parties can check off items in the “Don’t deal with it” or the “Give in” section of the Checklist: Conflict Management Approaches.

For Further Details:

Refer to Chapter 6 for tips on how to reach consensus when it is appropriate.


Reality Check

Six Sigma project teams often struggle with the difference between a compromise and a consensus style in dealing with conflict on the team. Compromise can usually resolve conflict fairly quickly, but when the issue is very important to the project, holding out for a consensus is worth the extra time and effort. Please see Notes on Handling Team Conflict Through Compromising vs. Consensus-Seeking above.

Example of a Conflict for Which Consensus Is Appropriate

A Six Sigma team created two processes for improving customer wait time at a bank. Each process had several proponents on the team and the debate became quite heated. The team decided to try each process in different branches and compare the results (a compromise).

Ultimately, neither process was quite right, and the team ended up taking the best elements from each (a consensus). Had the team members continued to work toward a common solution, rather than simply advocating for their own favorite, the better solution might have been reached without the time and expense of a contest.

Example of a Conflict for Which Compromise Is Appropriate

A Six Sigma team made up of representatives from two plants designed new touch-pad technology for collecting control chart data on production lines. The team had budget to buy touch screens for four lines. Naturally, the

members from each plant wanted these first screens in their own plant, and a loud argument erupted over who deserved them more. They decided the fair thing to do was to put two of the new screens in each plant.


Chapter 8: How to Deal with Difficult Project Team Members

Even on teams that are performing well, one or more members may become disruptive to the team’s progress ... or just make being on the team an unpleasant experience.

What to Do:

  1. Refer to Chapter 9 to see if part of the problem you’re having on the team is related to goals, roles, or procedures.

  2. Look at the checklist in Tool 8-1 and see if you can identify the difficult team member’s behavior.

Checklist: Dealing with Difficult Team Members—How to Recognize, What to Do

Tool 8-1.
Start example
Click To expand
Click To expand
Click To expand
Click To expand
End example

  3. Recognize the positive side of the behavior and build on that.

  4. Try the suggested approaches for dealing with the negative aspects of the team member’s behavior.

  5. When you need to do something about the behavior during the team meeting, refer to Tool 8-2 for how best to proceed.

Model for Dealing with Disruptive Behavior During the Team Meeting

Tool 8-2.
Start example
Click To expand
End example

Dealing with Disruptive Behavior During the Team Meeting

Start with the techniques at the top of the list—these are less confrontational. Work your way down the list as needed.


Reality Check

We’re reminded of a team member named Debby who was part of a very vocal and opinionated Six Sigma team. Whenever the discussion began to get heated, which was often, Debby would attempt to smooth over the conflict. Debby started out being helpful, because she could usually summarize the points on each side of the argument, but her insistence on maintaining peace at any price meant that contentious issues didn’t get discussed.

During one such episode, the team leader intervened, reminding the members that they had agreed to follow a consensus decision-making strategy on this particular topic, and that meant everyone’s role was to hold out until they reached a solution they could all support. The group seemed clear on their goals, roles, and procedures, but as soon as voices began to be raised, Debby jumped in to smooth ruffled feathers and shut down the discussion.

The team leader used the Checklist: Dealing with Difficult Team Members—How to Recognize, What to Do. The Mediator seemed to apply to Debby, so the team leader made a concerted effort to get Debby to express her own opinion, rather than worrying about the tension level in the room. Debby tried, but in subsequent meetings, her efforts to shut down any sign of conflict became more and more counterproductive.

The team leader decided to use the Model for Dealing with Disruptive Behavior During the Team Meeting to deal with the problem. He began by trying to catch Debby’s eye, and progressed to asking her to let others finish their thoughts. Finally, he decided to talk to Debby during the next break. Debby admitted that conflict and raised voices made her terribly uncomfortable, and she just couldn’t seem to stop trying to create harmony. The team leader asked Debby’s permission to involve the group. They agreed that whenever anyone in the group felt the discussion was getting too heated, they could say, “Switch,” and the combatants would stop and argue the opposite side. This usually got the group refocused on the issues, rather than feelings, and allowed even Debby to participate in more spirited—and productive—discussions.


Chapter 9: How to Figure Out What's Wrong When the Team Isn't Working Well or Loses Momentum

Overview

It happens to most teams: at some point, the team doesn’t seem to be working as well as it should. You may have a nagging suspicion that things could be more efficient ... or it may be very obvious that the work just isn’t getting done. Sometimes the first thing you notice is that people aren’t coming to the team meetings anymore ... or that they come, but don’t seem to have any energy for the project. Perhaps the initial excitement has worn off, other priorities have been established, or frustration at the magnitude of the task has set in.

How to prevent this from happening:

  1. Follow this guide’s suggestions for holding the first meeting; establishing team goals, roles, and procedures; having effective meetings; making decisions; etc.

  2. Take time on a regular basis to assess how the team is doing, identify any issues, and make necessary adjustments. (Think of this as the Control phase of your team, where you monitor performance to ensure it doesn’t deteriorate.)

Not all problems can be prevented, however, so what should you do when you do encounter difficulties? You need to act quickly to figure out what’s going on, and then do what’s required to get the team back on track.


What to Do:

  1. Use the Goals, Roles, and Procedures Pyramid and associated explanation (Tool 9-1) to identify the possible root cause of the team’s problems.

Using the Goals, Roles, and Procedures Pyramid to Identify the Cause of Project Team Problems

Tool 9-1.
Start example
Click To expand
Click To expand
End example

  2. If you need to pinpoint the problem more specifically, have the entire project team take the Project Team Effectiveness Survey. Look at individual scores and collective team scores to identify the areas you need to address. (See Tools 9-2 and 9-3.)

Project Team Effectiveness Survey

Tool 9-2.
Start example
Click To expand
Click To expand
Click To expand
Click To expand
Click To expand
End example

Survey Scoring Grid

Tool 9-3.
Start example
Click To expand
End example

  3. Follow the guidelines in Tool 9-4 for dealing with the underlying causes of the problems.

Guidelines: Dealing with Project Team Problems

Tool 9-4.
Start example
Click To expand
End example

  4. Look at the checklist in Tool 9-5 to ensure that you’re not worrying needlessly.

Checklist: Avoiding Needless Worry About Project Team Problems

Tool 9-5.
Start example
Click To expand
End example

  5. Where possible, do this analysis and discussion as a team.

Goals, Roles, and Procedures Pyramid

Click To expand
Note

You should look up one level in the pyramid to identify the root cause of a problem you’re seeing at another level. For example, if you’re having problems getting the team to follow procedures, the cause might be associated with unclear or conflicting roles.

Scoring the Survey:

  1. For each element of team effectiveness (such as Goals), add together all team members’ scores and divide by the number of team members to get an average score (1-7). Enter this information into the scoring grid in Tool 9-3.

  2. Look at the variation in scores: do some team members score an item at the high end of the scale, while others score it at the low?

  3. Select items for attention as directed page 72.

  4. Refer to the guidelines in Tool 9-4 (page 73) for what to do.

Where to Focus Your Attention

Look immediately at:

  • Areas with average score = 1-3

  • Areas with wide variation in team member scores

Consider next:

  • Areas with average score = 4-5

Address last or not at all:

  • Areas with average score = 6 or above

Note that it’s less important to look at the total survey score than it is to look at scores for the individual areas ... both the absolute scores and the variation among team member perceptions. It is at this level that you can get at the real underlying issues—and take action that will really help.


Reality Check

A Six Sigma team charged with improving first-pass yield on pharmaceutical fill lines had been working for two months. They made great progress in the first couple of weeks, but by the beginning of the third month, things began to fall apart. People started coming late for meetings, not doing their assignments, and sometimes not showing up at all. No one seemed to get along any more. The team leader, John, referred to the guidelines in Using the Goals, Roles, and Procedures Pyramid to Identify the Cause of Project Team Problems.

He looked at the “interpersonal relationships” problem area, because team members were not getting along. Following the guidelines, he looked up a level in the pyramid to see if the root cause of the problem might be the procedures they were following. John had to admit that they had gotten sloppy about getting the agenda out, and the task list hadn’t been updated for three weeks. He resolved to do better, but got sidetracked by yet another urgent request to redo his monthly report for the upcoming board meeting. His boss told him, “Your team will just have to wait. If we don’t prove to the board we can hit the numbers this quarter, they’re going to close the plant.” Nobody seemed to mind that John cancelled the next meeting because everybody was getting the same message from their own boss.

Eventually, John came up for air and realized that his team was weeks behind schedule. Another look at the pyramid convinced him that root cause of their difficulty was still higher than procedures. All of the team members were having difficulty with conflict between their roles on the team and their regular jobs, and the goals of the team seemed to be in conflict with the shifting goals of the company.

John decided to use the Project Team Effectiveness Survey with the team to confirm that this was what was getting in the way of their being effective. The results of the survey confirmed his suspicion. John was then able to sit with the team and the sponsor and work on clarifying and refocusing the goals of the team so that it would be clear how they could contribute to the needs of the plant. With a renewed sense of purpose, the team got back to work.


Part III: Getting Buy-in for Your Project

Chapter List

Chapter 10: The “Politics“ of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team
Chapter 11: Five Ways to Influence People to Cooperate with Your Six Sigma Project
Chapter 12: How to Communicate with People Whose Help You Need
Chapter 13: How to Be a Better Listener So That People Will Want to Help You
Chapter 14: How to Avoid the Pitfalls of E-Mail on Six Sigma Projects
Chapter 15: How to Make an Effective Presentation About Your Six Sigma Project
Chapter 16: What to Do When You’re Not Getting Cooperation
Chapter 17: Sample Plans for Getting Buy In


Chapter 10: The " Politics " of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team

Team LiB

Chapter 10: The “Politics“ of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team

Overview

What would happen if, in the measure phase of DMAIC, you didn’t identify the data you need, create a data-collection plan, and then implement that plan? What if you just asked random people to give you whatever data they thought might be useful? That wouldn’t be an effective approach, would it?

It’s no different with getting support and cooperation for your project. You can’t just barrel ahead and hope for the best. The key to getting support and cooperation from people outside the team is to think in advance about what you need, and from whom ... and then plan on how to get it.

We call this approach stakeholder management, and it consists of three steps:

  1. Identify your project “stakeholders.”

  2. Analyze them.

  3. Create a plan to get their support.


Step 1. Identify Your Project Stakeholders

Definition

Stakeholders are any individuals or groups who have a “stake” (or vested interest) in your project.

  • They are affected by—or can affect the outcome of—your Six Sigma project.

  • Either of you may lose or gain something as a result of what the other does.

  • You may supply them with something they need, or vice versa.

  • You can make each other’s lives easier or more difficult.

What to Do:

  1. Use a worksheet like that shown in Tool 10-1 to list your stakeholders. (We’ll discuss the “map” later in this chapter.)

Worksheet: Project Stakeholder Identification

Tool 10-1.
Start example
Click To expand
End example

  2. Use the Checklist: Potential Project Stakeholders (Tool 10-2) to identify “obvious” and “not-so-obvious” stakeholders. List them on your worksheet.

Checklist: Potential Project Stakeholders

Tool 10-2.
Start example
Click To expand
End example

  3. Think of all the major activities of your project.

    • Identify people (individuals or groups) who are affected by each activity and add them to your worksheet list.

    • Identify people who could affect the success of each activity, and add them to your list.

  4. For each project stakeholder, consider whether that person’s boss or direct reports are also stakeholders; add to the list as appropriate.

Note on Tool 10-2: We recommend that project teams work together on creating a project stakeholder plan to get support from those outside the team. See Chapter 1 for suggestions on how the team leader can use stakeholder planning to help the project team members feel committed to the team.


Step 2: Analyze Your Project Stakeholders

The more you know about your project stakeholders, the easier it is to figure out a way to get their support and cooperation. Follow this proven process to gain a clear understanding of your key stakeholders.

What to Do:

  1. Narrow down your list of project stakeholders to the key players you want to analyze further. Consider including:

    • high-impact stakeholders who are potential (or known) resisters ... and who might derail your project

    • high-impact stakeholders whose attitude you don’t know ... and who might blindside you

    • stakeholders who are potential (or known) supporters (particularly those who are high-impact, but others also) ... these people can help you bring other stakeholders along

  2. Use the worksheet shown in Tool 10-3 (page 86) to analyze each of your key stakeholders. An explanation of the worksheet items follows. You may want to refer to other chapters in this pocket guide for help on some of the items.

Worksheet: Project Stakeholder Analysis

Tool 10-3.
Start example
Click To expand
End example

Explanation of Worksheet Items

What I need from this stakeholder: Resources, information, permission, time, refraining from sabotage, active support, etc.

Stakeholders’ interests: Tangible and intangible interests, and how they may differ from the person’s stated position. (See Chapter 11 for more on interests and positions.)

How stakeholder may benefit: What the person might perceive as potential gain from project outcome/activities, or interests that could be satisfied.

How stakeholder may be hurt/inconvenienced: What the person might perceive as a potential loss or unpleasant result from the project outcome or activities ... or interests that could be imperiled.

Probable response from stakeholder: Whether you think the person will be supportive, resistant, or neutral, and what you think he/she might actually do. Base your guess on what you know about reasons for resistance (see Chapter 16) and this particular person’s situation.

Size of gap for this stakeholder: The gap between this person’s probable response and what you need. This helps you prioritize stakeholders so that you spend your time as effectively as possible.

Key influence “levers”: Key items that will help you influence this person, such as any of his/her interests that your project helps fulfill, shared values that will help smooth the way, etc.

Stakeholder’s communications needs: The person’s preferred way of communicating (see Chapter 12 for more on this).

Details/history of conflict with stakeholder: Any past (or anticipated) conflicts with this person, his/her conflict style, disruptive behavior he/she has exhibited, any areas where your project may conflict with this person’s goal or organizational role.

Other relevant info about this stakeholder: Anything else you know about the person that might be helpful, including who his/her allies are, and whether you have a relationship with any of them. (Tip: Check to see if any of your supporters are allies of those who are resisting; they might be able to help.)

A Useful Add-on to Your Project Stakeholder Analysis

Now that you know a little more about your key stakeholders, it can be useful to return to your initial list and create a visual map of the key people. A map can help you see at a glance the status of your stakeholders: whether they are in support of your project or not, and how much of an impact they might have on the project (or it on them). You can update the map as you gain more information and as you are successful in turning people from resisters into supporters.


Project Stakeholder Identification with Map

What to Do:

  • Using a form like that shown in Tool 10-4, put words identifying your project in the middle of the map.

Worksheet: Project Stakeholder Identification with Map

Tool 10-4.
Start example
Click To expand
End example

  • Consider the degree of impact the activities of your project will have on the stakeholders and the degree of impact the stakeholders can have on the success of your project. Indicate the level of stakeholder impact (in either direction) by placing those with high impact closer to the center of the map and those with low impact farther away.

  • Draw circles around stakeholders who seem likely to support your project, squares around those likely to resist, and nothing around those whose attitude you know nothing about.

Tool 10-4 is an example of a project stakeholder list with map.

How to Interpret the Example

Ray, Brown, Jones, and the contractors are probable supporters, while Smith, Boyd, and the Billing Department clerks are probable resisters. The attitudes of Lee and Doe are unknown.

Jones, Boyd, Lee, Doe, and the clerks have the greatest impact on the project or the project has the greatest impact on them. Ray, Brown, Smith, and the contractors have a lower impact or are not as affected.

If these were your project stakeholders, you’d probably want to start by:

  • planning to gain the support of the clerks and Boyd

  • gathering more information on how Lee and Doe feel about the project

  • enlisting help from supporters, starting with Jones


Step 3: Create a Project Stakeholder Plan

Having a project stakeholder plan ensures that you approach the influence part of your project with as much organization and attention as you give to the DMAIC steps. Time invested early in stakeholder planning can save you countless hours of dealing with resistance, redoing work, missing targets, etc.

What to Do:

  1. Use the worksheet in Tool 10-5 (page 91) to create a plan for the key stakeholders you analyzed in Step 2. An explanation of the worksheet items follows. You may want to refer to other chapters in this pocket guide for help on some of the items.

Worksheet: Project Stakeholder Planning

Tool 10-5.
Start example
Click To expand
End example

  2. Implement the plan, monitor progress, and update the information regularly.

Explanation of Worksheet Items

Influence objective: Describe in detail exactly what you want the person to do, and a description of what will happen if you are successful in influencing him/her.

How to increase benefits to stakeholder: Identify anything you—or someone else with whom you have influence—can do to ensure that this person benefits from the project outcome or activities. Think of how you might change the person’s perception if you perceive a benefit but he/she does not. If the person already perceives a benefit, consider how you can reinforce that perception.

How to reduce cost or inconvenience to stakeholder: Identify anything you—or someone else with whom you have influence—can do to reduce the negative effects of the project on this person. Think of how you can reframe the person’s perception if he/she perceives a cost/inconvenience but you do not believe it will happen.

How to deal with conflict with stakeholder: Write down your thoughts about a good approach to resolving the conflict, given what you know about your own and this person’s conflict styles (see Chapter 7 for more on conflict). If the conflict is disruptive team behavior, think of steps you might take to deal with it (see Chapter 8 for more), and consider whether you could reduce the conflict by addressing team roles or goals (see Chapters 4 and 9).

Plan for direct influence: Identify your primary and back-up influence strategies (see Chapter 11 for more information). Think of how you should communicate with this person in the course of your influence attempts (see Chapter 12).

Plan for indirect influence: If you are not the best person to do this, think about who you could ask to contact or attempt to influence this person in your place. Perhaps one of the supporters you identified earlier? Consider whether you have access to any materials, information, meetings, industry peers, etc. that might make the person more sympathetic to your project. If your stakeholder is a department or group, try to identify a friend or contact in that group who might serve as an informal link.

Implementation considerations: Identify the steps you’ll take, when you’ll take them, and whether anything else has to happen first. Determine what method of communications (face-to-face, phone, e-mail) you could and should use (see Chapters 12 through 15 for more on communicating).


Key Principles

The more broadly you think about what constitutes your universe of stakeholders, the better your plan will be. Thinking broadly allows you to minimize the chance of being blindsided by resistance from a “missed” stakeholder.

Perception is what counts; stakeholders may perceive that they will be negatively affected by a project even when that is not the case. And when considering what may be important to people, put yourself in their position and do not trivialize their concerns. (It’s often said that we think people are “overreacting” whenever they react more than we would!)

You do not always have to influence people directly. The decision between a direct or indirect approach will depend on such elements as your position in the organization, the timing, your history with the person you’re trying to influence, and other alternatives you may have.

If it seems too daunting to do this for all your key stakeholders, start with one person and see what happens.


Reality Check

It’s not always easy to identify all of the stakeholders for a Six Sigma project. We once worked with a project team that identified the consolidation of all monthly reporting into a single report as an improvement. The team quickly identified the more obvious stakeholders: MIS, the administrative assistants who provided the raw data, the recipients of the report. However, as the team worked through the Checklist: Potential Project Stakeholders, they began to see some real issues. The administrative assistants may have delivered the raw data, but they didn’t originate it. Likewise, the recipients of the various reports weren’t necessarily the people who used them. It took considerable effort to find out who actually generated and used the data.

The team also found that each of the departments had its own format for reports. The team members initially assumed that the reason for this was just pride of authorship. But in the course of using the Worksheet: Project Stakeholder Analysis, they came to recognize that the department heads with budget authority had a very clear interest in getting credit for revenue and/or not being charged with expenses. It was this interest that drove the departments to customize reports into forms that would help them do this in a quick and easy way. Had they not recognized this concern, the team would have been focused on ways of getting the department heads to give up their pride of authorship. Instead, they identified on their Worksheet: Project Stakeholder Planning the need to ensure that these stakeholders were still able to monitor revenue and expenses.

Early on, the team had identified the CFO, the team sponsor, as a strong supporter of the project. However, as the project progressed, it became apparent that there were serious problems with how the numbers were rolled up from the different reports and that revenue was significantly overstated. The CFO might be embarrassed or worse by the team’s discovery, so they needed to reevaluate the strength of support they could expect from the CFO. Had the team simply forged ahead, it was highly likely that the CFO would not have continued to support them ... and they would have been blindsided by what appeared to be a change of heart. But by revisiting the various worksheets, the team was able to identify a potential change in this stakeholder’s level of support and to adjust their approach accordingly.


Chapter 11: Five Ways to Influence People to Cooperate with Your Six Sigma Project

As you work to complete your Six Sigma project, you will have to influence many people in order to get cooperation for your project, and the same approach doesn’t work with everyone. So you’ll need to be familiar with a variety of influence approaches (or strategies) and know how to choose among them.

Definition:

Influence refers to the use of personal energy to create an impact upon, redirect, or change the outcome of a particular situation.

Key Principle:

Influence strategies fall on a continuum (see below), with one end being those that push people into action and the other being those that pull them (i.e., create a situation in which people want to do something).

What makes one influence strategy more appropriate than another is a combination of:

  • the situation

  • you and your capacity to influence

  • the person you’re trying to influence

    Click To expand

What to Do:

  1. Read through the Checklist: Influence Strategies (Tool 11-1) items, considering whether they apply to your situation. Put a check next to those that do.

Checklist: Influence Strategies

Tool 11-1.
Start example
Click To expand
Click To expand
Click To expand
End example

  2. Analyze your responses:

    • Look at the strategies with the most checks.

    • Consider whether all checks are equal, or whether some items have more weight in this situation; if some deserve more weight, assign additional checks to them.

    • Rank-order the strategies based on checks (adjusted for weight) and your own judgment (does the strategy seem to make sense?).

  3. Use this ranking as a guideline for helping you select the appropriate influence strategy for this person.

Checklist: Is Your Data Persuasive?

Tool 11-2.
Start example
Click To expand
End example

Six Sigma Professionals’ Biggest Influencing Mistake

When it’s time to influence people, Six Sigma professionals tend to reach for the same strategy every time: persuasion. In many cases, this is a good approach and it works quite well. But Six Sigma professionals often do this even when the other person already has the data, or has already taken it into consideration, or is not open to hearing it. In these situations, persuasion simply doesn’t work.

Why Does This Happen?

People tend to use influence approaches that seem logical to them and have worked well in the past. As someone with experience in Six Sigma and its focus on data-based decisions, you can easily draw the conclusion that using data is the best way to influence someone. When it doesn’t work, you may think it’s because you don’t have enough data, so you look for more and try again ... and again....

What Can You Do to Avoid This Tendency?

Recognize that people consider many factors as they make decisions, and you often have to move beyond the data—even though this may seem like a betrayal of Six Sigma principles! Become familiar with the five influence strategies and when they are appropriate. Use the checklist to pick an approach. Try out the other strategies and see what happens. Don’t let your preferred style get in the way of doing what will work best with this person in this situation.


More on Negotiating

You can negotiate effectively only if you can identify your own interests and those of the person whose cooperation you need. Sounds simple, but a common mistake is to confuse interests with positions.

Interests are things a person cares about—any concerns about the issue, any underlying wants. These can be tangible (such as money or resources) or intangible (such as power or reputation). See Tool 11-3 for hints on how to identify your project stakeholders’ interests.

Checklist: Identifying Your Project Stakeholders’ Interests

Tool 11-3.
Start example
Click To expand
End example

A position, on the other hand, is where a person stands on an issue. Examples:

  • You want a line worker’s help in collecting error rate data. The plant manager’s position may be that no resources are available. The manager’s interest might be that he wants to maintain control or be seen as competent (but thinks this won’t happen if he gives you access to the data).

  • You want a team member to attend more project meetings. Her position might be that she doesn’t have the time. Her interest might be that she wants to get credit or be associated only with a success (and she’s not sure if this project will succeed or whether she’ll get any credit if it does).

What to Do When You're Negotiating

  1. Identify the issue: what you’re negotiating about.

  2. Identify your own and the other person’s interests (see Tool 11-3 for guidance).

  3. Focus on interests rather than positions. Think about what you have to offer the other person (i.e., how you might satisfy his/her interests), and how to make your offer attractive to this person. Think about what he or she has that would satisfy your interests; don’t be afraid to ask for what you want or suggest trades.

  4. If the other person’s style bothers you, don’t let it get in the way of negotiating. The goal is to get both parties’ interests satisfied, not to become best friends.

  5. Generate alternatives, discuss them, evaluate, select, and implement.

  6. Repeat as necessary!


Reality Check

In the last chapter we described a team that identified the need to consolidate all monthly reporting into a single report. During the course of the project, the team discovered that different departments were taking credit for the same revenue, resulting in the CFO significantly overstating company earnings. While the CFO’s position relative to the team didn’t change from the beginning to the end of the project—he still openly supported it—his interests naturally shifted.

The team used the Checklist: Identifying Your Project Stakeholders’ Interests to help them identify what the CFO’s underlying interests might be. His original interests were to reduce both the time and effort required to analyze the monthly reports, and the potential for error that resulted from having different reports for each department. As the team progressed, and their analysis uncovered the unexpected issue of overstated earnings, the CFO’s interests shifted to not being seen as responsible for the overstatement and, finally, to keeping his job. After reviewing what they knew about the CFO and having a confidential discussion with the Master Black Belt (a long-time colleague to the CFO), the team concluded that the CFO’s need to be seen as competent and valuable to the organization was a stronger interest than his need to save face.

The team then used the Checklist: Influence Strategies to identify an appropriate strategy for getting the CFO’s support. They decided on a strategy of asking for much more direct involvement of the CFO in uncovering the extent of the problem and communicating the issues and solutions to the organization. The CFO responded to the team’s request, and the project was able to continue.


Chapter 12: How to Communicate with People Whose Help You Need

Highlights

If you want to get support and cooperation for your Six Sigma project, you need to know how to communicate about the project and your needs. The key is to talk to the people whose help you need in the way that is most appealing to them, not necessarily what is most comfortable for you. To do this, you need to figure out how they prefer to communicate, then adapt your style to theirs.

What to Do:

  1. Pick people whose help you need, and consider what you know about them, including the way they communicate, how they act, the positions they have in the organization.

  2. Use the checklist in Tool 12-1 to help you figure out how you should communicate with each person selected, based on what you know about each of them.

Checklist: Matching Your Communication to the Person Whose Help You Need

Tool 12-1.
Start example
Click To expand
Click To expand
Click To expand
End example

  3. Use the checklist in Tool 12-2 to ensure that you don’t make the fundamental mistake of using the wrong communication medium.

Checklist: Selecting the Right Communication Medium

Tool 12-2.
Start example
Click To expand
End example

Figuring out how someone likes to communicate and then adjusting to that person takes you out of your comfort zone and may feel odd at first. But you’ll find that when you learn to do it well, this approach can drastically increase your ability to get cooperation and support.

As you review Tool 12-1 (pages 109-111), note that the audience groups are not mutually exclusive. A person might interrupt people and tell stories and ask a lot of questions. But these behaviors often cluster together. Just try to get a general sense of the person.


Reality Check

A colleague of ours, Jan, was sitting in the cafeteria one day when her boss’s boss’s boss, Marie, sat down across from her, offered her half a muffin, and said, “I’m so glad to see you. Tell me how your Six Sigma project is going.” Jan’s first impulse was to whip out the data pack the team had just finished and launch into the fascinating details of their chi-square analysis. Jan loves the challenge of turning raw data into useful information, and she easily could have expounded on the team’s analysis for hours.

Fortunately, Jan recalled the Checklist: Matching Your Communication to the Person Whose Help You Need, and recognized that going into details of the team’s data analysis might not be the best approach with Marie. Although they didn’t know each other well, Marie was smiling and making full eye contact. Jan quickly reviewed the times she’d seen Marie in action, and recalled that Marie was a great storyteller and really seemed to care about people. So Jan started by relating a funny story about missing the first team meeting because there was a pickle spill on the freeway. She then mentioned how excited the team was about the breakthrough they made in the last meeting, and what a developmental experience the project has been for all members. They ended up talking about the project for nearly an hour, and Marie agreed to help Jan get some much-needed data from her boss’s boss.


Chapter 13: How to Be a Better Listener So That People Will Want to Help You

Overview

Good listening skills are critical to the success of your Six Sigma project. Obvious areas where listening skills come into play are in learning about the process and collecting the right data. Poor listeners won’t get the right information. Less obvious—but just as critical—is the role of listening in gaining support and cooperation from your stakeholders. Specifically:

  • People are more likely to cooperate when they feel you’re listening to them.

  • If you listen well, you’ll be better able to determine whether you are really getting cooperation or just “lip service.”

Becoming a better listener is not brain surgery—it’s primarily a matter of knowing what to do and (more importantly) committing to making the effort. We can’t help you make the commitment, but we can make some suggestions on how to improve. We recommend that you:

  1. Tune in to nonverbal communication cues.*

  2. Concentrate on the speaker.

    Note

    *The suggestions in the section on nonverbal cues apply to interactions that are face to face or via phone. While there are nonverbal cues in e-mail messages, most people are so poor at conveying information this way that interpreting their meaning is often quite difficult. See Chapter 14 for more on communicating effectively through e-mail.


Tune into Nonverbal Cues

Studies show that in conversation, we get 7% of the meaning from words and 93% from nonverbal cues. So if you’re not tuned into nonverbal communication cues and what they may mean, you’re missing most of what’s going on!

Nonverbal cues include:

  • Aspects of speech other than words: volume, tone, speed, pitch, etc.

  • Gestures

  • Facial expressions

  • Eye movements

  • Physical proximity/position

  • Bodily contact

What to Do:

  1. Consciously watch/listen for the speaker’s nonverbal communication.

  2. Be conscious of whether the overall pattern is positive or negative, and whether the speaker’s words and nonverbal communications match (see Tool 13-1).

Checklist: Reading Nonverbal Cues

Tool 13-1.
Start example
Click To expand
End example

  3. If the overall pattern seems negative or the speaker’s nonverbal behaviors are at odds with the words used, consider whether you should act to clarify what the speaker means, test for agreement, or probe for the speaker’s thoughts and feelings on the topic being discussed.

Key Principles:

The overall pattern of nonverbal cues counts more than any individual item, so don’t over-interpret one cue.

Nonverbal cues mean different things in different cultures. The categorization of items in Tool 13-1 applies to speakers from the USA. If you’re communicating with someone from another culture, you should learn all you can about nonverbal cues in that culture before trying to interpret those cues.


Concentrate on the Speaker

In a business environment in which multitasking is a way of life, concentrating all your attention on the person speaking to you may seem an impossible luxury. But if you’re looking not only to gain the information you need, but also to build support and cooperation for your project, that is exactly what you need to do.

What to Do:

Follow the suggestions in Tool 13-2 for what to do before and during the conversation in order to maintain your concentration on the speaker.

Checklist: Concentrating on the Speaker

Tool 13-2
Start example
Click To expand
Click To expand
End example


Reality Check

A good example of how to use the Checklist: Reading Nonverbal Cues came when a Six Sigma team sponsor was giving feedback on the just-in-time Six Sigma training a Black Belt had just delivered to a project team. The sponsor had nothing but glowing things to say about the program. She stressed that the participants had been engaged and that all of them had left the program excited about getting started on the project. She praised the Black Belt’s teaching skills and mentioned how rare it was to find someone good at both the technical and training aspects of Six Sigma.

Despite the positive words, however, the Black Belt noticed that the sponsor wasn’t making eye contact and was leaning away with her arms crossed. She seemed to be speaking faster than normal, too. The Black Belt was puzzled, and finally asked if something might be bothering the sponsor. The sponsor grew quiet and moved a few steps away, then finally admitted that the funding had been cut for the project and she felt she had just wasted the time of the Black Belt and the participants. The two were able to have a more direct conversation after that, and made plans for deploying the recent trainees to other teams. The sponsor’s relief was obvious and the two were smiling and laughing by the end of the conversation.

Had the Black Belt not noticed the “disconnect” between the sponsor’s words and her nonverbal cues, he would have left the meeting on a high ... only to be acutely disappointed when the lack of project funding was announced. And he would have been scrambling to figure out what to do with the recent trainees. Instead, by the time the trainees heard that their original project was off, they had already learned about their new assignments from the Black Belt. Their level of enthusiasm for Six Sigma remained high, and they were still able to make a contribution to the organization—although not on the original project. The Black Belt felt like part of a solution to the problem, rather than a victim of it.


Chapter 14: How to Avoid the Pitfalls of E-Mail on Six Sigma Projects

Every interaction with others in your organization is an opportunity to either increase or decrease support for your project. If you’re like the majority of Six Sigma team members, e-mail is one of the primary ways—if not the primary way—you interact with those whose support you need. So you’ll want to be sure you know the pitfalls of communicating with e-mail ... and how to make sure you don’t fall into them and inadvertently create resistance instead of support.

What to Do:

Use the checklist in Tool 14-1 to help you avoid the typical pitfalls of e-mail on Six Sigma projects. While it may seem cumbersome to run through this list for every e-mail you send, the goal is to make this way of thinking automatic. Try it a few times and soon you won’t even have to look at the list ... and you’ll increase the level of support and cooperation for your project.

Checklist: E-Mail Pitfalls and Avoiding Them

Tool 14-1.
Start example
Click To expand
Click To expand
End example

Reality Check

Here’s an example of an e-mail we saw that wasn’t very effective:

I’m still waiting for your month-end figures. My deadline is Friday.

Jim, the recipient of this e-mail, did not report to Beth, the sender, nor did he know her well. So he certainly wasn’t expecting to get what appeared to be a command from her. And didn’t she recognize that he had his own work to do and his own deadlines? Needless to say, Jim did not immediately leap into action upon receipt of this message. Nor was his impression of Beth enhanced.

Beth, meanwhile, couldn’t figure out why she didn’t get a quick answer from Jim. She knew he got the e-mail, since she’d gotten the receipt. It struck her that perhaps Jim just wasn’t a team player. It never occurred to Beth that perhaps her curt and seemingly demanding e-mail might have played a part in Jim’s response (that is, his lack of response).

Most people think they get too much e-mail, and some argue that readers appreciate concise e-mails. That may be true, but we still think the following would have been more likely to get results for Beth:

Hi Jim,

Thanks for getting back to me so quickly with the numbers for last quarter. I’d like to include last month’s figures, too, when I give my report this Friday. Could you possibly send me a copy of your month-end report by Thursday? I know you’re probably in the middle of a lot of other things, so please let me know if there’s anything I can do to help you on this.

Thanks!

Beth

Better still, Beth might have stopped by Jim’s office and asked for a copy in person. Had Beth considered the Checklist: E-Mail Pitfalls and Avoiding Them before sending her message, she likely could have gotten what she needed when she needed it.


Chapter 15: How to Make an Effective Presentation About Your Six Sigma Project

Overview

As you work through your project, you will have to make a number of presentations about your progress. Your project champion might want to see whether you’re following DMAIC correctly and using the right tools. The process owner may want to know how the process is performing now and what data you have to back that up. The steering committee might want to know what improvements you’re considering and the risks and costs associated with each.

No matter what the audience is looking for, the bottom line is that it’s not enough for you to do a good job on the project itself. You must also be able to convey information about your project in a way that gets you the outcome you’re looking for—whether that be agreement to continue with the project, support for your improvement idea, credit toward certification, etc. How well you present is key to your success.

Key Principles:

The most important three things you can do are:

  1. Follow the effective presentation techniques in the checklist (Tool 15-1).

Checklist: Effective Project Presentation

Tool 15-1.
Start example
Click To expand
Click To expand
End example

  2. Know your audience and adjust the way you speak to their style. (See Chapter 12 for details.)

  3. Don’t make the mistake of using Six Sigma jargon when it’s not appropriate. (See explanation on page 128.)


What Do You Mean, I Shouldn't Use Six Sigma Jargon?

Team LiB

What Do You Mean, I Shouldn’t Use Six Sigma Jargon?

One of the goals in Six Sigma is to get everyone speaking the same language, i.e., the language of Six Sigma. So you should set an example by using it as much as possible, right?

Six Sigma professionals often make a mistake in this area that results in their getting less rather than more support and cooperation for their projects.

While speaking the language of Six Sigma is an admirable corporate goal, the way this is actually implemented is of paramount importance. If you want to get support and cooperation, you have to start by meeting people on their own ground and speaking to them in their own language. Once you have their attention and trust, you can gradually introduce new language—providing you do so in a way that is instructive, not condescending. If you make people feel as if they are stupid or not part of the “elite,” then they will not be inclined to support you or your project. This is particularly the case when you’re communicating with people who have familiarity with other quality initiatives, but not with Six Sigma.

So speak in your stakeholders’ language, and introduce them to “Six Sigma speak” slowly and tactfully. You’ll get much more buy-in this way.


Reality Check

We worked with a Six Sigma team on a project involving large-scale change across a complex organization. The team needed to make a presentation to the CEO, who did not have a detailed view of that organization. The team leader had a 60-slide PowerPoint presentation, but the Checklist: Effective Project Presentation helped her realize that she would have to capture his attention in the first five minutes or he would be lost ... and would likely tune out or (worse) end the meeting.

We knew that the CEO was a visual thinker; whenever he spoke, it was always with a flipchart at hand, and he’d draw diagrams to illustrate his points. So we advised the team leader to keep the wordy slides in her “back pocket.” We helped her design a giant poster, with figures representing the various parts of the organization, the current interrelationships among them, and the probable changes that the project would create in those interrelationships. While the poster included a few words, the information was primarily visual.

At the presentation, the team leader spent a few minutes orienting the CEO to the poster and what it depicted. She then let the CEO direct the discussion. The presentation moved at the CEO’s pace, in the order of his choosing, and at a depth that he dictated. The PowerPoint slides never made it out of the team leader’s back pocket. The CEO did not leave the meeting with in-depth knowledge of what the team had been working on. He did leave with a global view of where the organization had been and was going ... and the team leader left with his full support for the project.


Chapter 16: What to Do When You're Not Getting Cooperation

Overview

The success of your Six Sigma project depends in good part on cooperation from people on your team and across the larger organization. So what do you do when you can’t get cooperation, when people resist?

Let us be very clear: the best way to deal with resistance is to prevent it, which means planning in advance (see Chapter 10). But not all resistance can be prevented, so when you do encounter what you think is resistance, take this general approach:

  1. Learn to recognize whether what’s happening really is resistance (see checklist in Tool 16-1).

Checklist: Recognizing Resistance to Your Six Sigma Project

Tool 16-1.
Start example
Click To expand
Click To expand
End example

  2. Understand possible reasons why people would resist your project (see Tool 16-2).

Checklist: Identifying Reasons People May Resist Your Six Sigma Project

Tool 16-2.
Start example
Click To expand
End example

  3. Learn and apply steps to minimizing the resistance (see Tool 16-3).

Checklist: Do’s and Don’ts for Dealing with Resistance to Your Six Sigma Project

Tool 16-3.
Start example
Click To expand
Click To expand
End example


Why Might People Not Cooperate with Your Project?

People may be uncooperative or resistant for variety of reasons. Some of these reasons might seem understandable to you, while others may strike you as unsupportable or even petty. We recommend that you refrain from making value judgments about the reasons. Instead, you should to try to discern the possible underlying causes for the resistance and deal with it as best you can. Use Tool 16-2 for identifying causes of uncooperative behavior.

Start Sidebar
Example of Resistance and Its Underlying Reason

Resistance Behavior

During root-cause analysis, a process owner disputes the validity of the data, claiming that you collected the wrong information because you don’t know what you’re doing (attacking) or that it was an unusual month so the data is meaningless (avoiding).

A Possible Reason for the Behavior

The root cause is something the process owner now realizes he should have addressed long ago, and he fears that acknowledging it now might make him appear incompetent. Since he cannot admit this, he instead attacks you or looks for ways to avoid the issue.

A Warning

If you really don’t know what you’re doing or the data really is from a nonrepresentative month, then this may be common sense rather than resistance!

End Sidebar

What to Do When Stakeholders Resist Your Project ... and What Not to Do

Tool 16-3 provides guidance on how to effectively deal with resistance behavior ... and what not to do.


Reality Check

Todd was leading a Six Sigma project that seemed to have come to a halt in the Measure phase. Joe, the team member responsible for gathering data from Jane, the department manager, just couldn’t seem to get what he needed from her. He’d tried various approaches, using e-mail reminders, voice mail messages, attempts at face-to-face meetings. Nothing worked. The manager made promises ... weeks passed ... still no data. At this rate, Todd thought, the project could take a year or more!

Then another team member, Sylvia, suggested that they stop bemoaning the lack of data and instead apply Six Sigma principles to the problem. “We say we’ve tried everything,” she said to the team, “but don’t we need to know the root cause of this problem before we identify the solution?” Somewhat embarrassed at not having thought of this himself, Todd suggested that the team devote a meeting to analyzing the problem in detail.

The team’s first question: were they seeing resistance or just good intentions gone awry? Using the Checklist: Recognizing Resistance to Your Six Sigma Project, the team saw two kinds of behavior that fit their situation. When Joe first spoke to Jane about what data the team would need, he barely got the words out before she said, “Hey, no problem! Anything you need—just ask and it’s yours. I know you Belts will be able to fix all our problems.” Oddly, she hadn’t asked Joe a single question—not even what he planned to do with the data. But when Joe followed up with a detailed list of what he wanted, somehow Jane could just never get around to it. Nor was she available for calls or meetings. This sounded very much like compliance followed by avoidance. The team concluded that they were indeed up against resistance.

Next, the team consulted the Checklist: Identifying Reasons People May Resist Your Six Sigma Project to help them figure out why Jane might be resisting. The item about fear of being viewed as incompetent jumped out at them, as did the one on concerns about not being the “expert.” They recalled that Jane had been part of the company’s TQM effort five years earlier. In fact, she’d been trained in many of the same tools they were using in Six Sigma, yet she hadn’t been trained as a Black Belt or Green Belt. When the TQM initiative fell apart, Jane ended up in a line job. Todd recalled hearing that she wanted to get out of that job and had been hurt and annoyed about being passed over for a Belt position, as she much preferred that kind of role. Joe recalled Jane’s remark about “you Belts” fixing all her department’s problems. In retrospect, this sounded less like a show of faith and more like resentment—with a bit of fear underneath. After all, shouldn’t a department run by a former quality expert have solved its own quality problems already?

Armed with this new perspective on the situation with Jane, Todd and the team were able to create a “stakeholder plan” that incorporated a targeted influence strategy and set of tactics. Finally they began to make some progress on getting the latest data.


Chapter 17: Sample Plans for Getting Buy-in

The Scenario:

Overview

Jasmine Doe is the CEO of a mid-sized company that manufactures state-of-the-art components for the video editing industry. The company has had a Six Sigma program for just over a year, and the team that worked on the New Product to Market project was wildly successful, even getting some press for their efforts.

With the significant reduction in the time it took to develop the last new product, it became obvious that the new product marketing cycle couldn’t keep up. There is a lot of energy in the company to launch a new Six Sigma team to improve the marketing process.

Even with less than adequate marketing, the new product is selling better than expected. Jasmine has been doing a great deal of personal promotion with customers. Discus-sions keep getting sidetracked, however, by complaints about the company’s billing system. Invoices arrive late, are hard to understand, and have errors, and no one at the home office seems to have any answers when the customers complain. Jasmine has decided to launch a Six Sigma team to improve the billing process before or maybe at the same time as the marketing improvement process. She’s not really sure the billing project is worth the effort of a Six Sigma team, but she’s had it with listening to complaints.

Jasmine called a meeting with Art Lee, the manager of the billing department, and William Boyd, VP of MIS. Art agreed that the project would be a good idea, mainly because it would make the clerks in his department happy to be on a Six Sigma project. He was, however, a bit annoyed that it took so long to get Six Sigma resources for his department. He even went so far as to imply that Jasmine helped cause the billing problem by withholding resources in spite of his repeated requests. Things got a little tense at this point of the meeting.

Bill Boyd said he thought the marketing project was a lot more important to the company. (Jasmine secretly agrees, as this is where her interests and skills lie, but part of her recognizes the need to deal with the invoicing issues.) And he felt a bit defensive, since he helped create the original billing process. But Bill reluctantly agreed to let the majority rule, as long as nobody tried to tell him how to run MIS (like that Black Belt working on the new product development cycle did last year).

As a result of the discussion at the meeting, Jasmine has assigned a Black Belt, Thomas, to the Billing Improvement project. Following are sample plans for getting buy-in on a Six Sigma project to improve billing processes. We’ve included a plan for Thomas and the project team to use to:

  • Get buy-in from senior management (J. Doe, CEO)

  • Get buy-in from middle management (W. Boyd, MIS VP)

  • Get buy-in from line workers (Billing Department clerks)

Sample Project Stakeholder Identification Worksheet with Map

Click To expand

Sample Senior Management Stakeholder Analysis

Tool 17-1.
Start example
Click To expand
Click To expand
Click To expand
Click To expand
End example

Sample Senior Management Stakeholder Plan

Tool 17-2.
Start example
Click To expand
Click To expand
Click To expand
End example

Sample Middle Management Stakeholder Analysis

Tool 17-3.
Start example
Click To expand
Click To expand
Click To expand
Click To expand
Click To expand
End example

Sample Middle Management Stakeholder Plan

Tool 17-4.
Start example
Click To expand
Click To expand
Click To expand
End example

Sample Line Worker Stakeholder Analysis

Tool 17-5.
Start example
Click To expand
Click To expand
Click To expand
Click To expand
End example

Sample Line Worker Stakeholder Plan

Tool 17-6.
Start example
Click To expand
Click To expand
Click To expand
End example


Conclusion: Final Thoughts on Using This Pocket Guide

Overview

We expect that readers of this Pocket Guide will have one of two reactions to these tools and approaches:

  1. This is exactly what I need to make my Six Sigma projects a success!

  2. Am I going to be able to do this? And even if I can, do I have to? I got involved in Six Sigma because I enjoy using my analytical ability. Can’t everyone just be logical and rational so we can get these projects done?

While we hope that you’ve had the first reaction, we recognize why you might have the second. So to anyone with those concerns, we respond:

  1. Yes, you can do this. While using the tools may not come naturally at first, neither do many other things that later become second nature. (Think of learning to drive.) And you’ll have the Pocket Guide to fall back on.

  2. No, you don’t have to ... but you may want to, for two reasons:

    • You can’t force or “logic” people into supporting your project. Though force may sometimes appear to work, it’s generally not an effective approach ... nor does this enhance your reputation in the organization. Further, when people consider whether they will support you, they do not rely on logic alone (sometimes they don’t rely on it at all!).

    • Practicing the approaches described in this book can help your career. People with both technical and team/influence skills are much more promotable and marketable than those with only one or the other.

So what should you do now?

Project Team Leaders:

  • Introduce your team members to the Pocket Guide and its concepts, and encourage them to get familiar with the approaches and tools.

  • Tell the team you’re committed to following the guide as the team does its project work.

  • Invite the team to work together on stakeholder identification, analysis, and planning. Not only will this result in a better plan (since it will be based on the knowledge of several people), but it also gets the team working together.

  • If your company selects and/or promotes Black Belts at least partly on the basis of suitability for future leadership positions, let your manager know about your new team and influence skills.

  • Introduce the Pocket Guide concepts to whoever is responsible for Master Black Belt, Black Belt, and Green Belt development. The more people who use the guide’s tools and approaches on their projects, the better for the overall Six Sigma initiative.

Project Team Members:

  • If your project team leader introduces the Pocket Guide to the team, cooperate in following the approaches and tools.

  • If your team leader doesn’t have the Pocket Guide, introduce him/her to it, and suggest that the team start using the approach and tools. Do this one on one (not in front of the team), and prior to the first team meeting if possible. You might want to show the team leader the chapters on preparing for and running the first team meeting.

  • Even if the team doesn’t adopt the Pocket Guide, use the tools on your own piece of the project work.

All:

  • Think about previous Six Sigma (or other) projects you’ve worked on. Identify ways the project might have gone more smoothly or where it might have run into trouble. Think of what might have been the root cause(s) of any nontechnical problems you encountered during that project. Consider whether and how you could have benefited from using the approaches and tools outlined in this guide.

  • Think about your current project and how it’s progressing. Identify which of the tools in the Pocket Guide you could use right now to make the project go more smoothly.

  • If you’re interested in attending a workshop that teaches these techniques in detail, contact Rath & Strong.

This guide is designed to increase your ability to get your Six Sigma projects completed successfully. Whether you’re leading the project team, participating part-time, or providing subject matter expertise when needed, the tools in the Pocket Guide can help you contribute to the project’s success.

We hope you’ve found it useful.


List of Tools

Chapter 1: The Role of the Project Team Leader

Tool 1-1.
Tool 1-2.
Tool 1-3.
Tool 1-4.

Chapter 2: The Role of the Project Team Member

Tool 2-1.

Chapter 3: What to Do at the First Six Sigma Project Team Meeting

Tool 3-1.
Tool 3-2.

Chapter 4: How to Establish Project Team Goals, Roles, and Procedures

Tool 4-1.
Tool 4-2.
Tool 4-3.
Tool 4-4.

Chapter 5: How to Have an Effective Project Team Meeting

Tool 5-1.
Tool 5-2.
Tool 5-3.
Tool 5-4.
Tool 5-5.

Chapter 6: How to Make Decisions on the Project Team

Tool 6-1.
Tool 6-2.
Tool 6-3.

Chapter 7: Three Ways to Handle Project Team Conflict, and When Each Works Best

Tool 7-1.

Chapter 8: How to Deal with Difficult Project Team Members

Tool 8-1.
Tool 8-2.

Chapter 9: How to Figure Out What's Wrong When the Team Isn't Working Well or Loses Momentum

Tool 9-1.
Tool 9-2.
Tool 9-3.
Tool 9-4.
Tool 9-5.

Chapter 10: The “Politics“ of Six Sigma Projects: Planning to Get Support and Cooperation from People Outside the Team

Tool 10-1.
Tool 10-2.
Tool 10-3.
Tool 10-4.
Tool 10-5.

Chapter 11: Five Ways to Influence People to Cooperate with Your Six Sigma Project

Tool 11-1.
Tool 11-2.
Tool 11-3.

Chapter 12: How to Communicate with People Whose Help You Need

Tool 12-1.
Tool 12-2.

Chapter 13: How to Be a Better Listener So That People Will Want to Help You

Tool 13-1.
Tool 13-2

Chapter 14: How to Avoid the Pitfalls of E-Mail on Six Sigma Projects

Tool 14-1.

Chapter 15: How to Make an Effective Presentation About Your Six Sigma Project

Tool 15-1.

Chapter 16: What to Do When You're Not Getting Cooperation

Tool 16-1.
Tool 16-2.
Tool 16-3.

Chapter 17: Sample Plans for Getting Buy-in

Tool 17-1.
Tool 17-2.
Tool 17-3.
Tool 17-4.
Tool 17-5.
Tool 17-6.


List of Sidebars

Chapter 16: What to Do When You're Not Getting Cooperation

Example of Resistance and Its Underlying Reason

Team LiB
Previous Section