Plan, Do, Check & Act Cycles

Introduction

Total Quality Management has a rich history outside of health care.  Within health care, Total Quality management (TQM) started recently but gained wide popularity quickly.  From a handful of early advocates, TQM has grown to encompass almost all health care organizations. The rapid growth of TQM has led to many different variations of its implementation. Sometimes, what is called TQM in one organization is radically different from another organization. But all variations of TQM share some common steps. One approach was suggested by Batalden and colleagues (see Journal on Quality Improvement 1994, 20, 4:167-180). We have adapted the steps suggested by these authors.  While we present a step by step approach, you are free and encouraged to deviate from these steps. In this regard, Batalden and colleagues write:

"At any point, it is possible - and may be desirable - to step out of the prescribed step and begin an improvement trial using a Plan-do-check and act (PDCA) method. The worst that might happen is that the experiment may fail. If the trial is small scale, little harm would have been done, the need for a new change trial would have been identified, and learning would have been advanced."

Objectives

• Describe the TQM implementation process.
• List the 10 steps of the TQM process as presented in this course.
• Describe five strategies for improving the problem definition.
• Explain how these three TQM tools are used: fishbone charts, flow charts and storyboards.
• Discuss the importance of using media to promote TQM initiatives.
  

Steps 1 through 4: Change the Culture

In the previous section, we highlighted the steps organizations need to go through to prepare the organization for change.  We do not repeat these steps here but encourage you to read the previous lecture.  More►

Step 5:  Assign Teams to Problems

TQM is organized around specific problems within the organization. It is important to improve the central problems of an organization and not the most convenient ones. The problem has to be real, significant, and important to the majority of customers. Of course, any problem should be solved and any defect should be improved. But given the resources available, it is important to focus on the more important problems first.

Assigning a team to a problem requires careful attention to the composition of the team.  A multi-disciplinary team is needed so that team's decisions can be quickly implemented and tested.  Management, nursing, physicians and other clinicians need to be involved.  Defining the task of these interdisciplinary teams should be done carefully.  Much can go wrong. 

While little attention is paid to the art of defining a problem, it remains one of the most important steps in solving a problem. Often teams work for years on a problem that was defined in a matter of days. Spend some time and care in defining the problem right so that you will not solve the wrong or solve an inconsequential problem.  Russo JE, and Schoemaker JH in their book Decision Traps identify the following issues that may affect problem definition:

1. "Plunging in. Failing to gather sufficient information and jumping to conclusion about the nature of the problem.
2. Frame blindness. Setting out to solve the wrong problem because you have created a mental framework for your decision, with little thought, that causes you to overlook the best options or lose sight of important objectives.
3. Overconfidence in your judgment. Failing to collect key factual information because you are too sure of your assumptions and opinions.
4. Short sighted short cuts. Relying inappropriately on rules of thumb such as implicitly trusting the most readily available information or anchoring too much on convenient facts.
5. Shooting from your hip. Believing that you can keep straight all of the information that you have discovered.
6. Fooling yourself. Failing to interpret the feedback you are receiving, either because you are protecting your ego or because you are tricked by hindsight.
7. Group failure. Assuming that with many smart people involved, good choice will follow automatically, and therefore failing to mange the group decision making process.
8. Not keeping track. Assuming that experience will make its lessons available automatically, and therefore failing to keep systematic records to track the results of your decisions."
   

Given all that can go wrong with defining a problem it is important to take time and do it right.  There is little data on what is the most effective method for problem definition. But some advice can be obtained from the research in this area.

1. Define a problem without suggesting a solution. People often define the problem in a way that it strongly or actually suggests a solution. This prevents the team from searching all possible options. For example, one hospital was experiencing problems with patients failing to show for scheduled therapy sessions. If the problem is defined as delays in dispatching therapists, then other avenues for solving the problem (e.g., making sure the patient is in the room when therapy is needed.) may not be examined. Avoid suggesting any solutions, blaming anyone for the problem, or focusing attention on any profession.
    
2. Define the problem in terms of the patient experience. Do not define the problem in terms of the process involved. Thus, "we are having a problem with crashes in our information system" is a poor definition. While, "patients wait too long for admission" is a better definition because it allows the exploration of other causes besides the information system. The solution, for example, may end up having paper admission forms. If you define the problem in terms of the customer's experience, you automatically remove embedded solutions to the problem. Here is another example: "The competition is driving us out of business." This seems like a good statement of the problem but it is not. It is not in terms of the customer's experience. Try: "Our customer's are choosing the competition over us.
    
