Problem statement
A problem statement is a concise description of an issue to be addressed or a condition to be improved upon. It identifies the gap between the current (problem) state and desired (goal) state of a process or product. Focusing on the facts, the problem statement should be designed to address the 5 W’s – who, what, where, when, and why. The first condition of solving a problem is understanding the problem, which can be done by way of a problem statement.[1]
Problem statements are widely used by businesses and organizations to execute process improvement projects. A simple and well-defined problem statement will be used by the project team to understand the problem and work toward developing a solution. It will also provide management with specific insights into the problem so that they can make appropriate project-approving decisions. As such, it is crucial for the problem statement to be clear and unambiguous.[2]
Purpose
The main purpose of the problem statement is to identify and explain the problem. This includes describing the existing environment, where the problem occurs, and what impacts it has on users, finances, and ancillary activities.[3] Additionally, the problem statement is used to explain what the expected environment looks like. Defining the desired condition provides an overall vision for the process or product. It makes clear the purpose for initiating the improvement project and the goals that it is meant to accomplish.[4]
Another important function of the problem statement is to be used as a communication device. It helps with obtaining buy-in from those involved in the project.[3] Before the project begins, the stakeholders verify the problem and goals are accurately described in the problem statement. Once this approval is received, the project team reviews it to ensure everyone understands the issue at hand and what they are trying to accomplish. This also helps define the project scope, which keeps the project concentrated on the overall goal.[5]
The problem statement is referenced throughout the project to establish focus within the project team and verify they stay on track. At the end of the project, it is revisited to confirm the implemented solution indeed solves the problem. A well-defined problem statement can also aid in performing root-cause analysis to understand why the problem occurred and ensure measures can be taken to prevent it from happening in the future.[2]
It is important to note that the problem statement does not define the solution or methods of reaching the solution. The problem statement simply recognizes the gap between the problem and goal states. It can be said that, “a problem well stated is half solved.”[4] However, there are often multiple, viable solutions to a problem. Only after the problem statement is written and agreed upon should the solution(s) be discussed and the resulting course of action determined.[6]
Defining the problem
Before the problem statement can be crafted, the problem must be defined. It is human nature to want to begin working on a solution as soon as possible and neglecting the definition of the true problem to be solved. However, a poorly defined problem increases the risk of implementing a solution that does not fully meet the expected results. A problem cannot be solved if it is not completely understood.[7]
The process of defining the problem is often a group effort. It starts with meeting with the stakeholders, customers, and/or users affected by the issue (if possible) and learning about their pain points.[8] Since people often struggle with effectively communicating their issues, particularly to someone outside of the process, it is helpful to ask a series of “why” questions until the underlying reasoning is identified. This method, known as the “5 Why’s”, helps drill down to the core problem as many of the experienced frustrations could be mere symptoms of the actual problem.[6] Asking these additional questions as well as paraphrasing what the stakeholder had said demonstrates a degree of empathy and understanding of the problem.[5]
The information collected from these initial interviews is only one part of problem analysis. Many times the problem extends to multiple areas or functions to which the stakeholders, customers, and users are unaware. They may also be familiar with what is happening on the surface but not necessarily the underlying cause. Therefore, it is just as essential to gather knowledge, information, and insights from project team members and subject matter experts concerning the problem.[8] Additional research materials, including work instructions, user manuals, product specifications, workflow charts, and previous project plans may also need to be consulted. Like most other stages in the process improvement project, defining the problem is often iterative as several rounds of discussions may be needed to get the full picture.[2]
Once the problem is understood and the circumstances driving the project initiation are clear, it is time to write the problem statement.
Writing the problem statement
The problem statement will be used to gain project support and approval from stakeholders. As such, it must be action-oriented.[3] More importantly, the problem statement must be written clearly and accurately in order to deliver successful results. A poorly crafted or incorrect problem statement will lead to a faulty solution, as well as wasted time, money, and resources.[1]
There are several basic elements that can be built into every problem statement to decrease the risk of project failure. First, the problem statement must focus on the end user. A common mistake is focusing on “how” a problem will be solved rather than the current gap. Second, the problem statement shouldn’t be too broad. A benefit of using the “5 Why’s” approach is that it avoids over-simplicity by providing the details needed for understanding the problem and developing an appropriate solution. Finally, the problem statement shouldn’t be too narrow. Solution-bias stifles the creativity that arises while brainstorming a solution, which may result in a less-than-optimal experience for the user.[8]
It is useful to design and follow a specific format when writing a problem statement. While there are several options for doing this, the following is a simple and straightforward template often used in Business Analysis to maintain focus on defining the problem.
- IDEAL: This section is used to describe the desired or “to be” state of the process or product. It identifies the goals of the stakeholders and customers as well as assists in defining scope. At large, this section should illustrate what the expected environment would look like once the solution is implemented.
- REALITY: This section is used to describe the current or “as is” state of the process or product. It explains the pain points expressed by the stakeholders and customers. It should also include the insights and expertise of the project team and subject matter experts provided during problem analysis.
- CONSEQUENCES: This section is used to describe the impacts on the business if the problem is not fixed or improved upon. This includes costs associated with loss of money, time, productivity, competitive advantage, and so forth. The magnitude of these effects will also help determine the priority of the project.
- PROPOSAL: This section is used to describe potential solutions. Once the ideal, reality, and consequences sections have been completed, understood, and approved, the project team can start offering options for solving the problem. It can also include suggestions by the stakeholders and customers, although further discussions and research will be needed before a specific course of action can be determined.[7]
Following this format will result in a workable document that can be used by all parties to understand the problem and elicit requirements that will lead to a winning solution.
Example
Problem statements can vary in length, depending on the complexity of the problem. The following is an example of a simple problem statement for the creation of a Single Sign On capability:
IDEAL
Ideally our users would be able sign into their laptops and then automatically have access to all of the applications they need to use.
REALITY
In reality we use at least three applications every day to accomplish our work. Each application is protected by a password with different requirements for username & password length. Passwords also expire at different times.
CONSEQUENCES
- Users waste approximately 2 minutes per day logging into multiple applications (500 users * 2 minutes per day = 1000 minutes in lost productivity; 1000 minutes = 16.67 hrs per day * $75/hr = $1250 per day).
- Helpdesk resolves approximately 6000 calls per year to reset forgotten passwords & unlock accounts.
- Security risk as users will continue to write usernames & passwords on sticky notes at their desks.
PROPOSAL
Have S/W Dev, Network Administration and business stakeholders collaborate to evaluate potential solutions for a Single Sign On capability.
References
- ^ a b Kush, Max (June 2015). "The Statement Problem". Quality Progress. 48 (6).
- ^ a b c Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (September 2013). "Importance of Problem Statement in Solving Industry Problems". Applied Mechanics and Materials. 421. Zurich – via ProQuest.
- ^ a b c Gygi, Craig; DeCarlo, Neil; Williams, Bruce (2015). Six sigma for dummies. Hoboken, NJ: John Wiley & Sons. pp. 76–78.
- ^ a b Lindstrom, Chris (2011-04-24). "How To Write A Problem Statement". www.ceptara.com. Retrieved 2018-04-10.
{{cite web}}: Cite has empty unknown parameter:|dead-url=(help) - ^ a b Perry, Randy; Bacon, David (2010). Commercializing Great Products with Design for Six Sigma. Prentice Hall. p. 18.
- ^ a b Shaffer, Deb (2017-07-12). "How to Write a Problem Statement". ProProject Manager. Retrieved 2018-04-10.
{{cite news}}: Cite has empty unknown parameter:|dead-url=(help) - ^ a b Shaffer, David (2015-12-21). "Cooking Up Business Analysis Success". BA Times. Retrieved 2018-04-10.
{{cite web}}: Cite has empty unknown parameter:|dead-url=(help) - ^ a b c Widen, Steven (2018-04-02). "Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes". Forbes. Retrieved 2018-04-10.
{{cite news}}: Cite has empty unknown parameter:|dead-url=(help)