COACHING PROCESS IMPROVEMENT TEAMS

Transcription

1 COACHING PROCESS IMPROVEMENT TEAMS LORI L. SILVERMAN Partners for Progress 1218 Carpenter Street Madison, WI 53704, USA ANNABETH L. PROPST Fuller & Propst Associates 41W202 Whitney Road St. Charles, IL 60175, USA I don't understand it. We've had these teams for months and nothing's happened. Our teams are floundering and we don't know what to do. We tried to help our teams but they resented our suggestions. Some people even quit. Put a group of people in a room with a problem to solve. Give them a basic method for problem solving and they will solve the problem. Right? Not always. So what is needed for teams to be successful in their problem-solving efforts? When a company integrates a total quality management approach into its day-to-day and strategic operations, it tends to stumble onto the answers to this issue. To be successful, process improvement teams (i.e., teams of employees of cross-functional and multilevel representation) that are put together to solve problems need: 1. To be composed of the appropriate individuals those who work in the work process where the problem is occurring, and customers and suppliers to that work process; 2. Team members who have been exposed to the seven basic QC tools and teams skills; 3. To be given real problems to solve, not solutions to implement; 4. A problem-solving methodology that investigates root causes based on data, before moving the team to potential solutions and standardization of results; 5. An approach to building a team environment in which team members have been empowered to solve the problem within stated parameters and understand their roles and COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 1

2 responsibilities, the problem situation, and the team s ground rules for working together; and 6. To have been provided with the services of an internal/external consultant who has been trained in the above as well as how to coach the team through the process of problem solving and how to build a team. This is especially necessary when team members have not had the opportunity to utilize a problem-solving methodology on a regular basis and have not had to solve problems in a team-based environment. This paper focuses on two of these areas: a problem-solving methodology called the 7-Stage Problem-Solving Process, based on the QC Story (1); and an approach for coaching a process improvement team through this methodology and its interactions as a team. This paper assumes that the team has received the appropriate training, that the right members are on the team, and that the team has a common understanding of its charter (what others think it is to do), its mission (purpose and scope of its efforts), its ground rules, and individual roles and responsibilities. PROBLEM SOLVING VS. CONTINUAL IMPROVEMENT Before discussing these two areas in more detail it is important to distinguish between problem solving and continual improvement. Problem solving is the action(s) taken to get rid of an existing specific, undesirable effect(s). There are generally two types of problems: too much of something with a need to decrease or eliminate; or too little of something with a need to increase. Examples of these two types of problems include reduction of a particular item (e.g., expenses), elimination of the occurrence of a particular item to zero (e.g., customer complaints), or increasing a particular item (e.g., sales or market share). Continual improvement is the action(s) taken to optimize a specific characteristic or set of characteristics even though performance of the characteristic(s) might be acceptable to the customer. The 7-Stage Problem-Solving Process works best for the types of problems described here. It does not as readily apply to continual improvement opportunities. (See the book, Critical SHIFT: The Future of Quality in Organizational Performance for a systematic approach to continual improvement.) 7-STAGE PROBLEM-SOLVING PROCESS The 7-Stage Problem-Solving Process has been adapted from the QC Story to reflect the philosophy of W. Edwards Deming. This adapted method continues to embody a number of quality concepts found in the QC Story approach: 1. The use of data to understand problems, make decisions, and test theories; 2. Stratification of data to identify root cause(s); 3. Solutions focused on curing root causes rather than treating symptoms; 4. Standardization of the problem solution; and COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 2

