How to write a problem statement
Drafting problem statements for Business Cases
Why do we need one?
When developing a business case, it is common to include a 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 even none at all (1).
So, what do we need to include in a problem statement and how do we write one?
Firstly, we should separate out the problem/issue from any future desired state (goal). The reason we want to do this is that we want to understand the problem clearly before we do or decide anything else.
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, simple, specific and unambiguous (2).
It must always be written in plain (non-technical, non-jargonistic) language.
How do you create a problem statement?
Typically, 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.
- Be totally specific about the issue – qualify your statements so that they mean the same to many people and minimise assumptions and ambiguity.
- Explain why the problem matters.
- Describe the direct impact of the issue on for example: stakeholders; customers; users; revenue; conversion rates, security etc. etc.
- If the source of the issue cannot be proved beyond doubt, use root cause analysis or similar to support and confirm the problem statement.
- Don’t confuse issues with goals – “we need to be best in class” is more of a goal/gap statement than an issue.
- 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:
|The new user registration process is unfit for purpose.||There are issues of trust with the user registration process with: user name privacy; email privacy and ……..||The impacts are: many who start registration to do complete registration; new customers are potentially lost; loss of revenue.|
What we should never do: assume a solution, or even worse
It is often a huge mistake to assume the best solution, or even worse, 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 (2).
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.
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 trying to solve and the impacts you are trying to resolve.
- 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.
- 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 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 acurately describe the issue, and b) how many did not go forward to any further consideration once the issue was properly understood by all parties.