How wonderful would it be to design a new product or process flawlessly and on time? But apparently we live in a different reality. One where problems and drawbacks always arise to prevent us hitting our deadlines within budget. Problems such as unexpected issues in the design or the inability to scale up to mass production due to quality issues in production.
This article demonstrates the power of statistical structuring in the context of such problems. The main focus is on discovering the root cause. Once this has been identified, solving the problem is generally straightforward.
A very natural way to deal with a problem is to quickly form an hypothesis for the root cause and then take action based on that hypothesis.But what if our hypothesis is wrong? Do we formulate another hypothesis and start the process all over again?
Beyond the quick-fix
This natural problem-solving strategy is often also applied in product development. Problems can vary from performance issues, to low yield rates, to other completely unexpected phenomena. With the best of intentions, one or multiple quick-fixes are considered and applied. But then reality strikes: the issue cannot be solved easily. What now?
Good practice is to prevent problems as early as possible in the development process. DfSS is a well-developed methodology that puts the focus on the early detection of problems, when constrictions and the cost of making changes are both still relatively low. At the very least, the most significant risks need to be identified and actions taken to mitigate them. Nonetheless, whatever we do we can’t prevent every problem from occurring. So we need to have good strategies for dealing with them when they do inevitably arise.
Resisting the pressure
Nearly all problems in development can be considered from the same viewpoint. We need to discover and understand in sufficient detail what precisely the problem is — discover its root cause. Once the root cause has been identified, the actual solution to a problem can often be a relatively straightforward part of the problem-solving process.
Seen from this perspective, solving a problem can almost seem easy. But there are other factors at play: the ever-increasing development speed; the panic amongst key stakeholders; the pressure to pass milestones. It takes a strong character to defend a statistical structuring approach against the demand to jump to conclusions.
So what does a statistical structuring approach look like?
First and foremost, think before taking any action. Intuitively, we are considering all sorts of possible causes. Some high level, others very detailed. What’s missing is the link and the hierarchy between those various potential causes. The goal of statistical structuring is to create an explicit model on paper that captures the thoughts of people.
Creating such an explicit model is no trivial task. An infinite number can be created, only some of which are useful. The very process of creating an explicit model already leads to a deeper insight into the issue and is therefore valuable in itself. Moreover, when every element at the highest level of the model can be quantified, and has the potential to be influenced, the model is very strong and the perfect starting point for quickly pin-pointing the root cause of a problem.
One problem that often occurs during scale-up is too much variation on critical-to-quality parameters. The natural approach would be to assume that one specific aspect is causing the high variation. So this aspect is measured and variation duly discovered. The product design is then modified to be more robust in respect of this specific aspect. New products are made, tests done, an analysis executed. Then reality strikes again: the problem is still there, and apparently the specific aspect, now dealt with, was not the main cause after all. So only one minor aspect of the variation in the critical-to-quality parameters has been addressed.
The statistical structuring approach in this example has a generic structure that is more widely applicable. Unfortunately, for other types of problems such a generic structure does not usually exist.
At the highest level, it is important to distinguish different types of sources of spread. When sufficient data is available this step can be taken quickly. Otherwise data has to be gathered to determine the correct focus area.
Suppose that in this case 80% of the problem is caused by a difference between production lines. We then go a level deeper in the tree.
For this next level in the tree, we can check how the different branches scored for the previous tests. This gives some insight into where the problem might lie. This is a good moment to set up a smart test: a test designed to rule out different branches with the aim of going another level deeper.
In many cases, the third level in the tree will lead to a test that can pinpoint the root cause sufficiently accurately. Once identified, the product and/or process can be modified to solve the scale-up issue. And your problem is solved. Really solved.