Better Business Analysis Through Problem Statements

Published:12 August 2013

NOTE: As part of a BA discussion group at work, we were discussing different ways to encourage a focus on defining the root cause of the problem before a solution is specified. We had all had far too many experiences with a business partner saying the problem is that the system does not .... (have a drop-down here, have this extra screen, a button for this, etc., where the problem is defined as the lack of the solution they have already decided upon without any investigation to ensure that the problem has been correctly identified. I brought up the use of Problem Statements, and was asked by my peers to write up my ideas in more detail. I ended up writing it in article format so that it could be shared ahead of time, and it was deliberately written to generate some discussion. I hope you find it useful as well.

Introduction

A problem can be defined as a difference between the expected state affairs and the actual state affairs. And 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. ^[1]

Problem Statements are a common aspect of Project Management. They are frequently included in a Project Charter, with the Problem Statement identifying what problem the project is focused on solving and the Business Case identifying why the problem should be solved (usually in the form of some specific benefit(s) to be gained).

However, problem statements should also be used in the Elicitation and Requirements Analysis aspects of Business Analysis work.

Project Problem Statements

A good problem statement in a Project Charter should essentially specify the scope by defining:

A description of the problem elements (with specific measures where possible)
Identify the stakeholders affected
Describe the impact of the problem (with specific measures where possible)

There is some debate over whether a problem statement should include a solution to the problem, but it is usually a better idea to specify a measurable state that will indicate a solution has been achieved rather than the method the problem will be solved with. For more complex or larger projects, there may be a set of problem statements rather than just one.

However, specifying the problem in project management is not always an easy task. Common issues with defining a good problem statement for a project include:

The problem is nothing more than a list of business complaints that may or may not be related to the project goal or that make the project goal nebulous and ill-defined.
The problem is actually describing the symptoms of the root problem.
Stakeholders disagree about what the problem is because each stakeholder views the problem from within their own silo’d business perspective. Or worse, the stakeholders all read different things into the problem statement but they all assume that the other stakeholders share their understanding.
The problem is defined as a solution state, not a problem. An example might be a problem statement of The server is too slow, resulting in reduced response times. Unless you have done the work to ensure it really is the server, and not network issues, software issues, or a number of other factors you may solve the problem only to find it has had no effect.
The problem is defined too simplistically and without measures. This leads to uncertainty about the actual problem being solved, the scope of the project, and how success will be measured.

A good problem statement in a project charter becomes the key factor in deciding if something is in scope (or in deciding to change scope), in supporting Stakeholder management and engagement, in guiding Business Analysis work, and in evaluating Change Requests.

Problem Statements in Business Analysis

However, Problem Statements aren’t just useful in Project Management work. They can also be a valuable tool for Business Analysts in their Elicitation and Requirements Analysis activities.

Problems Instead of Needs

Business Analysts frequently start Elicitation work with the question What do you need? These needs can then be evaluated to determine if they are within the project scope, and if so, work with the client to validate the need and determine requirements that will fulfill the need.

The problem with this approach is that a client’s needs (or at least their perception of their needs) are almost always framed by their current process, business, or system constraints. Their needs are evolutions of their current situation, and are almost never revolutions. And while evolutions frequently cost less, are easier to envision, and are usually easier to implement; they will never deliver the real business transformations that are needed for major improvements. Indeed, evolutions rarely even consider revolution as a possibility and end up limiting the vision of potential solutions. Evolution is safe, but myopic. That is not to say that sometimes evolutionary change is not the best option, but you should always be aware of its limitations in generating solution options.

Additionally, asking for needs is inviting the client to provide their full wish-list of everything that they want and think they might be able to get the project to pay for. The needs may not be related the project goals or scope in any way. And frequently the Business Analyst must do all of this while relying almost entirely on the client for business context.

A better option may be to start elicitation with the question What are your problems? or What are the barriers preventing you from doing your job better or the company being more effective? By changing the focus to problems and barriers you begin change the client focus from evolution to revolution. You also take the focus away from a general wish-list of new features that the client wants.

The Education Value of Problems

Another benefit of starting with problems and barriers is that the business analyst starts off the elicitation process by essentially educating themselves on the business processes and work. By identifying problems and decomposing those problems down to their most atomic level, the business analyst will learn about the business at a greater level of detail than they would likely learn by asking for needs. This puts the business analyst in a much better position to analyze the business needs and requirements that will solve the problem, making the requirements and the solution more effective at actually meeting the client needs.

Problems Should be Blame-Free and Solution Agnostic

At the requirements level, the Business Analyst should focus on identifying single, highly-specific problems (unlike the more general problems at the project level). Each problem should be traced back to its root cause and all stakeholders involved in that problem identified. Once this is done a problem statement should be generated for that specific problem that every stakeholder involved can agree upon. This problem statement should:

Not blame any group or person,
Should generally not identify specific system capabilities or lack thereof as problems,
It should not identify a solution to the problem.

There are likely to be some doubts about why a problem statement should be solution and system agnostic, so let me explain my reasoning.

If you were to say that the problem is the accounting system does not calculate year-end cost basis correctly for reporting to clients you have defined the problem as being with the accounting system. You have also limited all potential solutions to just the accounting system because that is the root of the problem you have defined.

The question is the whether client (or business) problem is really with the accounting system? If you instead say that the problem is accurate and correct year-end cost basis reporting figures are not available for clients you make the problem solution independent of a specific system. Now the range of solutions could include at least the following:

Changing the accounting system to calculate the figures correctly (if you own the source code)
Creating a separate system that correctly does the cost-basis calculations and provides them to the accounting system
Manually calculating the cost-basis figures offline as a stop-gap while the entire accounting system is replaced, upgraded, or fixed.
A business decision is made to not provide client cost-basis reporting, if that is a viable option.

This process of creating a blame-free and solution agnostic problem definition should result in a discussion of what the problem is in abstract terms, which should lead to a discussion of business needs in more abstract, solution agnostic terms in the future. This separation of the client problem from specific solutions or systems enables a more strategic view of problem solutions that are outside of the current process and system limitations. In essence, it makes revolutionary change easier to consider while system-specific solutions are almost always evolutionary in nature.

If achieving agreement among all stakeholders if proving difficult, you may not have identified the true root cause or you may need to build knowledge and perspective among the stakeholders of why the problem is valid in order to build consensus. This can often occur when stakeholders get bogged down in identifying the problem as being with a specific system or group, rather than in isolation.

Free-Range Business Needs

Once a verified and agreed upon problem statement exists, the problem can be identified as in or out of scope of the project goals and prioritized among all problems identified for the project effort. The Business Analyst can then begin the needs identification part of the Elicitation process focused on what the business needs are to solve that specific problem. This helps keep the needs elicitation process focused and more effective. It also helps to identify business needs that are free-range, and not confined within the current system and process limitations.

This does not mean that the final solution may not have to be built around those realities, but starting at a level outside of the current limitations means the underlying business needs are more likely to be identified. This makes the range of solution options more open, and may make non-technical solutions such as process changes easier to identify.

Writing Problem Statements

Writing problem statements can start with the same process at both the project management and requirements levels. The first task is to identify the problem(s). ^[2] One way to do this is to start with the Five W’s^[3] and then follow that up with the 5 Why’s. ^[4] The Five W’s are the classic Who, Where, What, When, and Why. In the case of problem statements, these might be better stated as: [5]

What is the problem?
Who has the problem?
Where does the problem occur?
When does the problem occur?
What does the problem impact?

This information is then further analyzed using the 5 Why’s (asking Why five times or more to elicit more details and to ensure the root cause is identified), or other methods such as Fishbone Diagrams that help with identifying root causes. This process should continue until there is agreement that the actual root cause problem has been correctly identified and defined.

Where the Project Management and Requirements work with Problem Statements usually diverge is at the Problem Decomposition stage.^[2] Once a problem has been identified, the business analyst will work with the client to decompose it into smaller distinct elements. These may be new dependent problems that are smaller but separate issues that cause the problem(s) at higher levels; or the components of a problem such as who is involved in the process, the systems used, the business units or system with input to process or who take output from it, and other characteristics.

In the end, each problem statement at the requirements level should meet the following criteria: ^[5]

Focused on only one Problem.
One or two sentences long.
Does not suggest a Solution.

As each discreet problem is identified and decomposed, the business analyst is identifying the business needs that a solution to that specific problem must meet. These business needs then drive further elicitation and analysis work until business requirements are complete.

Recommendations

Starting requirements work from a problem perspective isn’t very different in most ways than starting with needs elicitation. It inserts two additional steps at the start of the normal requirements process so that the flow is now:

Problem Identification
Problem Decomposition
Need Identification
Need Analysis
Requirements Identification
Requirements Verification
Requirements Validation

In my opinion, the real difference is in how starting with problem identification and decomposition changes thinking on both the business analyst and stakeholders part.

The real difficulties are likely to be in identifying the actual root cause of problems, and in the time it takes to do that analysis. The process of identifying root causes can lead to systems or groups that are not in scope, can require the business analyst to gain a significant amount of knowledge of the business, and can take a lot of the client’s time. This can result in clients feeling the BA is wasting their time when they already know what the problem is.

When documenting requirements, the business analyst should also make sure to tie specific requirements to specific problems. Just as with tying specific requirements to specific business needs and goals is done through a traceability matrix, the same process can support tying those business needs to specific problems that prevent the achievement of the business goals.

Benefits

Starting with defining problem statements in requirements work has several benefits. These include:

Starting with defining the problem helps keep the project effort from becoming the dumping ground of the client’s wish list.
By identifying specific problems early on, it becomes much easier to ensure the scope is properly defined and prevent scope creep later in the project.
By starting with problem analysis, the risk is reduced of the project delivering a solution for the symptoms, rather than the true problem.
By starting with problem identification and decomposition, the clients are encouraged to conceive of needs and potential solutions beyond their current environment. This increases the likelihood of revolutionary change instead of evolutionary change.
Problems can be prioritized for solution by the project, rather than just individual requirements. Problem priority can then drive requirement prioritization. This may be an easier prioritization process for all stakeholders to understand and reach consensus on.

Comments and feedback are welcome.

References

Wikipedia – Problem Statement
Research Paper - Problem Identification and Decomposition within the Requirements Generation Process. Sidky, Sud, Bhatia, and Arthur. Virginia Tech Department of Computing Science. 2002:
Wikipedia – Five W’s
Wikipedia – 5 Why’s
enFocus Blog – Writing an Effective Problem Statement

Minor edits made in 2015 to fix spelling and grammar mistakes.