3 5. Utilization of the Shewhart (Plan-Do-Check-Act) Cycle, both at the macro (overall seven stages) and micro (within the stages) levels. An overview of this method is shown in Figure 1, the 7 Stage Problem Solving Process. Each stage in the 7-Stage Problem-Solving Process is explained here in more detail before the coaching framework that supports its success is explained. Specifically, the following information is outlined for each stage: The purpose of the stage; What the team will need to have to complete the stage; What the team needs to do during this stage to assure its completion; and What the team will want to have accomplished before proceeding on to the next stage of the problem-solving process. Stage 1: Identify the Problem The purpose of Stage 1 is to establish the importance of the problem as a basis for checking later on to see if the problem is solved. Understanding the importance of the problem may impact the resources needed to solve it. For example, is the problem serious enough to warrant the expenditure of time and/or money that will be needed to solve the problem? The team also needs to establish early on how it will know if the problem has been solved. This helps the team understand the features that the solution must embody, as well as the data that will need to be collected, both on the initial state of the problem and its changed state. To begin, the team will need: A team charter; A problem to work on; and Data on the behavior of the problem. Using data, the team should first state the undesirable effects of the problem such as customer complaints, loss of customers, higher costs, or unsafe working conditions. After determining these, the team should further explore these effects. For example, what are the effects of unsafe working conditions? Are people quitting as a result? Are they not doing a thorough job so they can leave the unsafe area sooner? What could be other effects? Could someone get killed? The team should continue this questioning approach until the effects are thoroughly understood and documented. Often a team will begin by stating the problem as an answer or as an interpretation of the effects. It takes perseverance to reverse direction to find the problem. After understanding the undesirable effects of the problem the team must establish the focus of the problem. If the problem is large, the team may decide to work on the problem in smaller chunks. A problem that is too big may be intimidating even impossible to solve. If the decision is to focus only on limited aspects of the problem, the team can always return to bigger issues in a COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 3

4 Figure 1: 7-Stage Problem-Solving Process Inputs Stage Outputs Team mission Known problem Data on behavior of problem Stage 1: Identify the Problem Specific problem statement Plan (milestones) Metrics for monitoring Resource requests Data about the problem Specific problem statement Process knowledge Deeper understanding of initial problem statement Process theory Data about how the problem behaves Stage 2: Investigate the Problem Stage 3: Uncover the Cause(s) Flowchart of work process Stratified data Deeper understanding of initial problem statement Impact of problem on customers and suppliers Understanding of cause system Main cause(s) of the problem Main cause(s) of the problem Process knowledge Organizational knowledge Stage 4: Take Action on the Main Cause(s) Plan of action Limited test of solution Results of test Data on initial behavior of problem Results of test Stage 5: Confirm the Effectiveness of the Action Comparison of new vs. old problem behavior Decision on solution effectiveness Plan of action Observations from trial Decision on solution effectiveness Organizational knowledge Process knowledge Stage 6: Eliminate the Cause(s) Permanently New job standards Instructions for the job System for ongoing monitoring Institutionalized change Team mission Data on new current state Experience using problem solving process Stage 7: Review Activities and Plan Next Steps New directions for team Suggested improvements to the 7 Stages COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 4

5 later problem-solving cycle. Any constraints such as budget or time should be brought to the team's attention at this point as they may help in determining the focus of the problem. Once the team has identified the scope of the problem, it is important for it to determine how progress will be measured. Reduction or elimination of the problem would be one obvious measure of progress, but there are often others. The team should start by identifying the characteristics of a perfect solution. Initially, this list of characteristics will not be in terms of numerical measures but will be a list of qualitative indicators of success such as less wasted effort, higher customer satisfaction, and so on. When the list is complete, the team should address how progress could be measured or monitored against each item. Sometimes it may be as simple as a yes/no response while other times it will be a numerical measure. Finally, the team needs to develop a plan for solving the problem. The 7-Stage Process provides a framework for problem solving, but the specific details of each stage will vary from problem to problem. Questions about the kind of data to be collected, testing of theories, and determining the basis for a trial solution are key here. The team should recognize that as it moves through the stages, its plan might need to be adjusted based on what has been learned about the problem. However, any deviations from the plan should be made consciously and be based on new knowledge. As part of this plan, the team should identify any available resources that may be needed such as time, other people (support or experts), equipment, travel funds, etc. These resource requests should be communicated as soon as possible. Flowcharting the plan can help to delineate the specific milestones in the team's plan. Before proceeding to the next stage the team should have: A specific problem statement; A plan (with milestones noted); Metrics for monitoring progress; and Resource requests. Stage 2: Investigate the Problem The purpose of Stage 2 is to thoroughly understand how the problem behaves from a variety of viewpoints. This will aid the team in suggesting or eliminating possible causes of the problem. To complete this stage the team will need: Data about the problem; Process knowledge; and A specific problem statement. To gain a better understanding of the problem, the team should first study its features such as when and where the problem occurs and its symptoms. The team will need to study data from as many different views as possible. The more viewpoints used, the better. Any new characteristics of the problem or characteristics of its associated work processes should also be studied. It is COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 5

