# Given a control chart that shows the mean and upper/lower control limits, how do I tell if the cause of out of control points is assignable or not?

I am given 15 points. The control limits are at +/- 3 $\sigma$. Points 1, 4, 5, 6, 7, 8, 9, 10, 11, 13, and 15 fall within the control limits. Points 2, 3, 12, and 14 are outside of the control limits, with 2 being below the lower control limit and 3, 12, and 14 being above the upper control limit.

How do I know if points 2, 3, 12, and 14 are out of control caused by chance causes or caused by assignable causes?

• If anyone wants me to, I can produce a similar graph as the one I was given and link to it here. This question came from a practice IEEE Certified Software Development Associate exam - the correct answer is apparently "out of control caused by assignable causes". Unfortunately, I don't know why that's the answer - I said "out of control caused by chance causes" since there aren't a series of points out of control. Nov 26, 2010 at 14:14
• Yes, the graph would be useful. As stated in my answer, the look of the chart is important as well, not only which points are outside the control limits. Nov 26, 2010 at 16:12
• I just added a picture of the question, graph included. I marked the correct answer as well. Nov 26, 2010 at 16:27

Yes, you should find and assignable cause for every point that's outside the limits. But things are a little more complicated.

First you have to determine if the process is in control, since a control chart is meaningless when the process is out of control. Nearly 1/4 of your observations falling outside the limits is a strong sign that the process may be out of control. Looking at the chart would be useful to determine whether the process is under control or not.

Besides falling outside the control limits, there are other potential reasons for needing to look for assignable causes for certain observations. For example, if you have several observations in a row falling on the same side of the mean -- especially if they're near the control limit -- they may need to assigned a special cause.

I might be able to be more specific if you'd post the chart itself.

If you want to learn more about control charts, SPC Press has a number of useful free resources. You might also want to look at this book: it's short, concise and very informative.

(Edit:)

I assumed we were talking about real-world data, not an exam question. In this case, the correct answer really is the first one: the points outside the control limits are (probably) caused by assignable causes.

The exam is a little sloppy in its terminology, though: you can't actually tell with 100% certainty that the points outside the control limits are not caused by chance. You can only say that there is a 99.7% probability that a particular point outside the limits is not caused by chance.

• I added a picture that includes the original question and graph. Nov 26, 2010 at 16:28

My understanding of control charts is a little bit different... After the first signal at observation 2, wouldn't the process would be stopped and checked for problems, and then restarted?

In any case, you could use a p-value argument. The probability of observing 4 or more observations (out of 15) beyond their control limits is VERY tiny if the process is actually in control. Let's say the probability of an observation going outside of the control limits while the process is actually in control is about 0.01 (this exact probability depends on the in control distribution of the data), so if the process is in control, we expect a false alarm (ie out of control signal caused by random chance) every 100 observations or so. The probability of observing 4 or more out of control signals (out of 15) while the process is in control is about 0.000012, so it's very unlikely that the signals are due to random chance.

While an actual diagnosis would require you to look at the chart and possibly actually investigate the physical process, because the out of control points are both below and above the control limits, I'm betting there was a scale shift (i.e. increase in variance.)

• I've only taken one course in Engineering Stats, but I seem to remember that you don't stop the process until you have 3 (maybe 2) points that are out of control. However, your second argument makes sense, where a process truly in control wouldn't have 4/15 observations outside of +/- 3 std dev. Unfortunately, I don't have my EngStats book at home to verify that. At least it's plausible. +1 for now, until I can research this some more. But at least it's a starting point. Nov 26, 2010 at 16:07
• (+1) Good answer. Alternatively, assuming the standard deviation was previously estimated from a very long series of data, one might wonder about the normality of the distribution. Furthermore, these 15 points were not likely a random selection: they must have been chosen as a short sequence in which an unusual number of OOC measurements appeared. The former suggests the chance of a single OOC may be quite a bit greater than 0.01 while the latter indicates that the binomial calculation is misleading. After all, it is virtually certain that such a sequence will eventually occur by chance!
– whuber
Nov 26, 2010 at 16:11
• I added a picture that includes the original question and graph. Nov 26, 2010 at 16:28
• @Thomas It still looks like a bad question to me. It attempts to measure two concepts (how to read a control chart and the distinction between "assignable" and "chance" causes), which is one mistake, and it punishes the thoughtful test-taker who knows that much more information is necessary to interpret the OOC points than is given here, which is the more egregious mistake.
– whuber
Nov 26, 2010 at 17:40

I don't really agree with the statement:

"Apparently, if you cross either the UCL or LCL, there has to be an assignable cause"

To keep things simple, if your in control distribution is N(0,1), then you will still obtain false alarms once every 370 observations, on average, using a UCL of 3 and LCL of -3. When the chart signals, the process needs to be investigated. Only then can a reason for the signal be assigned (ie process change or random error.) Setting the UCL and LCL requires the user to balance the desired false alarm/missed detection rate (analogous to the Type I/Type II error trade off in hypothesis testing.)

You can also wait until a few signals to actually stop and investigate the process, but in that case, you may detect the shift too late if it really occurred at the first signal. Again, you can't have something for nothing and the user must use their judgment to decide on how to set up the control chart and monitor the process.

I found something interesting tucked away in a study document from the IEEE geared toward this exam:

• Data points falling within the UCL and LCL range are considered to be in control and caused by chance causes.
• Outliers falling above the UCL or below the LCL are considered to be out of control and caused by assignable causes.
• If a number of points fall systematically above or below the mean (but are within the UCL and LCL) this may indicate a nonrandom out-of-control state.
• The goal of a control chart is to detect out-of-control states quickly.
• The chart, alone, will not indicate the root causes of the event, but it will provide investigative leads.

Apparently, if you cross either the UCL or LCL, there has to be an assignable cause.

This makes sense, given the Wikipedia definition of characteristics of assignable (special) cause:

• New, unanticipated, emergent or previously neglected phenomena within the system;
• Variation inherently unpredictable, even probabilistically;
• Variation outside the historical experience base; and
• Evidence of some inherent change in the system or our knowledge of it.
• OK, thanks for the clarification: it resolves your original question. "Assignable" seems to mean "not attributable to chance," which is consistent with the dichotomy in the question. What I am struggling with is the assumption that OOC events can not be due to chance. This is clearly mistaken, as @HairyBeast has noted. Another striking aspect of the study document is how informal, unquantitative, and ad hoc it seems, as in "a number of points" (how many?) and "systematically" (meaning what?). It seems to refer to CUSUM or runs charts without providing appropriate guidelines for their use.
– whuber
Nov 26, 2010 at 21:15
• @whuber I agree fully. Considering this is published and maintained by the IEEE, I expected a whole lot better. I'm just wondering if they are handwaving a bunch of stuff because it's a software engineering certification, and they don't want to get in too much depth in other things. But that's no excuse for some of this confusion. Nov 26, 2010 at 21:30