Problem statement

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.[3] Additionally, the problem statement is used to explain what the expected environment looks like.[4]

Another important function of the problem statement is to be used as a communication device. A problem statement 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.[4][6]

Before the problem statement can be crafted, the problem must be defined.[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 five whys, 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.

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 should not be too broad. A benefit of using the five whys 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 should not be too narrow. Solution-bias stifles the creativity that arises while brainstorming a solution, which may result in 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.

1. 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.
2. Reality: This section is used to describe the current or "as is" state of the process or product. It explains 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.
3. 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.
4. 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]

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, users would be able to sign into their laptops and then automatically have access to all of the applications they need to use.

Reality:

• In reality, at least three applications are used every day to accomplish the work. Each application is protected by a password with different requirements for username and password length. Passwords also expire at different times.

Consequences:

• Users waste approximately two minutes per day logging into multiple applications (if there are 500 users, then 500 users * 2 minutes per day = 1000 minutes in lost productivity; 1000 minutes = 16.67 hrs per day * $75/hr = $1250 per day).
• Help desk resolves approximately 6,000 calls per year to reset forgotten passwords and unlock accounts.
• Security risk as users will continue to write usernames and passwords on sticky notes on their desks

Proposal:

• Have a software developer, network administration and business stakeholders collaboration to evaluate potential solutions for a single-sign on capability.