Skip to main content

Control Charts

In the 1920’s while working at ATT Bell labs, Dr Walter Shewhart (mentor of W Edwards Deming) sought a way to improve telephone transmission systems. Seeking to reduce variations and failures, on May 16, 1924 Dr Shewhart wrote an internal memo introducing the concept of the control chart [Wikipedia]. Today the control chart (AKA process quality control chart or Shewhart chart) has become the standard statistical tool for finding variation that lead to continual improvement. As with other continual improvement tools, the control chart can be understood in a short time, yet takes a lifetime to master as a truly powerful tool for statistical and incremental improvements.

The control chart is a tool that tells us whether a process or system is in a state of statistical control. The state of statistical control is one in which a minimum or acceptable amount of variation is acceptable while still meeting the desired output of the process. Shewhart recognized that every process and system has a sort of natural “wobble” or variation. Nothing follows a strict straight path without any variance or exceptions. There are always exceptions or variations in a process. The goal of process improvement then is not to try to remove all variances or adhere to a perfect ideal, rather to eliminate the variances that are outside of statistical control.
Reducing variances involves plotting statistical data along a mean and identifying Upper and Lower Control Limits that represent the acceptable level of variation within the process or system. This plot of data done over time is known as a control chart. By looking for data points that fall outside the acceptable or established limits we can identify those situations where something unusual or out control took place. Data points inside the established control limits are considered to be part of the natural “ebb and flow” or “wobble” of a system. Time and effort should be spent eliminating the causes (called “special causes” by Shewhart) of the data points outside the established limits. Time and effort should not be spent on the points inside the limits since these are the results of “normal causes” or the natural variation of a system or process.
Perhaps one of the most important points to remember about control charts and statistical control is that the plot or results of the chart cannot be determined before actually conducting a process and gathering data points. This means we cannot set an arbitrary target and expect the system or process to conform to the target. We must first perform the process, gather the data, plot it and see the natural mean and limits of the current process. If we do not think the results are acceptable we must change the process and gather new data and create a new chart to reflect the new process. The old chart can no longer serve for an improved or changed process. In other words control charts reflect the process or system rather than directing or steering the process or system. This concept was taken by Dr Deming as he went forth to talk about statistical control in the form of the Plan-Do-Check-Act cycle. Checking (using control charts) occurs after Doing of the process, not before.
Control charts are one of the most important and powerful tools we have for Continual Service Improvement. Spend some time learning about these tools and you will eap the benefit for your organization.


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th

The ITIL Maturity Model

Most organizations, especially service management organizations, strive to improve themselves. For those of us leveraging the ITIL® best practices, continual improvement is part of our DNA. We are constantly evaluating our organizations and looking for ways to improve. To aid in our improvement goals and underscore one of the major components of the ITIL Service Value System , Continual Improvement .   AXELOS has updated the ITIL Maturity Model and is offering new ITIL Assessment services. This will enable organizations to conduct evaluations and establish baselines to facilitate a continual improvement program. A while back I wrote an article on the importance of conducting an assessment . I explained the need to understand where you are before you can achieve your improvement goals. Understanding where you are deficient, how significant gaps are from your maturity objectives, and prioritizing which areas to focus on first are key to successfully improving. One method many organi

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem