How to write a problem statement

Writing problem statements for Business Cases

In this post we discuss: how to develop a clear problem statement; why we need one; common mistakes to avoid, and provide tips on how they can be improved.

Why do we need one?

When developing a business case, it is often hugely useful to include a clear problem statement or similar.  It should be the starting point for many business cases. Sadly, far too many business cases do not contain a clear problem statement or sometimes even none at all ⁽¹⁾.

The reason we need one is that we should never commit to a business case without having a crystal clear definition of the problem it is intending to resolve.  This firstly helps us to judge whether the problem itself is a priority, relative to all the other things we might be able to at that point in time.

Going forward, if that business case results in a project, no person should ever work on that project without being totally aware of why the project is being done and what it is trying to resolve/improve.

So, what do we need to include in a problem statement and how do we write one?

Firstly, we should separate the problem/issue from any future desired state (goal).  The reason we want to do this is that we want to communicate the problem clearly and accurately before we make any decisions about what we are going to do.

Following this, we should agree that it is a problem worth addressing with the appropriate stakeholders before we then discuss and agree on the desired future state (goal) that we might commit to.

Next, and you cannot over-emphasize how important this is. We must ensure that the problem statement is crystal clear, specific and unambiguous ⁽²⁾. It helps to achieve this if it is written in simple, plain (non-technical, non-jargonistic) language.

How do you create a problem statement?

Often, it should not be written by just one person.  We must minimise or even better eliminate assumptions about the issue or its impacts.

That involves talking to or involving subject matter experts (e.g. users) to confirm that we capture the issue correctly and clearly.

1. Be totally specific about the issue. Qualify your statements so that they mean the same to many people and minimise assumptions and ambiguity.
2. Explain why the problem matters. Even if it seems obvious.
3. Describe the direct impact of the issue on for example: stakeholders; customers; users; revenue; conversion rates, security etc. etc.
4. If the source of the issue cannot be proved beyond doubt, use root cause analysis or similar to support and confirm the problem statement.
5. Don’t confuse issues with goals – “we need to be best in class” is more of a goal/gap statement than an issue.
6. When defining problem statements, there can be many related elements, that are not the same and it does not provide the clarity we need if we mix them up or confuse them:
   • Problem statement: defines an issue and its impacts.
   • Gap statement: describes something you don’t have that you either need or would benefit from. If it’s a gap statement call it that. Not a problem statement.
   • Opportunity: defines the prospect of something of genuine value to stakeholders.
   • Goal statement: describes an aspiration that would result in direct business benefits.
   • Solution: is the specific change to be made to deliver the desired outcomes and benefits.
   • Future state: describes the conditions (and potentially the results) that would be achieved if the goal is achieved.
   • Road map: describes the steps that you need to take to get from your current state to your future state.

Simple example problem statement:

What we should never do: assume a solution, or even worse

It is often a huge mistake to assume the best solution before we have defined the problem properly. Even worse, is to start the problem statement or business case by proposing or describing a solution.

Also, in many cases, we should not expend the time to confirm the optimum solution until we have confirmed this is a problem worth resolving ⁽²⁾.

We should resist the temptation to consider solutions until the problem is a) fully defined and b) confirmed by those who need to. Otherwise, our solution may well be ineffective.

For these reasons, we should hold back on considering or defining solutions until we have formally agreed with the relevant parties that this is a problem worth fixing.

Conclusion:

Having a clear problem statement is of huge value and importance. Assuming the idea/issue goes forward and results in a change, everyone involved in developing the chosen solution should be explicitly aware of the exact problem you are addressing and the impacts you are trying to resolve.

Notes:

1. This is not an isolated example. I was presented with a 27-page business case proposing a new system.  The opening pages and executive summary focused exclusively on extolling the virtues of the new system.  The language being used even made it very obvious where the whole text had come from.  Not once, in all 27 pages were any issues (that the new system was going to resolve) highlighted or discussed.  The Business case was full of words like ‘seamless’, ‘integrated’, ‘best in class’ etc. Totally meaningless, but resulted in an expensive project. Why? Personally, I have no idea.
2. Real-world case-study. When facilitating the development of draft business cases among a large group of product managers, the first step was to agree on and present the problem statement to members of the leadership team. This was in a medium-sized software house. Following discussion between the individual product managers and leadership team, it was remarkable how many times: a) the initial text provided did not clearly or accurately describe the issue, and b) how many did not go forward to any further consideration once the issue was properly understood by all parties, as it was not considered a priority by the leadership team.