The Knowledge Brief™ (Part 2): Understanding the Structure of a Problem Statement

 

What's the problem with writing a problem statement? 

Today we will cover Part 2 of “The Knowledge Brief”, defining, structuring and creating our problem statement to allow direction and focus on what we should be changing.

 

“It’s so much easier to suggest solutions when you don’t know too much about the problem.” ― Malcolm Forbes

2.1 Overview

It is often easier to come up with a solution than spend time on solving the problem. However, by failing to address a real issue, we risk repeating the same painful process. We could argue that humans have an action bias, which is a good thing! Nevertheless, there are times when we need to go a little deeper and slower in order to truly solve a problem. Today we will cover Part 2 of “The Knowledge Brief”, defining, structuring and creating our problem statement. Continuing from Part 1, where we discussed the importance of having a well-written background statement that covers the who, what, when, why, and how, our next step is to analyse the background to truly define the problem. Once again, we will take on the persona of an investigative journalist to help business analysts understand the task at hand,

2.2 Why define a problem statement

"A problem well-stated is half-solved," Charles Kettering

Many organisations aren't diligent enough when it comes to articulating the problems they're attempting to tackle and explaining why those difficulties are critical when implementing a change. Without it, businesses miss out on opportunities, waste resources, and indulge in non-strategic activities. Businesses should strive to improve their ability to ask the appropriate questions in order to tackle the right problems. Just as it is tough to write a good background statement, stating the problem/opportunity clearly demands a high level of skill.

Defining a problem means making sure that everyone understands the nature of the problem and any underlying problems. Stakeholders' points of view are stated and talked about to figure out if there are any conflicts between their goals and objectives. Assumptions are reasoned out and checked.

The problem statement is a key factor in gaining stakeholder buy-in, so it’s crucial for the statement to be well written. Just as crucially, the statement must be clear and concise so that all stakeholders understand why the change matters. Precision is paramount here. A problem statement that is incomplete, inaccurate, or poorly crafted will lead to ineffective solutions that waste time, money, and resources. 

As in Part 1, it is useful to think of a business analyst (BA) as an investigative journalist. When crafting their story, every good investigative journalist looks to define the problem or opportunity at hand. BAs do the same, considering the pain points or opportunities that have presented themselves relating to what has happened and why in order to better understand the current business state and the need for change. 

2.3 Structuring your problem statement

“It’s not that I’m so smart, it’s just that I stay with problems longer.” Albert Einstein

The goal when writing the problem statement is that it be written simply, clearly, and precisely. To offer stakeholders clarity, the problem should be stated at a high level. It must summarise the core causes of the problem in its statement to guarantee that the solutions address those causes. This can be more difficult than you imagine, so learning from people who have done it before can be beneficial. In Part 4 of The Knowledge Brief, the root cause analysis is talked about, which has a direct link to the problem statement.

2.3.1 Top 5 things that make a good problem statement

As you can see in the video by Tod Hudson, a good problem statement is made up of the following:

1. It must be factual, not based on opinion. Describing what you know with certainty.
2. It needs to be concise and focussed. Not straying into irrelevant topics.
3. It should be unbiased and not "blame" a person or a team. Not assuming the cause of the problem.
4. There is no suggestion of a solution. No hidden agenda of "what to do".
5. It is relevant; it is important to the business and has associated measures.

2.3.2 Avoiding common pitfalls in crafting your problem statement

You can minimise the risk of project failure by building several basic elements into your problem.  

• Focus on the organisational need: This is where your background statement comes into play — the information you collected should directly influence the problem statement. 
• Don’t worry about how to solve the problem yet: It’s important to keep the focus on the problem rather than exploring how the problem will be solved. Solutions come later in the process. 
• Don’t be overly broad or narrow: It can be tricky to strike just the right balance of specificity in your problem statement (this is an area we will cover in more depth in part 4 of The Knowledge Brief, where we look at how root cause analysis can help define the breadth and depth of the problem). 

For now, keep in mind that a general statement won’t adequately capture the nature of the problem and a narrow one risks stifling creativity because of “solution bias.”

2.4 Creating a problem statement

It all sounds very complicated and hard to do, but there are some very simple tricks to creating a problem statement. Start off by use this simple formula to construct your problem statement. You may have to work with your peers and stakeholders to really define this well. 

Since (date) the (something) in the (business unit or tool) has not met it it’s goal of (something – list the goal and supporting measures or costs). The result has had the following (3 consequences) that have resulted (goal not being achieved).

You already have the background, or at least a good idea of why the change has happened. Use this to create several iterations of the problem statement. It takes time to get it right, but just like a background statement, it is worth it! Again, as mentioned in Part 1 of "The Knowledge Brief", use the Business Analysis Core Concept Model™ (BACCM™) to frame your thinking. The six core concepts in the BACCM are: Change, Need, Solution, Stakeholder, Value, and Context. An effective problem statement will take into account all of these perspectives as they relate to both the background and the problem the organisation is experiencing. 

2.5 Key learnings

• When it comes to explaining the problems they're trying to solve, many organisations don't do it well enough. Without it, the business may miss out on opportunities, waste money, and do things that aren't strategic.
• The problem statement is a key factor in gaining stakeholder buy-in, so it's crucial for the statement to be well written.
• It is important to focus on the 5 key components of a well written problem statement which are:

1. Factual
2. Concise and focussed. 
3. Unbiased 
4. No suggestion of a solution. 
5. Relevant

• Remember this formula: Since (date) the (something) in the (business unit or tool) has not met it it’s goal of (something – list the goal and supporting measures or costs). The result has had the following (3 consequences) that have resulted (goal not being achieved).

2.6 Conclusion

In this post, we covered defining (why), structuring (what), and creating (how) of our problem statement. These three areas of focus assist business analysts in pinpointing the problem that needs to be solved in order to provide clarity to stakeholders. Using the persona of an investigative journalist, we broke down the five key components of a well-written problem statement.  

Happy learning everyone

Stay tuned for our next blog post in “The Knowledge Brief” series, in which we will focus on Part 3 Critical Success Factors. 

 Sources

1. Wikipedia https://en.wikipedia.org/wiki/Problem_statement
2. BABOK® Guide v3
3. Lean Learning Starts with a good problem statement https://youtu.be/sXWQoA4QGB8 

© The Knowledge Brief is a product of Agora Insights Ltd. All rights are reserved.

Post sponsored by Agora Insights Ltd