c Chart: Hold the Gain After the Project Team Moves On

The c Chart monitors the count of defects per constant inspection unit to detect changes in defect frequency. That is the whole job. You count how many things went wrong inside a fixed unit of work, you plot that count over time, and the chart tells you whether the pattern you see is ordinary variation or a real change.

The word constant matters. The inspection unit has to stay the same size from one period to the next. One batch, one shift, one hundred metres of cable, one invoice run of the same volume. If the size of the unit moves around, a c Chart is the wrong tool and you want a chart that handles variable opportunity instead.

In RDMAICS, the c Chart earns its keep in Control. Measure and Analyse told you where the defects came from. Improve changed something. Control is where you prove the change held. The chart becomes the handover artefact. It is the thing you leave behind when the project team disbands and the process owner takes the process back.

Ci Flow ships the c Chart with a small sample dataset, and this guide is built entirely around it so you can follow along inside the tool. The data is fictional. It was written to demonstrate the tool and it does not describe any real organisation.

The scenario is labelled Delivery defects per batch. Twelve consecutive days are recorded. Each day is one observation and each observation carries a defect count for one batch. The days alternate between two strata, Lunch shift and Dinner shift, so there are six of each.

The counts run Day 1 at 3, Day 2 at 4, Day 3 at 5, Day 4 at 3, Day 5 at 6, Day 6 at 4, Day 7 at 12, Day 8 at 5, Day 9 at 4, Day 10 at 3, Day 11 at 5 and Day 12 at 4. Read that list and one value stands out. Day 7 recorded 12 defects while every other day sat between 3 and 6. The purpose of the chart is to decide whether that difference is worth acting on.

The input table has four columns and each one has a job. Observation or period is the label for the point in time. In the sample this is Day 1 through Day 12. Keep these in chronological order, because a control chart reads sequence as meaning. Sorting by value destroys the chart.

Defect counts per inspection unit is the only column the arithmetic uses. It must be a whole number count of defects, not a percentage and not a rate you have already adjusted. The sample column holds the twelve counts listed above.

Group or stratum lets you tag each point. The sample tags every point as either Lunch shift or Dinner shift. The stratum does not change the limits. It is there so you can see whether signals cluster in one part of the process. Series or scenario names the dataset, which in the sample is Delivery defects per batch. If you are running several processes through the tool, this is how you keep them apart.

Before you type anything, write down your definition of a defect and your definition of the inspection unit. If the next person counts differently from you, the chart stops being comparable and the control plan quietly fails.

From those twelve points the tool returns a centre line of 4.8333, which is the average defect count per batch across the period. The upper limit is 11.4288 and the lower limit is 0. Sigma is 2.1985. The point count is 12 and the out of control count is 1.

The lower limit sitting at 0 is normal for count data with a modest average. Counts cannot go negative, so the calculation floors there. That means this chart cannot signal an improvement through the lower limit. It can only signal deterioration through the upper limit, or through the pattern rules.

The signals table reports one entry. Point 7, value 12, triggered rule 1, one point beyond 3 sigma. The explanation given is that a single reading this far out is almost never chance. Day 7 at 12 sits above the upper limit of 11.4288, so the chart is telling you something specific happened on that day rather than the process simply wandering.

The tool applies all eight Nelson rules to the main chart. A moving range or dispersion chart is tested only for points outside its limits, because those values are related to each other by construction. A note under the chart also reminds you that the limits were calculated from all twelve points, and that you can set a baseline to judge later data against an earlier period. The tool also offers an AI review that explains the result in plain language if you want a second read.

The first decision is whether to act at all. Eleven of the twelve points sit inside the limits. If you had reacted to Day 5 at 6 because it was higher than Day 4 at 3, you would have been chasing noise. The chart gives the process owner permission to leave the process alone most of the time, which is the quieter half of Control and the half people skip.

The second decision is where to investigate. Day 7 is flagged, so the investigation has a date, a batch and a shift attached to it. The stratum column says Day 7 was a Lunch shift. That is a starting point for a conversation, not a conclusion, because the other Lunch shift days recorded 3, 5, 6, 4 and 5.

The third decision is the baseline. Once the Improve phase change has settled, you freeze the limits from that settled period and judge everything after it against those limits. That converts the chart from a description of history into a live alarm. The tool supports exactly this through the baseline setting noted under the chart.

The fourth decision is handover. The control plan should say who looks at the chart, how often, and what happens when a signal appears. Without that sentence, the chart is a picture. With it, the chart is a process.

The most frequent error is letting the inspection unit drift. If batch size grows, defect counts grow with it and the chart will signal a change that is really a change in opportunity, not in quality. Check the unit definition every time the process changes.

The second error is recalculating limits every time new data arrives. If you keep folding new points into the centre line, a slow deterioration gets absorbed into the average and the chart never complains. Freeze the limits at a baseline and leave them alone until the process is deliberately changed.

The third error is removing the signal because it is inconvenient. Day 7 at 12 raises the centre line and widens the limits. Deleting it would make the chart look calmer and would hide the one piece of information the chart actually found. Investigate the point first. Only consider exclusion when you have a documented special cause and you record the exclusion.

The fourth error is reading the stratum tags as causes. Six Lunch shift points and six Dinner shift points is a small sample. The tags help you look. They do not prove anything on their own.

The chart does not tell you why Day 7 recorded 12 defects. It tells you that 12 is outside what this process normally produces. The cause lives in the gemba, the logs and the people who were there. The chart buys the investigation its justification and nothing more.

The chart does not tell you whether 4.8333 defects per batch is acceptable. A centre line is a description of current behaviour, not a target. If the customer requirement is two defects per batch, this process is stable and failing at the same time. Control charts speak about stability. They say nothing about specification.

The chart cannot confirm an improvement when the lower limit is 0. With these limits there is no point low enough to break the floor. To detect a reduction you would rely on the pattern rules, such as a run below the centre line, or you would set a baseline from the earlier period and watch the later data against it.

Twelve points is enough to demonstrate the tool. It is thin for setting durable limits. Expect the centre line and the limits to move as you gather more periods, and plan to lock a baseline once you have a stretch of data you trust. Finally, the chart only works if someone keeps feeding it. The gain holds because the counting continues, not because the chart exists.