Good processes and systems have ways designed into them to identify when a problem occurs, and ensure it gets the right rigor of problem-solving. A model like Art Smalley’s can be helpful here.
Each and every process should go through the following steps:
- Define those problems that should be escalated and those that should not. Everyone working in a process should have the same definition of what is a problem. Often times we end up with a hierarchy of issues that are solved within the process – Level 1 – and those processes that go to a root cause process (deviation/CAPA) – level 2.
- Identify the ways to notice a problem. Make the work as visual as possible so it is easier to detect the problem.
- Define the escalation method. There should be one clear way to surface a problem. There are many ways to create a signal, but it should be simple, timely, and very clear.
These three elements make up the request for help.
The next two steps make up the response to that request.
- Who is the right person to respond? Supervisor? Area management? Process Owner? Quality?
- How does the individual respond, and most importantly when? This should be standardized so the other end of that help chain is not wondering whether, when, and in what form that help is going to arrive.
In order for this to work, it is important to identify clear ownership of the problem. There always must be one person clearly accountable, even if only responsible for bits, so they can push the problem forward.
It is easy for problem-solving to stall. So make sure progress is transparent. Knowing what is being worked on, and what is not, is critical.
Prioritization is key. Not every problem needs solving so have a mechanism to ensure the right problems are being solved in the process.

5 thoughts on “Design Problem Solving into the Process”