6 sometimes difficult to come up with ways to continue to stratify the data. When this happens it is easy to dismiss a dimension as not being applicable to the specific problem. Even if some team members think that a particular dimension does not have an effect, it should be stratified and studied. Knowing what is not a factor is as valuable as knowing what is. At this point, the work process within which the problem occurs should be flowcharted from each person s (those who work on the process) point of view if this has not already been done. If a flowchart of the actual work process does exist, it should be checked to make sure it truly represents the work process that is currently being used. If it does not exist, then it will be necessary to do this work. Note the switch from focusing on the problem to focusing on the work process. This is consistent with Dr. W. Edwards Deming s philosophy that the only way to achieve results is to focus on work as a process. The team should observe firsthand the work process within which the problem appears to occur, including its physical environment. Even though such observations may not be quantifiable, they can be extremely helpful in assessing the potential causes of the problem. Key to this stage is the team's understanding of the problem from the customers perspective. It must identify the customers, how they use the product and/or service, and what the customers processes are in which the product and/or service is used. It is important to address such issues as how the problem impacts the customers processes, and whether or not changes would affect them positively or negatively. In addition, the team should also understand the suppliers perspectives, including their capabilities, work processes and whether or not the suppliers are willing to work with the team. The team may even want to ask customers to help flowchart the work processes within which the problems occur. Sometimes teams will skip the customer and supplier steps. This can be a fatal error. It is important to look at the entire system when evaluating the problem, its behavior, and its associated work process. Before proceeding to Stage 3 the team should have: A flowchart of the work process; Stratified data; A deeper understanding of the current (initial) state of the problem; and An understanding of the impact of the problem on the customer(s) and supplier(s). Stage 3: Uncover the Main Cause(s) The purpose of this stage is to determine the cause(s) of the problem in a scientific manner. This includes the use of scientifically collected data to test theories. To complete Stage 3 the team will need: Deeper understanding of the current state; Process theory; and COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 6

7 Data about how the problem behaves. The team must first form theories about the possible causes of the problem through the use of brainstorming. The question that needs to be answered is: What are the possible causes of the problem as documented in Stage 1? A cause and effect diagram works well here. It is not practical to test all of the causes at once, so the list must be narrowed down. The stratifications done in Stage 2 will eliminate some causes. From the remaining possibilities, the team should identify the most likely causes based on process theory and process knowledge (experience). Team members should then state their theories about how these causes affect the problem. Helpful probing questions include: If we increase X, will we see more problems or fewer? If we eliminate Y, will the problem go away? If we change suppliers, will our variability decrease? New data is required to test these theories. This may necessitate re-creating the problem or increasing/decreasing the magnitude of the problem to obtain the needed data. Only by changing elements of the cause system, and reversing them while observing the effects, can a cause and effect relationship be assured. Statistically sound experimentation techniques are essential. Resist the temptation to use existing theories to test data. With the data collected during its experimentation, the team must test its theories. This includes using designed experiments to change factors and using graphical techniques as well as Analysis of Variance to analyze the data and identify whether the expected relationships exist. If a theoretical relationship is not seen in the data this does not necessarily mean the relationship does not exist. Something else may be masking the effect. However, the existence of a masked relationship will not help to solve the problem. The data the team collects may lead to confirming its theories, denying its theories, or modifying its theories. The team should continue to form and test theories until the main causes have been uncovered. Main causes are defined by the authors as those 20% of the causes that account for 80% of the results. It is not appropriate to use a voting approach to determine the main causes. Before proceeding to the next stage, the team must have: An understanding of the cause system and its effect on the problem; and Determined the main cause(s) of the problem. Stage 4: Take Action on the Main Cause(s) The purpose of this stage is to propose and test solutions to the problem, given the main cause(s) identified in the previous stage. To complete this stage the team must have: The main cause(s); Process knowledge; and Organizational knowledge. COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 7

