If you have been asked to produce a problem statement and you are staring at a blank page, start here. Problem statement examples in business are most useful when they show you not just the finished output but the thinking behind it. In my experience, the problem statement is the document that either earns you credibility at the start of a project or quietly undermines everything you build afterwards. I want to help you get it right before you go any further.
A business problem statement does one job: it defines what is wrong, in practical terms, and establishes the context for why addressing it matters. It is not a solution. It is not a scope document. It is the foundation that justifies everything that comes next, from the business case through to the requirements work. If you need a structured approach for how that analysis flows from here, the business analysis plan template guide gives you a solid framework for sequencing the whole effort.
Who Writes the Problem Statement and When
In most projects I have worked on, the responsibility for developing the problem statement sits with whoever is leading the analysis effort. That is often me, as the BA, working alongside the project manager or a senior stakeholder who has raised the concern. In some cases, I have been handed a half-formed problem statement written by an executive and asked to sharpen it into something workable. Both situations require the same discipline: get the right people in the room, and do not let anyone rush past this step.
There are several moments in a project lifecycle where developing a problem statement is appropriate:
- Project initiation: Defining the scope and objectives before any solution thinking begins is where the problem statement earns its keep.
- Process improvement: When an area of the business is underperforming, the problem statement anchors the root cause investigation before you jump to fixes.
- Business case development: A well-articulated problem statement is the opening argument in any business case. Without it, the case has no foundation.
- Strategic planning: When an organisation is reviewing its direction, problem statements help frame the challenges that need to be addressed in the roadmap.
- Policy or programme work: In government and public sector projects I have worked on, problem statements are often required before funding is even considered.
How to Categorise Business Problems
One of the most useful things I do early in any engagement is categorise the problems I am uncovering. This stops me from treating symptoms as root causes, and it gives stakeholders a structured way to see where the organisation is struggling. I use a business architecture lens, which organises problems across seven capability areas. For each area, I look for issues and then describe the associated risk so the impact is explicit.
| Capability Area | Typical Problem Statement | Associated Risk |
|---|---|---|
| Strategy | Initiatives are not aligned to an overall organisational vision, resulting in siloed project delivery. | Investment is duplicated and strategic objectives are not met. |
| Services / Products | Slow responsiveness to sales leads due to untimely retrieval of customer information. | Lost revenue and declining customer satisfaction. |
| People | Poorly defined roles and responsibilities create confusion and slow operational response times. | Staff morale declines and service delivery quality suffers. |
| Processes | Intensive manual processing due to physical handling of paperwork and mail-outs. | Bottlenecks in service delivery and wasted staff time on non-core tasks. |
| Applications | Out-of-date functionality caused by a constantly evolving business environment with no upgrade path. | Increasing technical debt and growing gap between system capability and business need. |
| Information | Unstructured content stored across multiple devices with no metadata, making retrieval unreliable. | Poor decision-making due to inaccessible or inconsistent data. |
| Infrastructure | Multiple applications running on duplicate systems, creating unnecessary maintenance overhead. | Escalating support costs and increased risk of system failure. |
This framework is directly applicable to the early discovery phase. I typically work through these categories in interviews with managers and subject matter experts, asking targeted questions within each area to surface the real issues rather than the presenting complaints. For guidance on the kinds of questions that generate this level of insight, the kick-off meeting questions guide is worth reading alongside this article.
How Long Should a Problem Statement Be
The honest answer is: as short as it can be while still being complete. In most business reports and project documents I produce, a problem statement runs from two sentences to a short paragraph. Occasionally, for a complex regulatory or technology transformation programme, it may extend to two paragraphs. It should never exceed that. The purpose is to focus attention, not to demonstrate how much analysis has been done. Jargon, excessive context, and hedging language all dilute the statement’s impact. Write it plainly, and get a colleague to read it cold. If they cannot explain the problem back to you in one sentence, it needs another pass.
A Worked Example: When the Stakeholder Pushes Back
On a process improvement project I worked on for Organisation A, a government agency with around 400 staff, I identified a significant problem in how annual leave was being managed. The process required an employee to fill out a paper form, print it, have it signed by their manager, send it physically to HR for verification and data entry, scan it into the records management system, and then forward it again to payroll for re-keying. Every step was manual. Every step was a potential point of delay or error.
I drafted the following problem statement:
Problem Statement: Intensive manual processing due to the physical handling of leave paperwork across multiple business units.
Description: Annual leave requests are initiated on paper, routed physically through management, HR, and payroll teams for sequential approval and data entry. Each transfer introduces delays and creates risk of data loss or error.
Risk: This process creates bottlenecks in HR service delivery, increases the likelihood of payroll errors, and consumes significant staff time that could be directed to core business activities. Estimated rework time across HR and payroll is approximately 12 hours per week.
When I presented this to the HR Manager, she pushed back immediately. Her position was that the process was “working fine” and that the real problem was a lack of staff, not the process itself. This is one of the most common forms of friction I encounter: a stakeholder who has ownership of a broken process and interprets any problem statement about it as a personal criticism.
I did not argue the point in the room. Instead, I went back and used a Five Whys analysis to trace the root cause properly, and brought the quantified rework estimate back to a follow-up session. When the HR Manager saw that the 12-hour figure was drawn from her own team’s time logs, the conversation shifted. We revised the problem statement together, which gave her ownership of it, and she became one of the project’s strongest advocates. The friction did not derail the work. It made the problem statement more accurate and more defensible.
Tools for Developing a Problem Statement
- Brainstorming with stakeholders: Gather the people closest to the problem and surface every issue on the table before filtering down to the most critical ones.
- SWOT analysis: Useful for framing the problem within the broader internal and external context, particularly in strategic planning scenarios.
- Fishbone diagram: A structured way to map potential causes back to a central problem. I use this when there are multiple competing theories about what is driving an issue. See the fishbone analysis example for a practical walkthrough.
- Five Whys: Asking why five times forces you past the surface symptoms and into the root cause. It is especially effective in one-to-one conversations with subject matter experts.
- Problem statement template: A structured template prompts you to cover the problem, its context, its impact, and the risk of inaction. Use it to make sure nothing is missed.
The Steps I Follow to Write a Problem Statement
I have settled on a consistent sequence over many years of doing this work, and it holds up whether the project is agile or waterfall, large or small:
- Identify the problem in specific, measurable terms. Avoid vague language like “issues with” or “challenges around.”
- Gather context from data, existing documentation, and stakeholder input before writing anything.
- Break the problem into its component parts using the categorisation framework above.
- Identify root causes, stakeholder impacts, and the consequences of inaction.
- Draft a problem statement that covers: what the problem is, who it affects, and what happens if it is not addressed.
- Refine the language until it is plain, direct, and free of jargon.
- Validate the statement with stakeholders and subject matter experts, and be prepared to revise it based on what they tell you.
That last step is not optional. A problem statement that has not been tested with the people closest to the problem is a hypothesis, not a finding. The validation step is also where you will encounter the friction that makes the statement stronger, as I found with the HR Manager on Project A.
A well-constructed problem statement does more than justify a project. It becomes the reference point every time scope creep appears, every time a stakeholder wants to redirect effort, and every time you need to remind a team why the work matters. The time you invest in getting this right at the start is repaid many times over in clearer decisions, faster approvals, and a project team that actually understands what it is trying to solve.
Frequently asked questions
What is a problem statement example in business?
A business problem statement clearly defines an existing issue, its context, and the risk of not addressing it. An example would be: intensive manual processing due to physical handling of leave paperwork across HR and payroll, resulting in bottlenecks and an estimated 12 hours of rework per week. The statement names the problem, the affected area, and the measurable impact.
How long should a business problem statement be?
Most business problem statements run from two sentences to a short paragraph. For complex projects, two paragraphs is the practical maximum. The goal is clarity and focus, not length, so anything that does not directly describe the problem, its context, or its risk should be cut.
Who is responsible for writing a business problem statement?
Responsibility typically falls on whoever is leading the analysis effort, most often the business analyst, sometimes alongside the project manager. The BA should involve relevant stakeholders and subject matter experts in validating the statement, even if they draft it independently.
What is the best way to structure a business problem statement?
A practical structure covers three elements: the problem itself stated specifically, a description of the context and how it manifests operationally, and the risk or impact of not resolving it. Adding a quantified impact wherever possible makes the statement significantly more persuasive with decision-makers.
What tools help you write a business problem statement?
The Five Whys technique, fishbone diagrams, SWOT analysis, and structured stakeholder interviews are all effective. A problem statement template helps ensure you cover every required element consistently across different projects and contexts.
Try Ash, Your Virtual BA
If you are working on a problem statement right now and need help shaping the language, structuring the categories, or pushing through stakeholder friction, Ash is built for exactly this kind of task. Ash can help you move from a vague concern to a well-formed, defensible problem statement using the same structured thinking described in this article. Give it a go with your current project details and see what comes back. Try Ash Virtual BA.
Further reading
- Common Pitfalls to Consider with Business Problem Statements | Scrum.org
- Business Problem Statement Examples | Scrum.org
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.