3. Define the problem in at least two different ways. A problem can be stated as "Few patients get admitted quickly." or as "Many patients wait long before admission." This may seem a mere play with words but it has much impact on the solutions generated. How you define the problem affects what ideas the team comes up with. The first problem statement focuses on the number of patients, the other focuses on long wait time. The solutions that come to mind may be different. Here is an example how subtle changes in a question can change the response. If you ask a person to tell you whether interest rates will be above 14 in the next year and then to estimate the rate. You get one answer. If you ask whether interest rates will be above 8 in the next year and to estimate the rate, you get an entirely different answer. Leading questions confuse everyone, even some of the most experienced people. This example shows how a subtle change in a question can lead to a major change in the response. Likewise a subtle change in the problem statement can lead to examination of entirely new set of solutions.
    
4.  Do not blame anyone.  State the problem in ways that do not blame any specific group or individual employees.  Here is an example of a poorly defined problem because it blames a specific person:  "The admission process did not work because the computer if often not working and the IT people are late in fixing it."  This statement blames the IT department for why admission is not going more smoothly.  This may be true but would force endless hours of frustrations and debate among the IT and other departments, each blaming why computers fail.  Here is another poor example:  "The problem in our clinic is that the doctor comes in too late."  This statement is blaming the doctor for the situation in the clinic.  This may be true but it is not a productive way of stating the problem because it makes the people who are blamed more defensive.  An alternative way is to state the patient's experience and let the improvement team arrive at their own conclusions for why the problem is occurring.   

In addition to the above criteria, some investigators have suggested these additional two criteria:

5. Rely on data. Define the problem and show the data for the problem. Show how much the data should change for the problem to be considered successfully addressed. Verify that the problem is real. Verify that the problem is important for the organization as a whole, i.e. it will affect the organization's survival, market share, income or expense. All problems should be solved, but more important ones should be solved first.
    
6. Be specific. General statements could be best reserved for organizational goals or visions. Problems must be specific and attached to particular processes. A statement "Most of our beds are empty. We are having a low market share." is not a good problem definition as it (1) does not define the problem in terms of patient experiences, and (2) does not give enough details to focus our attention on a specific process in the organization. Compare this with "Ob-GYN patients choose another hospital for their second child and do not come back here." This is more specific and is put in terms of customer's experiences.
   

State the problems in ways that is conducive to bring about rapid change to the problem.  The above six criteria can guide you in this task.

Step 6:  Plan by Describing the Process

Teams are often told to engage in cycles of Plan, Do, Check and Act (PDCA).  A key component in planning is to describe the current process.  No problem can be solved unless it is understood.  When poor outcomes occur, we need to understand the process that leads to it.  This section describes two ways of understanding processes.  The first is known as flow charting and lists events and how they lead to one another.  The second is known as listing routines and lists events in the process sequentially as they occur.  Both approaches document the process. Both are useful for communicating the team's understanding to others. Both create a shared understanding of the process among the team members. Often team members are surprised at how much more goes into a process besides what they knew. Flow charting is a visual step that when communicated through story boards reassures employees that the team has understood the process.

Flow charting is time consuming. A lot more than people believe. Part of the problem is that processes are complicated and charting them takes time. Another part is that team members each have a different picture of the process and they need to exchange their views about the process. The literature on group effectiveness can be used to reduce the time it takes to create a process chart. Here are the steps for flow charting a process.

1. Ask each team member to individually construct a flow chart of the process. The literature on group processes shows that when individuals work on ideas before bringing them to the group two things happen. First, ideas do not get to be evaluated prematurely as idea generation and evaluation are separated. Second, ideas are judged on their merit not based on who said what. Here are some guidelines about creating charts for individual team members.
   1. Use common notations. Show a step in the process as a box and show a decision in the process as a diamond.
      Break the chart into an overview and several details of specific processes.
   2. It is not possible to anticipate all possibilities. Keep the flow chart to 80-90% of events in the process.
   3. Chart what is the process and not what it should be or how it was supposed to be. Charting what the process should be introduces new areas of disagreement.
      