8 In this stage the team should focus on those solutions that act on the main cause(s) rather than those that merely treat the symptoms. In order for the team to knowledgeably evaluate the proposed solutions, they should be described in detail. For example, if a solution involves buying new equipment, the team should describe the equipment its features and its advantages and disadvantages. If the solution is a new method, it should be flowcharted and the team should also identify what other changes must take place in order to follow the new method. Each of the proposed solutions must be thoroughly understood. The team must then evaluate all solutions and compare them to each other. The team should evaluate possible side effects of each solution so modifications can be made before pilot testing it even if only one solution is proposed. The team also needs to consider other issues such as the costs of the change(s) and its benefits, as well as what could go wrong if the change(s) is made. At this point the team s choices are to go with one of the original solutions, to modify one of the solutions, to combine the features of several solutions, or to develop an entirely new proposal. The team should continue in this manner until it has selected a single solution. Again, it is necessary to brainstorm all of the things that could go wrong with the selected solution and build preventions or contingencies into it. The solution should then be tested for a limited time on a limited basis one location, one department, one supplier, one shift, and so on. However, before conducting this test, the details of the test must be planned. It must be determined how the test will be conducted, who will be involved, the length of the test, the data to be collected and how and by whom, and how the data will be analyzed. Flowcharts are helpful. All of the people involved in the test must completely understand the purpose of the test and how it will be conducted. This may necessitate additional training.teams tend to want to jump into the pilot test phase without planning thoroughly. It is a challenge to restrain their eagerness to move forward. Using the plan, the team should conduct the test, noting any difficulties. All observations and effects must be recorded, including the effects of the tests, both good and bad. Before moving to Stage 5, the team must have: A plan of action; Carried out a limited test of the solution; and The results of the test. Stage 5: Confirm the Effectiveness of the Action The purpose of this stage is to check the results of the test to learn if it solves the problem and, if the solution does not solve the problem, what the results are. To complete Stage 5 the team must have: Data on the initial behavior of the problem; and The results of the test COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 8

9 The team needs to look back to the initial problem statement developed in Stage 1 and determine if the problem is solved. Then the team should stratify the data from Stage 4 and compare it to the stratifications obtained in Stage 2. It is important that the data from the test be stratified along the same dimensions as in Stage 2. Key areas to consider include whether the behavior or level of the problem has been affected and if further improvement is desired. Note that even though the focus switched from a problem to its associated work process in Stage 2, the team was, after all, interested in solving a problem. This check must, therefore, be against the initially defined problem. The effects of the test (both good and bad) and any other observed effects need to be reviewed. The team should go back to the metrics and indicators that were developed in Stage 1 to see if they have all been accomplished given the results/effects of the test. If they have not been accomplished, the team should note how large a gap still exists. The team must then decide if it is ready to implement the change(s) on a larger scale. If the test has been completely successful, the team should fully implement the change(s) and proceed to Stage 6. If the test was completely unsuccessful (no progress or worse problems), the team has three options. It may: 1. Return to Stage 4. Using what has been learned as a result of the test, the team would reevaluate the possible solutions, test untried solutions, or develop another solution. Repeat the stages from there. 2. Return to Stage 3. The team would re-evaluate the list of main causes, try to duplicate the results of the earlier experiments, test some other causes, and form some new theories. Repeat the stages from there. 3. Return to Stage 2. The team would try to learn more about the behavior of the problem, perhaps through stratification along different dimensions. The resulting data would need to be displayed and understood. Repeat the stages from there. If some progress has been made toward solving the problem, the team has the same three options for continuing the improvement. In addition, it will want to implement the changes that have been made and standardize these gains. Before going on to Stage 6, the team should have: Compared the new behavior of the problem to its old behavior; and Made a decision on the effectiveness of the solution. Stage 6: Eliminate the Cause(s) Permanently The purpose of this stage is to institutionalize the solution and ensure ongoing performance at the improved level. Ongoing monitoring is needed to ensure this new level of performance. To complete Stage 6, the team must have: A plan of action; COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 9

