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

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

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group .   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service than toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service

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