2. The group facilitator takes the input from individual team members and builds one process chart that reflects all of the ideas presented using the terminology of the team members. If you do not have a group facilitator, you should ask each team member to put his ideas on stick-on pads and during the first part of the meeting attempt to arrive at a consensus on the process flow.
3. The group facilitator presents the integrated charts as his/her poor attempt at constructing a flow chart and asks for revisions. The idea is to separate the idea from who generated it so that ideas will be judged based on their merits and not personalities involved. Also, data shows that group discussion at this time helps clarify many issues and in the absence of the group discussion the quality of the chart will suffer.
4. Discuss parts of the chart. Move along from part to part till all segments are discussed. Do not force consensus. Accept that there may be genuine disagreements about what is the process.
5. Post the chart to the story board. This makes sure that others can comment on the chart and correct obvious deficiencies. In addition, it will serve as a notice of things to come. It creates expectations. It helps prepare employees to be receptive to the recommendations of the team. Employees are more likely to accept a recommendation when they have a sense that the process was understood before solutions were proposed.

An alternative to flow charting is to make lists of periodic events and work routines.  Such lists are simpler to make but do not have a visual component.  Despite this shortcoming, such lists may be just as useful in understanding a process.  They are especially helpful in focusing the group's attention on repetitive tasks and work norms.    Periodic lists are based on the principle that any system or process is best understood in terms of its “steady states;” that is in terms of events that keep recurring.  Work is not a random heap of events.  Some events reoccur and are referred to as routines.  System Analysts refer to these reoccurring events as the “steady state” of the system. Systems are changed by changing the steady state of the system. By listing periodic events, a person can see the steady state for his or her work.  The focus shifts from fringe or rare events to central and repetitive elements of a work process.  The focus shifts to the small percent of activities that describe most of the observed outcomes.  By listing periodic events, the work process and structure is revealed.  There are many recurring events at work.  Any given work process, starts with employees coming to work and ends with them leaving.  In between patients arrive, information is exchanged, reports are made, meetings are kept, and numerous other activities are accomplished.  The purpose of listing work routines to identify the key activities that occur within a process. The first step is to list the periodic events.  It is not that non-routine events do not matter, they do; but the impact of routines events is by definition more frequent.  If routine events can be understood, a big part of work process is understood.  In order to list periodic events, the most useful tool is to follow a patient through the process and list discrete events that happen.   Listing routines is easy because it lists events in the sequence they occur.  In contrast flow charts list events in the way they influence each other, which may not be the sequence they occur.

The exercise of listing routines can be more difficult than it appears.  Some activities, like answer phone calls from patients, seem to follow clear patterns.  Patients tend to call more on Monday mornings.  Frequency of calls drops around meal time.  Other activities, like disputes among employees, are not so typical and may not necessarily reoccur with a clear frequency.  It is important to include all periodic events, even if they do not always occur at the same frequency.  For activities with variable periods, record the average time of reoccurrence.  This exercise is difficult because the variability in process activities must be distilled and ignored.  We acknowledge that events do not necessarily occur at fixed intervals.  This makes the task of recognizing what is routine and what is rare one-time event difficult.  Even more difficult is identifying events that occur with irregular frequencies.  But the benefit is that when the exercise is finished, a person should be able to understand the work process much better.   The steps in constructing a list of periodic events are as follows:

1. Identify work process.  Label the process and define its boundaries.
2. Walk with several patients through the process and make a list of routines and less frequent events within the process.  Form►
3. Check the depth of the list.  It is not helpful to list very broad events (e.g. patients show, providers care for patients, patients leave) is a list of sorts but not very informative.  Enough details should be present that could help understand what leads to process outcomes. 
4. Check accuracy of the list.  The accuracy of the list is checked by carrying the list around and checking that events listed do occur and no other major event does occur.  Another way of checking the accuracy of the list is to share it with others who have independently observed the event.

Step 7:  Suggest Changes, Select One and Do It

A component of Plan, Do, Check and Act (PDCA) is to select a possible solution and implement it, to so called "Do Phase."  To find out what should the improvement team implement, it is important to collect ideas from each team member.  There should be an organized approach for collecting ideas, listing them and evaluating them. Often people express an idea and evaluate it immediately afterwards. Research shows that brainstorming ideas before evaluating them is more productive: more ideas are expressed and better ideas are expressed. One tool often used for collecting ideas before evaluating them is referred to as a Fishbone diagram.  In this tool ideas are listed under different categories.  Team members brainstorm major causes that can lead to the problem. Then for each main cause, they brainstorm specific causes. The list of causes of the problem is arranged like the bones of a fish. The x axis ends with the statement of the problem. Additional lines are drawn at 45 degree angle to the x axis for each additional main cause. All the causes are listed along these additional slanted lines. When many lines are drawn the picture looks like a fish bone hence the name fish bone diagram.  Figure 1 shows a Fishbone diagram where ideas for why mishaps occur are listed under four categories (training, supervision, material/equipment, and procedures):

Figure 1:  An example of Fishbone diagram

Step 8:  Check & Act

The last phase of the Plan, Do, Check and Act (PDCA) is to check that changes that have been introduced have actually improved the situation and if not act to implement other changes that could improve the situation.  Many act and decide that the improvement will follow.  They do not collect data to verify whether they have succeeded.  Or if they collect data they may just rely on their own experiences.  Often people generalize from one single experience. This is a mistake. For learning to occur, you need to look for patterns across experiences. People often do not do that. In science, we learn from mistakes. We make a hypothesis and then look for data that will prove it wrong. But, in life, we survive by avoiding mistakes. We cannot systematically look forward to making mistakes. We may learn a lot but we may not survive to take advantage of the learning. So we often avoid mistakes. This creates a problem. We are never sure if the experiences we avoided could have led us to other conclusions. Learning from one's experiences is tricky. In this regard, Russo JE, and Schoemaker PJH write in their book on Decision Traps (Doubleday, 1989):

"Learning from experience is not automatic. It requires profound skills. Experience, after all, provides only the data, not knowledge. It offers the raw ingredients for learning. And people can turn it into knowledge only when they know how to evaluate the data for what they really say.

People do not learn as easily from experience as you might expect - even intelligent highly motivated people. ... Why don't people learn from their experience? For one, the data we receive can usually be interpreted in different ways. And even when the evidence is clear enough that we should learn from it, we are naturally biased to interpret it in a way that preserves our positive image. ... Because we like to believe that we caused successful outcomes and we like to rationalize that we were not responsible when things turned out badly, most people suffer from an attrition bias that can destroy useful feedback. In short we believe that our successes are due to skill and our failures due to bad luck.

Data is needed to correct our experiences and insights. Data is also needed for communicating the problem and its solution to others. Without data there is no arbitrator among the various ideas. Different professions will claim solutions that in reality do not work to resolve the problem for the customer. In the end, data is the only way that different professions can become focused on the customer's experiences.  Gathering data is time consuming. There are short cuts.

1. One way is to sample. Sampling allows one to collect data from a sub-set of the customers and infer the experience of all customers. To sample effectively, you should choose the customers you survey randomly.
2. Another way is to rely on experts' opinions. People often say that opinions are subjective and should not be relied upon. Is this reasonable? If by subjective we mean unreliable and idiosyncratic, then the answer is "No. Opinions can be more accurate than observations made by ourselves." When expert opinions are based on (1) their direct experience of the system, (2) shared across different experts, then opinions may be quite reliable.
   

Sometimes, you just have to gather the data so that you can make your case for people outside the team.  Many proposals fail to solve the problem at hand. It is important to gather data concerning how the intervention has solved the problem. Such data can be used to alert the team that a successful solution has been found. If the data does not show that the problem has been solved, the team needs to continue examining other solutions. Pilot testing and gathering data on improvement is also useful for helping other employees believe in the team's recommendations. Learning organizations need to allow for testing new ideas, even if these ideas are subsequently discarded. Without trying, that is without accepting that you will occasionally fail, no learning can occur. Teams should decide on the solution they wish to implement. One way to do so is through the Nominal group process.  In this process team members silently generate a list of ideas.  A group facilitator collects all ideas and lists it for all to see.  Then group members rate each idea.  The group facilitator collects the ratings and displays the average rating for each idea.  Team members then discuss if certain ideas should receive higher ratings.  Following the open discussion, team members rate again and the idea with highest ratings is selected. 

