“A careless operator caused another delay” might sound like a problem statement, but in truth, it isn’t. By saying an operator was careless, you are already stating the result of an investigation. You’re identifying a party (the operator), stating an assumption (carelessness) and you’ve left out any data that would help you investigate. A helpful problem statement says what the desired result should have been, what the actual result was, and the circumstances under which the actual result was observed.
Let’s say that service requests should have been entered into a tracking system before the day’s business was done. But during one week, nine service requests were entered the next day. We might conclude that the team members didn’t care, or that the software was difficult to use. But we’d be jumping to conclusions. Those might have been contributing factors, but they weren’t proved yet. In fact, the facts are that nine requests were entered after the required time during a stated timeframe. This is more useful because it has been stated in detail: the process or process step, the quality requirement, the actual outcome, the place and time the problem occurred and evidence that you have to back up your claim.
Do not add details because it is easy to do so; add details because they describe the gap between the desired and actual outcome. The phrase “careless” (or “lazy,” “untrained,” “inattentive,” or “negligent”) brings in blame, and words like “likely due to” (or “probably the fault of,” “clearly caused by” or “because the system is too bad”) add speculation. You want to eliminate these qualifiers from your first statement. You are not saying you don’t know what is wrong, but just saying there may be several factors involved: a delayed action transfer may be caused by a vague responsibility, missing information, too high demand for a specific task, a confusing work instruction, a breakdown in a technology or several factors together. It is premature to decide which one is correct, as that could bias your findings.
The best way to practice writing a statement is to take a common problem (you’ve probably come across one many times) in the system you know best and try to rewrite it into an unblamed and unbiased statement. Change “orders are often filled improperly” to an observation, such as “four of 20 orders checked on Tuesday had one missing item shown in the pick list,” and then separate the statement from any explanations you might have to justify it. Your observation is in the pick list and in your findings from the check sheet; your speculations are in an employee who was rushing and the pick list didn’t clearly say to check every item, and maybe the supplies weren’t in the right place.
Make sure you have only one problem, even though the problem might be related to others. For example, if you include “completion late, wrong information in the service report, damaged product and a customer’s complaint,” you might be opening the door to five or more problem-solving efforts. This might seem efficient to some, but in truth each problem has its own expected result, actual result and evidence of actual. By limiting the statement to what needs to be fixed now, you make it easier to select the appropriate measure, create the appropriate cause-and-effect diagram, and take the appropriate corrective actions that can later be monitored.
Read your problem statement after you write it to see what you have left out. If someone has no knowledge of the event, would your problem statement tell them what the desired result should have been, what the actual result was, and how you measured it? If so, you can stop there. It is a useful problem statement. You haven’t yet told them who caused the problem and what they should do to correct it. That may come in a subsequent step. It is a good thing you have left those details out.