Having a clear, understandable problem statement that everybody agrees upon can prevent all sorts of project dysfunction, from stakeholders having a hard time agreeing on requirements and people unwittingly working at cross-purposes due to their different objectives and priorities, to a failed initiative due to a disconnect between what is delivered and what is truly needed.
A problem can be defined as the difference between an existing situation and a preferred one. This definition covers two kinds of problems:
Perception problems. My experience with customers complaining about a page being too slow, originally told in Are You Sweating the Right Small Stuff?, is a good example of when the delta between existing and preferred situation is a matter of changing perceptions.
Actual problems. When you’re dealing with facts, such as “our main customer has just pulled out, taking a quarter of the firm’s revenues with it”, it makes more sense to talk about the difference between existing vs. preferred situation, as opposed to desired vs. perceived state.
Now, you may be asking, “but how do I figure out what the problem really is?”. It’s one thing to talk about the importance of having a well-constructed problem statement, but how do you actually get there?
I’ve been asked this question a couple of times recently, and while books like Are Your Lights On? and Thinking in Systems offer good insights, because of the kinds of examples they use I’ve realized that they don’t necessarily help business analysts working on software projects get better at problem definition. For that reason, I decided to put together a free email course in which I’ll share more targeted case studies and useful techniques in problem recognition & framing to help business analysts create a valid problem statement for their software projects.
Interested? Sign up to the course below.