10 Observations from the trial; A decision on the effectiveness of the solution; Organizational knowledge; and Process knowledge. The team will create standards for the improved work process in this stage. The improvement must be thoroughly documented through the use of the 5 W s and 1 H: Why it is being done this way; What is to be done; Who is going to do it; Where it is going to be done; When it is to be done; and How it is to be done. Flowcharts should be used as much as possible as should diagrams, pictures, and maps, as they are needed. The team should consider what other documents might need to be changed to reflect the solution. Next, a system to monitor the process in the future should be set up. Both the work process and its results should be monitored through questions such as: Are people following the process correctly? Are the results being maintained? If not, why not? The monitoring system should include information on the type of data to be collected, the person(s) responsible for collecting it, how and how often to collect it, how to analyze it, and what to do if there is a problem. Those individuals who work in the process, as well as those who might do the job or be impacted by it, need to be educated and trained in the new methods. The history of the problem, the 5 W s and 1 H, and the ongoing monitoring system should be part of this training. Any existing or ongoing training programs that might relate to this changed work process also need to be updated. Teams often overlook this stage and, as such, are subject to the Hawthorne effect whereby just by being observed, the work process exhibits improvement. Before moving to the last stage, the team should have: New standards for the job; Instructions for the job; A system for ongoing monitoring; and Institutionalized change. Stage 7: Review Activities and Plan Next Steps The purpose of Stage 7 is to bring closure to the problem. This is done by reviewing key learning and planning future activities. To do this the team will need: Data on the new current state; COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 10

11 Experience using the 7-Stage Process; and The team charter. Before embarking on this stage, the team should take time to acknowledge and celebrate its success. This helps team members feel good about their efforts and, as such, serves as a form of recognition. Using data collected during the trial and after full implementation of the solution, the team has a responsibility to document any remaining problems. Before deciding what to work on next the team should compare the new current state of the work process to the team mission to decide whether it has accomplished what it set out to do, and whether or not associated problems never before realized are occurring. If the decision is to continue as a team to work on remaining problems, the team must set priorities and carefully select the topic of the next problem-solving cycle. Finally, the team should use what it has learned to suggest improvements to the 7-Stage Problem-Solving Process. This step will help each team member remember and build on what he/she has learned. It will also make it easier to share new knowledge with others. Before the team is finished with the 7-Stage Process it should have: A new direction for the team, and Suggested improvements to the 7-Stage Process. Figure 2, Detailed Overview of the 7-Stage Problem-Solving Process provides a convenient reference, answering the why s, what s, and how s and providing tips for each of the seven stages. THE NEED FOR COACHING Providing teams with a methodology for problem solving based on quality concepts and the philosophy of W. Edwards Deming will help to direct the team s problem-solving efforts toward resolution. However, if the team members are not able to communicate effectively, confront sensitive issues; focus on the problem, not the people; gain the participation of everyone; or overcome hidden agendas; the team will not be able to proceed through the model. Or, the team will attempt to plow its way through the 7-Stage Process, skipping stages along the way in order to quickly wrap up its efforts. It is also not surprising to find teams that, even when trained in the 7-Stage Process, want to take shortcuts because the approach is so different from traditional methods of problem solving. They cognitively see the need for a rigorous approach based on data but are not able to apply their knowledge to a specific problem. They become impatient and often fall back to the old way of COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 11