To see if the ideas select actually improve the situation, it is important to implement a pilot test of the idea and collect data on whether the change is an improvement.  When data is collected, it is important to examine whether the process performance has changed over time. By examining the process over time, one examines the data before and after the intervention. One way to do so is through control charts. Control charts, especially risk adjusted control charts, are discussed in depth in subsequent lectures.   Figure 2 shows an example of a control chart.  In this chart data before and after the implementation of a change are displayed.  The red lines show upper and lower control limits.  Values that fall below or above the control limit signify a change in the process. 

Step 9:  Show and Tell and Celebrate Success

Effective change requires clear communications.  When you tell others about your efforts, you become more committed to them.  Surprisingly, when you tell others about personal improvement you also get to understand yourself better.  How do you tell, is up to you.  Some use paper and pencil diaries, others use emails, still others use slides.  Whatever you do, keep in mind that successful ideas and efforts will die and disappear if they are not communicated clearly, vividly and using multiple media. The purpose of a story board is to summarize and visually present the impact of the improvement.  It serves as a communication medium to others around you.  It also serves the project team as a documentation of their progress to date.  Story boards is a form of public reporting, there are many other mediums and methods available for reporting on an improvement effort. Story boards is also a celebration of success and in this manner it provides a positive environment for change. Here are brief steps to follow if you are constructing a story board.   Divide the story board into the following sections:

1. Title of the project or statement of the problem.  Include the project's name and list the team members.  If the information is provided publicly, as it often is, avoid using contact information.
2. Permission for display.  Include a statement from project participants whether the story board can be in public domain (e.g. the web)
3. Description of the problem.  A problem is best articulated using data and a vivid quote from the customer. In addition to displaying the customer's words or voice, also include data that documents the extent of the problem
4. Process flow chart or list of routines. Describe the current situation using either the process flow chart or a list of routines
5. Fishbone diagram or list of solutions.  List possible solutions examined and mark the solutions implemented.
6. Control chart or indications of success.  Provide data on impact of the change and display the data visually so others can understand the magnitude of the change
7. Future plans & conclusions.  

To assist you in creating a storyboard we have put together a template using Microsoft Power Point.  Download► PPS► Html►

Here is a layout of what goes where if the sections were included in one large poster:

Here are simple steps you can take to make your storyboard better:

1. Put your storyboard where you and others can see it on a daily basis.   No point in telling a story if there is no one who sees it.
2. Add sections as they become available. The idea is to generate a sense of anticipation and unfolding as the story is told.
3. Organize the story well. Put time into keeping a chronicle of what happens to the patient and how their experience has improved.
4. Write little and show more by pictures and drawings. Have fun in the design and content.
5. Include some pictures of team members working together. 
6. Leave the story board up for several months even after the change has been adopted. Data shows that post-sales activities help improve adoption of innovations.  A continued exposure to a story board will remind employees of the effort that was made and the success that was achieved.  
7. Allow for input from others. Let them write on the storyboard directly and modify it as they see fit.  People like what they participate in creating.

One way to tell your story is to narrate your presentation.  Savvy managers use media to make their points to employees through out the firm.  In doing so, they make sure that different employees hear of the process improvement as it progresses.  In narrating slides, please keep the following advice in mind:

1. Make all of your slides before starting the narration.
2. Do not use animation, it usually conflicts with narration on a machine that works at a different speed.
3. Duplicate slides that have a list of items so that each item is on a separate slide
4. Do not put too much text on slides.  Do not use full sentences, abbreviate to key phrases.
5. Once all slides are done, copy full-text sentences on top of your slides so that you can read your narration while looking at the slide.
6. Narrate all of your slides at one sitting.  Video►
7. Delete the full-text sentences that you had copied on top of the slides.
8. Distribute your narrated slides on the web, through email, or by other mediums. 

Many improvement projects fail to create a story board. Or if they do, they create the board only after the fact. This is a mistake and these projects are not taking advantage of an important communication tool.  When you make the storyboard on the first day of the project, it begins to tell that something is up.  As time goes on, it unfolds a story about what the team is up to. The climax of the story is reached when the control chart is posted showing the improvement.  Story boards are the team's public minutes.  It helps integrate the rest of the deliberations. Unfortunately, many are not comfortable with taking advantage of mass communication tools, like a storyboard.  But real lasting change requires help from others who share the environment.  Without the storyboard, others are not aware and cannot contribute to changes in the environment. 

Step 10:  Spread Improvement to Other Units

