Many organizations use some form of “problem statement,” which is often nothing more than a list of user complaints, as a catalyst to initiate projects. However, in my experience, merely documenting hundreds of complaints or listing hundred of prescribed requirements does not accurately document the underlying problem.  If you do not understand the problem, then how can you define a solution to resolve the problem?

To resolve the underlying problem, it is essential that project teams and stakeholders collaboratively determine what the real problem is, document it and understand it.  This may sound easy, but it is difficult for most organizations. People often find it extremely difficult to recognize and document the real problem, partly because they focus on the wrong things, generally symptoms rather than cause, and make incorrect presumptions of how the process works.  It is difficult to discover the real problem because people are not accustomed to thinking in the disciplined manner needed to identify and solve their problem.

Robin Goldsmith’s problem pyramid is an excellent method to define business problems.  It consists of six steps:

1. Identify the problem, opportunity or challenge
2. Define current performance measures
3. Define target performance measures
4. Determine the cause of the problem
5. Define what should be done to resolve the problem
6. Define how the problem will be solved

One reason people get confused about the problem is that they are not accustomed to applying measures and goals. Measures and goals are key to the disciplined thinking needed to identify the problem correctly. The difference between the current and goal measures is the benefit or value to be obtained from solving the problem. Nevertheless, discovering and documenting the real problem and its cause are necessary for successful projects.  Let’s examine what is required to define a good problem statement.

According to Wikipedia, a problem statement is a concise description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve the problem.

In project management, the problem statement is part of the project charter and defines what the problem is so that the project team and stakeholders can focus their attention on solving the problem.  Either a project manager of business analyst may prepare the problem statement.  Having a good problem statement is essential for good business analysis.

It is important to have a good problem statement before starting eliciting requirements for a solution. A good problem statement should answer questions such as:

1. What is the problem?
2. Who has the problem?
3. Where does the problem occur?
4. When does the problem occur?
5. How often does the problem occur?
6. What causes the problem?
7. What does the problem impact?

After drafting the problem statement, the prepare should further analyze the problem statement by posing additional questions such as:

• What is occurring? (E.G., Sales have dropped 30% over the last two years and has significantly eroded customer profitability.  A recent customer satisfaction survey has shown that customers are not pleases with our product and they also consider our price to be too high.)
• What “should” be occurring? (E.G., We need to significantly increase sales in this fiscal year by at least 30 percent or more.)
• What could happen if the problem is not addressed? (E.G., if action is not taken quickly, we will need to significantly reduce headcount and other costs to be a going concern.)

A good problem statement should be:

▪ Concise. The essence of your problem needs to be condensed down to a single sentence. A reader of the project statement should be able to say “Aha!! Now I now understand the problem.”

▪ Specific. The problems statement should focus your thinking, research, and solutions toward a single population or issue.

▪ Measurable. Problems can be measured in terms of degree and frequency. The strongest problem statements incorporate measurable aspects of both the degree and frequency of the problem.

▪ Specify what is Impacted. The problem statement should identify the population affected by the problem.

Let’s further examine the steps for creating a good problem statement.

▪ Write down your problem or current state. Don’t worry too much about quality at this point – simply making a start is significant.

▪ Expand on the problem by asking the following questions:

▪ Who does it affect / does not affect?

▪ What does it effect / does not affect?

▪ How does it effect / does not affect?

▪ When is it a problem / is not a problem?

▪ Where is it a problem / is not a problem?

▪ Re-write your problem statement based on those answers. It may consist of several sentences or a set of bulleted items.

▪ Try to revise the bulleted list or initial problem statement into a single clear sentence. This might take a couple of attempts but stick with it. Finally, review your new problem statement against the following criteria:

▪ Focused on only one problem.

▪ One or two sentences long.

▪ Does not suggest a solution.

You should now have a concise and well-balanced Problem Statement. It should be unambiguous and devoid of assumptions. It will enable you or your group to focus on the problem and provide the foundation for the team to begin work on the solution.

The problem statement should be available and accessible to all stakeholders and the solution team. The screen shot below shows how the problem statement would be displayed in RequirementPro,™ a component of the Enfocus Requirements Suite.™