12 Figure 2: Detailed Overview of the 7-Stage Problem-Solving Process Stage Why What How Tips Identify the To establish the Problem importance of the problem and provide a basis for checking later on to see if the problem is resolved Investigate the Problem Uncover To determine the the Main cause(s) of the problem Cause(s) in a scientific manner State undesirable effects of the problem Establish the problem focus Determine how to measure progress Develop the plan for solving the problem Identify necessary resources Study the problem features Study the problem from several points of view (people, equipment, etc.) Observe the problem and its associated work process Understand the problem from the customer' and suppliers' perspective Form theories about causes Test the theories, using new data COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 12 Pareto Charts Run charts Histograms Brainstorming Flowcharts Pareto Charts Run charts Control charts Histograms Stem and Leaf Box plots Flowcharts Observation Photographs Maps Cause and effect diagrams Experimental design Scatter plots Run charts ANOVA Study the undesirable effects of the problem Avoid stating the solution Use graphics to display data wherever possible Visualize what would be different if the team were successful Stratify the data as many ways as possible Use graphs to display data Avoid drawing conclusions about causes or solutions; focus on the behavior of the problem Use new data to test theories Avoid voting to select causes Look for causes of causes

13 Stage Why What How Tips Take Action on To propose and test solutions to the problem the Main Cause(s) Confirm To check the results of the the test to learn if it Effectivene solves the problem; if it ss of the does not solve the Action problem, to note what the results are Eliminate To institutionalize the the solution and ensure Cause(s) ongoing performance at Permanentl the improved level y Review To bring closure to the Activities problem and Plan Next Steps Propose solutions Evaluate solutions Plan the test Conduct the test Compare results to initial problem statement List other effects, good and bad Decide if you are ready to implement the changes on a full basis Create new work process standards Train people in the new methods Set up a system to monitor the process in the future Document the remaining problems Decide what to work on next Suggests improvements to the 7-Stage Process Brainstorming Affinity diagrams Flowcharts Reverse fishbone Failure mode and effect analysis Pareto Charts Run charts Control charts Histograms Stem and leaf Box plots Flowcharts Diagrams Pictures Pareto Charts Run charts Control charts Histograms Stem and leaf Box plots Brainstorming Act only on causes identified in Stage 3 Clearly identify limited basis for test Get buy-in from key people before test Use same data and charts as in Stages 1 and 2 Check for other process behavior changes Compare results to desired improvement Document the change and train people thoroughly Communicate to all who might be involved Monitor changes regularly Celebrate success Recognize when it is time to disband the team COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 13

14 solving issues. Therefore, it is important that the team has someone to coach it through how to solve the problem and the way the team works together to solve it. This coaching will help to ensure the integrity of the 7-Stage Process as well as make the team members experiences more satisfying. CHOOSING COACHES Coaches need to have a well-rounded background in quality and team-based concepts, tools, and methods. More specifically, they minimally need to be able to use and explain fundamental quality concepts such as the Shewhart Cycle, work as a process, process variability, and customer focus; and team concepts such as group dynamics, task versus relationship issues, and how a group differs from a team. They also need to be skilled in tools and methods such as the 7 basic QC tools, flowcharting, stratification of data, the 7-Stage Problem-Solving Process, building a team environment, participative techniques, active listening, and meeting management. Early on in a company s total quality management efforts, it is important that those chosen to coach a problem-solving team are not the direct supervisor of any of the team members, are not a leader/member of the team, and do not have a vested interest in the outcome of the team s efforts. The coach needs to be able to look at the team from an overall systems perspective. That is, the coach needs to be distant enough from the problem and team members to take an objective approach and yet close enough to what is going on (that is, attending the team s meetings) to stay abreast of what is happening and be able to provide credible feedback. However, to ensure the integration of total quality management throughout the organization, coaches need to be supervisors and/or managers. ROLE OF COACHES Coaches need to tailor their role around a particular model of consulting. There are a variety of models one can choose from. Examples include the medical model, the expert model, the trainer/educator model and process consultation. The model of consulting found to be most effective (by the authors) with process improvement teams is that called Process Leader (2, 3). This is a more active approach when compared to the process consultation model defined by Schein (4). The individual reaches beyond strict process-focused interventions (e.g., clarifying issues, asking probing questions, summarizing responses) to actually commenting on the content of the team s work. This does not, however, mean that the coach wades deeply into technical conversations. What it means is that the coach may lead a discussion, offer alternatives based on subject matter expertise that have not been stated by others, and question what is being done related to the changes the team is trying to effect. Effective coaches do not just avail themselves to the team during its meetings. They also hold pre- and post-meeting sessions with the team leader, and possibly others, as agreed on by the COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 14