When an improvement effort has succeeded in one unit of the organization, it is important to spread the improvement to other units.  The key in accomplishing this step is to persuade other units to adopt the change by explaining the benefits of the change.  But sometimes this is not enough.  Some employees may not want to change no matter how much they will benefit from the change.  It is important to work on barriers for widespread implementation of the change.  Many projects make rational arguments, based on self interest or organization's interest (e.g. if we make this change we can save money).  This is not enough.  Adoption of improvements across organizations are more likely when the self-interest arguments are supplemented with emotional appeals.  Employees are more likely to change when they are reminded about it, feel good about the change, see others that they admire changing and adopting the new ways, and think it will help them do their work with less effort.   

What do you know?

1. List the steps in TQM.  These steps were presented under the lectures on "Leading change" and "PDCA cycle" combined.  For the steps were specific tools have been suggested, list the tools.  At a minimum list the following tools:  problem definition criteria, control chart, storyboard, brainstorming, flow chart, Fish-bone diagram, and Nominal Group Process (which is a group processes for delaying evaluation of ideas).  The purpose of this question is to help you see the big picture. Be brief but show me that you know each step and the principle tool used in it.
2. Two aspect of TQM are often missing in improvement projects: (1) data on improvements made and their variation, (2) story board. Speculate why is the case. Why is it so difficult to do these steps? Does the omission of these two components matter? If you were running the TQM resource group, would you remedy this situation and how would you do it.
3. Have you heard a poorly defined problem? A problem that does not fit the advice given in this lecture?   State the problem you have heard.
4. Please read the lecture and note the advice given about problem definition before you answer this question. Correct the statement given in response to question 3.  List four criteria from the reading that can be used to evaluate problem statements, then revise the above statement to meet all four criteria.

Please send an email to your instructor with your responses to the above questions.    Make sure that the email subject line includes the course number, topic name and your name, otherwise it will not get to the right place.  For example, subject line could be:  "Joe Smith from HAP 586 responses to questions in lecture on PDCA cycles"   If you wish to receive a receipt that the instructor has received your email, you may request the receipt from your email program.  Please respond to all of the questions within the same email.  Keep a copy of all your emails to the instructor till the end of the semester.  Email►

Analyze Data

To help you get ready for a number of control chart assignments coming up later in the course, we ask that you become more proficient in using Excel. 

1. In cells A1, through A4 enter the following data:  25, 50, 75 and 100.  Calculate the sum, count, standard deviation and average of the data.  To accomplish this task you need to use the functions =sum, =count, =stddev and =average.

Email your instructor and obtain his email.  Then send an email to him with your Excel file attached.  For full credit of your work, in the subject line include the course number and your name.  For example, subject line could be:  "Joe Smith from HAP 586 analysis of data in lecture on PDCA cycles"   Please submit one file.  Please note that all cell values must be calculated using a formula from the data.  Do not enter values in any calculated cells.  Calculate each cell using Excel formulas.  Keep a copy of all assignments till end of semester.  Email►

Presentations

To assist you in reviewing the material in this lecture, please see:

• Lecture on cycles of change.  Listen► Slides►
• Lecture on typical improvement.   Read► Listen►  Slides► 

Narrated lectures require use of Flash. 

Examples

• Read about recent applications of continuous quality improvements in health care.  More► Still more►  
• Conduct a pre-arranged search of Medline database for examples of quality improvement.  PubMed►
• Researchers solicited nominations for successful examples of clinical quality improvement teams from quality leaders in the network.  After collecting data from the nominees (e.g., team reports, storyboards, charts, graphs, and bibliographies), the researchers developed a project report with 15 case studies. This report, after expert review, is now available to the public.  More►
• Other examples of use of Plan, Do, Check and Act (PDCA) model can be found in published literature.  More►  

More

1. A Fishbone diagram template.  More►
2. What is the difference between six sigma and the steps presented here? More►
3. As quality improves market share increases and cost of production drops.  More► 
4. Tutorial on creating a storyboard. More► Bibliography►  
5. Alternatives to continuous quality improvement exist.  Bankruptcy► Re-engineering► Organizational Development► 
6. Different ways of implementing continuous quality improvement. Deming► Juran► Crosby► Six Sigma► Lean Thinking ► 
7. Comparison of three planning methods.  More► 

This page is part of the course on Quality, the lecture on PDCA Cycles.  It was last edited on 05/12/2003 by Farrokh Alemi, Ph.D.  © Copyright protected.