“Orders are often wrong” is a statement, not a problem. It does not tell you which process, which time frame, which type of defect, or any supporting evidence. A better problem statement would read, “Eight out of forty of the orders were processed with incorrect addresses at our weekly review and were sent back to have the record corrected, following manual data entry.” Both statements identify an issue that is bothering us; only the second is something the team can work with.
Before jumping to the root cause of the problem, develop your problem statement in four distinct parts by identifying “what,” “where,” “when” and “impact.” Pick a process you know well, such as “missing data on a form.” If you were to write “forms are missing information,” be specific and describe the exact information that is missing, where the missing information was discovered in the process, the period under review, and what was impeded by the missing information. You will be working with observable data, not frustration or a preconceived idea.
The “what” should be the defect or deviation or nonconformity; do not describe the cause. It is not “employees forgot to enter data,” it is “the approval field is blank.” To forget is already a suspected cause; it may or may not be the real cause. The condition that has been confirmed is the blank field. Apply similar reasoning to terms such as “poor quality,” “improper processing” or “system down.” Describe it as something another person could verify, from a record, a sample, an inspection or an eye-witness observation.
The “where” refers to a physical location, process step, computer screen, form or file, product line, or transfer or transaction. Identify the problem precisely because a problem may occur at one point in the process and then be noticed or manifest itself later on. If a code is found wrong at the final quality check step, it may have been entered wrong at the order entry process. Your problem statement clearly describes where the defect was observed and where it likely happened. If you are unsure, identify the likely place. Wait until the data confirms the place.
“Recently” or “sometimes” is not a time that is helpful in describing when the issue occurred and what magnitude the issue is. Use a shift, a review period, a batch of data, a set of dates or a process when you have that information. The impact should be something you can describe in factual terms, such as, “additional re-work,” “later release,” “more inspection,” “delay in the transfer” or “result does not meet acceptance criteria.” Do not describe a problem in a way that sounds more serious than the data suggests.
Once you have written the problem statement, check to remove any reference to a proposed solution, the blame or an unverified cause. Do not write “A checklist should be implemented,” or “the problem was caused by a person in the finance department.” Those statements are for a later step in your process, when you analyze the process and the data. When you have a good problem statement, you have a starting point for the solution. It shows clearly “what” the problem is, where the problem lies in the process, when the problem occurs and the magnitude of its impact.