15 team. Pre-meeting sessions focus on the meeting agenda and the approach that will be used by the leader of each agenda item to move the team through each topic. This meeting is also a time to discuss other sorts of strategies related to participation and group dynamics. Post-meeting sessions, usually held immediately after the meeting, are for debriefing purposes: to determine the effectiveness of the agenda and topic approaches; assess any surprises; and find out how the team leader honestly feels about the meeting. Given the active nature of the process leader model, it is critical that the team leader and all team members understand the role of the coach. It is also important that the same coach be used throughout the lifespan of the team. Switching coaches adds an element of variability to the team s approach and changes the dynamics of how team members interact with one another. FRAMEWORK FOR COACHING TEAMS The ultimate goal of the process leader model is to assist the team in the successful completion of its work. In order to do this, the coach needs to employ a framework for coaching teams that builds upon this model. The framework shown in Figure 3 has three component parts that serve as the basis for assessment of the team's efforts and choosing how to respond to what's happening in the team. Figure 3: Framework for Coaching Teams What the team actually says/does How the team approaches its task How the team works together COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 15

16 What the team actually says/does refers to the verbal, nonverbal, and written communication generated by the team. It also includes any written documentation (i.e., forms, data, charts, diagrams) used by the team in its work. The coach s role is to encourage open communication, collective understanding, and assessment of the accuracy of this information. The coach also needs to pay attention to whether or not the team is actively using the written documentation available to it. It is also important that the coach work with the team to ensure it records its work throughout the 7-Stage Problem-Solving Process. Examples of what to look for in this part of the framework include: use and understanding of jargon, acronyms, and terms; the amount of conceptual versus detailed communication; the thoroughness of the communication; use of pictures and diagrams to enhance communication; use of assumptions and intuition rather than facts and data; and use of active listening skills. How the team approaches its task refers to the processes the team uses to collect, organize, analyze and act on the information/communication it generates or uses in how it does its work. Often, teams will create flowcharts of these processes to increase their effectiveness in these areas. The coach s role is to ensure the team follows the 7-Stage Problem-Solving Process and the processes it created to move itself through its work. A key part of this role is the facilitation of the team s use of quality tools and concepts such as the Plan-Do-Check-Act cycle. In addition, participative tools such as brainstorming, nominal group, and round robin need to be used by the team. The coach assesses whether or not these participative tools are being used and, if so, whether they are being used appropriately. Examples of what to look for in this part of the framework include: whether or not the team is oriented towards process or outcome, whether or not the team is skipping stages or steps in the problem solving process and the reason(s) for doing so; members ability to use a variety of tools and methods to do their work; and appropriate use of tools, methods, and concepts. How the team works together focuses on the relationships that exist between team members at the interpersonal and team levels. The coach s role is to assist the team in building these relationships. Key aspects of relationship building are trust, respect, credibility, and integrity. Since relationships are predicated by the thoughts, feelings, and attitudes of each person on the team, the coach must elicit these in order to effectively assist the team. It is also important that the team feel good about working together. The coach s role is to encourage acceptance of each person as a unique individual, to break down stereotypes or other types of barriers, and to create a safe, empowering team environment. Examples of what to look for in this area of the framework include: what the stated and implied norms are for the team, whether or not the team has ground rules for working together and how effective these ground rules are, how the team handles problem behaviors, how the team makes its decisions and the impact this has in and outside the COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 16

