Problem Statements are used as a concise description of the object and the issue under investigation.

It should clearly state what is wrong in order to lead the individual, or team to determine the root cause and creative solution to the problem. Just the facts, maam In developing a good problem statement, use facts and avoid folklore and emotion. Act like an investigator or a newspaper reporter and ask questions such as the following: What is the problem? How does the problem occur? When does the problem occur? Where does the problem occur? Who identified the problem? What is the magnitude of the problem? How many customers are affected? Use of objective evidence (or lack of!!) to support the problem should be used. This will help keep the focus on the problem, not the solution or root cause. Another way to keep focus on the problem is to leave out blame; do not use names and, where possible, avoid referring to individuals. This helps the corrective process remain focused on a long-term solution rather than on laying blame. Think about the difference between the following two statements: 1. The release engineer didnt complete the build correctly and didnt do an integration test. 2. The build logs from the final system test dont provide evidence that the integration test was completed The first statement leads investigators to the root cause and lays the blame on a person. The second statement indicates some objective evidence is missing and leads the team to the conclusion that an activity wasnt performed according to procedure. It allows Root cause analysis to occur. In the second question, the team gets to ask, Why?. The first statement already tells us Why. The second allows you to question if the operation was completed, if it was necessary, if the build script completed automated testing , was the record recorded differently or if the process has been changed and the documented procedure hasnt been updated. Having a good problem statement will help the root cause analysis and problem resolution come to a creative and useful solution. Below are sections from MAS templates that require problem statements:

From the Product Vision Template:

Problem Statement <Describe the problem that the product will solve. Focus on items such as saving time, saving or making money or meeting a government (e.g., FDA) or certifying organization (eg.e, JCAHO, CAP) requirement. This should already be completed in the Business Case document. Use the table below to guide your thinking about the problem statement, but state the problem statement in paragraph form.> The problem of Affects The impact of which is A successful solution would <describe the problem> <the stakeholders affected by the problem>. <what is the impact of the problem>. <list some key benefits of a successful solution>.

CAPA Problem Statement:

Description of CAPA issue:

Explain the nature of the quality issue leading to CAPA, e.g., what was the source and type of feedback resulting in the CAPA? What were the results of quality data analysis that identified the CAPA? Is this the first instance or has the issue occurred on other occasions? When and where did the issue occur? Nonconformity Problem Statement:
Description of Nonconformity: How did the software or platform malfunction (i.e. did not meet its requirements)? How was the nonconformity discovered (MAS employee, hospital customer, device vendor partner or other business partner)? When and where did the nonconformity occur?

SOP Deviation Report (Problem Statement)

Description of Deviation: Provide a brief description of the process deviation. How was the process deviation discovered or identified (MAS employee, hospital customer, device vendor partner or other business partner)? When and where did (or will) the process deviation occur?