Using Control Charts to Identify Product Process Problems

Project managers use control charts to spot production process problems before they spin out of control. On a control chart, production data is plotted and analyzed for specific trends. Control charts are used more as a preventive measure rather than for detection or rejection of quality problems. This is extremely useful since it is cheaper to prevent mistakes than to correct them.

Control charts compare quality, cost, and time issues to an established norm. They indicate permissible behavior so that aberrations are easy to identify. Analysis of control charts determines whether a process is stable or whether corrective action needs to be taken.

Control charts can also help determine sources of variation. Variation is the range the observations fall around the process mean or average. Variation is different for every product or process since each has different characteristics.

• Common cause variation - is random variation common to any process. This type of variation requires management decisions to change the basic processes. Common cause variation is caused by chance and requires no corrections.
• Special cause variation - happens at the operational, or production, level. This variation is indicated by exceeding a control limit or a persistent trend towards the limit. Special causes exist when the variation in a process exceeds allowable standards. Corrective action is then required.

Variation is also categorized by time.

• Short-term variation - can be caused by changes in suppliers or workers' performance.
• Long-term variation - occurs in cases of tool wear, environmental changes, or increased administrative control.

There are two types of control charts classified by the type of data they collect. Variable control charts are used with continuous data in which all numerical values are possible. Variable charts are useful when measurements from a process are variable such as diameters, electrical output, or chemical concentrations.

Attribute control charts are used with discrete data, or when data can only have a certain value, or range, such as "1" for "yes" and "2" for "no" in a conformance test. Attribute charts analyze data such as conforming/non-conforming, pass/fail, go/no go, or yes/no measurements.

The use of these various charts depends on what type of quality measurement is desired. The most common type is the X bar chart, or process average chart.

Limits on a control chart are often called the three-sigma limit because most companies operate within the 3 sigma limit. In a normal distribution, 99.73 percent of the measurements lie within X bar ± 3s, or within the UCL and LCL. Some companies now employ a six-sigma limit in their quality control. This allows only 2 defects per billion. This exactness in quality is so expensive that it is only possible over very large production runs.

The high figure indicates a high degree of variation because more of the observations fall away from the average. Therefore, the taller the curve shape, or the bell curve, the lower the standard deviation will be.

Control charts can be interpreted in many ways depending on their patterns and line shifts. Experience is the greatest aid to understanding a chart. Control charts tell when to look for trouble but not where the cause lies. Control charts also indicate when to leave a process alone. Variation can be unnecessarily introduced by an operator trying to fine-tune a machine to near perfection, when the control chart indicates the operator could leave the process alone. Charts are interpreted by runs, trends, periodicity, and hugging.

Quality control inspectors also use the Rule of Seven to determine if a process is out of control. If seven or more consecutive observations are found to be on one side of the mean, then it is out of control. The reason it is said to be out of control is that there is only a 1.56 percent statistical chance of random variation that the run of seven would fall on one side of the mean.

One of the most useful quality control tasks is ensuring a process is in control, by identifying the existence of a problem. Control charts are a valuable tool in determining whether or not a project or process is in control. To be able to read control charts, you need to be familiar with the different control chart types and their components, and the various methods of interpretation.

Project Product Descriptions and Scope Statements

The product description document, which is an important input to project quality planning, does just what you would expect—it describes the product. Specifically, it describes the product characteristics a project will create. It contains technical information as well as other issues that affect quality planning.

At the beginning of a project, the product description document will be vague. However, as the project evolves and the product characteristics become more complicated, more details will be added to the product description. Some points to keep in mind about the product description documents are listed below.

• When a supplier does work under contract for a client, the initial product description is provided by the client.
• The product description needs enough detail to support project planning in later stages.
• The product description should state the relationship between the product or service and the business need, opportunity, or problem that initiated the project.

Throughout the project, the product description document will be modified to add the details that were unknown when the project first began. This process assists with the development of the quality outputs.

Parts of the product description may be included in the scope statement, which is another important input to quality planning. Scope statements include information on project deliverables and objectives. Specifically, a scope statement is a description of what the stakeholders want. Details about the scope statement are provided below.

• The scope statement is a written source for making decisions later on in the project.
• The scope statement confirms that the stakeholders all have the same expectations of the project.
• The scope statement is a written source for making decisions later on in the project.
• The scope statement confirms that the stakeholders all have the same expectations of the project.

Just like the product description, the scope statement may need to be revised as the project changes. A scope statement should refer to, or include a description of, the project justification, project product, project deliverables, and project objectives. These four elements of the scope statement are described below.

• Project justification. The project justification can be taken directly from the product description document. It states the business need that initiated the project.
• Project product. This is the actual product description. This portion of the scope statement can be taken from the product description document.
• Project deliverables. The project is considered complete when all the products that make up the project are delivered. If you discover that something has been excluded, you should immediately add it to the scope statement.
• Project objectives. These are the criteria that mark the success of a project. Project objectives detail costs, schedules, and quality measures.

A clear product description and scope statement confirm that everyone involved in a project has the same expectations. You have to know what your customers really want. Your project's success depends on it.