17 team as well as the amount and type of participation that is occurring in and outside of team meetings. In order to utilize the framework for coaching teams during a team meeting, the coach continually monitors each of these areas simultaneously (data collection), assesses what is happening within each area of the framework and makes a decision as to whether or not to intervene. This may sound easy, but within a team environment it is a challenge. So much is going on at any one moment in time that it often becomes necessary for the coach to prioritize issues for intervention and only focus on the top items. It is important to note that even though this framework shows each area as being of equal importance, it is sometimes more effective to intervene in how the team approaches it task. The assumption here is that people who are able to collectively focus their efforts and move toward task accomplishment will, in the process, start to build positive working relationships with each other. And one can also assume that all team members are, in essence, subject-matter experts in what is being said or done. Pre- and post-meeting, the framework for coaching teams can be used by the coach and team leader as the basis for discussion. Accuracies in communication/data could be the focus of the what the team actually says or does discussion. Discussions on how the team approaches its task could focus on where the team is in the 7-Stage Process and any difficulties it is having getting through the stages. Items such as participation, involvement, and conflict could be the focus of the discussion on how the team works together. CONCLUSION When a rigorous problem-solving approach based on quality concepts such as the 7-Stage Problem-Solving Process is combined with a framework for coaching teams through the process, several things can happen. First of all, the team might discover that it has the wrong membership to solve the problem. Second, the team may discover that the perceived problem is not the real (root) problem. On a more positive note, the team may increase its ability to work together effectively outside of its problem-solving work. In addition, team members no doubt will learn new concepts, tools and methods through actual application and may even be able to solve long-standing problems/issues. Both a problem-solving methodology based on quality concepts, tools, and methods and a coaching framework that together address team problem solving from an overall systems perspective are necessary for a process improvement team to be successful. COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 17

18 REFERENCES 1. Kume, H. (1985). Statistical Methods for Quality Improvement. (Japan: The Association for Overseas Technical Scholarship). 2. Moosbruker, J. (1989) The consultant as process leader. OD Practioner, (Vol. 21, No. 1, pp ). 3. Bellman, G.(1990). The Consultant's Calling. (San Francisco: Jossey-Bass Publishers). 4. Schein, E. (1988). Process Consultation. (MA: Addison-Wesley). ABOUT THE AUTHORS Lori L. Silverman Lori is the owner of Partners for Progress, a management consulting firm dedicated to helping organizations achieve and maintain a sustainable competitive advantage. Her expertise spans work in the areas of business strategy, enterprise-wide change and performance improvement. Lori is the co-author of Critical SHIFT: The Future of Quality in Organizational Performance and Stories Trainers Tell: 55 Ready-to-Use Stories to Make Training Stick. Over the past 15 years she has published over 60 articles and workbooks on strategic planning, coaching, organizational change, self-managed teams, corporate storytelling, consumer obsession, and performance excellence. She is sought after as a keynote speaker, having positively impacted the lives of 1000s of conference and meeting participants. Annabeth L. Propst For almost twenty years, Annabeth was a management consultant, specializing in quality and productivity improvement, statistical thinking, and Theory of Constraints. Prior to that, she worked in manufacturing in a variety of engineering and quality positions. She is the co-author of Critical SHIFT: The Future of Quality in Organizational Performance and the author of a number of articles that have appeared in publications such as Quality Progress, Quality Engineering, and Quality Digest. Annabeth has also been a frequent speaker at American Society for Quality conferences and meetings. In 2002, she made a career change, and now makes grows and sells plants and flowers at farmer s markets. COPYRIGHT 1991 PARTNERS FOR PROGRESS AND FULLER & PROPST ASSOCIATES. ALL RIGHTS RESERVED. 18