I came across a presentation recently which described the various stages that research projects go through and Stage 1 was “Identify and define the problem”. That’s fine and a fair starting point for the journey through hypothesis testing, data gathering, analysis and reporting.
The presentation even came up with a definition of “problem” which is pretty close to my working definition: “a deviation from normal expectations”. I was brought up as a manager on Kepner Tregoe’s Problem Solving approach where their definition (in the book, The Rational Manager) was “A problem is a deviation from a standard of performance”. In other words, if what you’ve got is not what you expected, or what you wanted, then you’ve got a problem.
The KT method emphasises the importance of coming up with a precise statement of the problem, before even thinking about how to solve it. This reflects the well-known phrase “A problem well defined, is a problem half solved”.
So, problem statements must be written on the basis of an identified deviation from normal expectations. That way, you avoid:
- Asking questions (e.g. our problem is how to speed up complaints handling)
- Defining solutions (e.g. our problem is we need new computers)
In my view, very few of the examples given in the presentation were examples of well-defined problems. They included:
- Has the new marketing campaign increased sales?
- Will opening a new showroom improve our brand and reputation?
- What are the components of citizen wellbeing?
- What factors should be considered in deciding where to relocate the warehouse?
They may be OK as research questions, but they are not well-defined problems because none of them specify a deviation.
Of course, a really useful Problem Definition Statement comprises more than just a view of “what” the problem is. It should also include where, when, who and how big is the problem. In the same way as most Project Definitions spell out what is out of scope, a well-defined problem should also summarise what’s outside the problem. Kepner Tregoe refer to “Is” and “Is not” definitions, but I usually talk about “inside the problem” and “outside the problem”. Not only do these additional levels of definition help you understand what you don’t need to solve, they might also lead you to potential solutions. If XYZ Claims have increased, what can we learn from the fact that ABC Claims haven’t. Of particular importance is the “when” dimension. If you can identify the point in time when a problem started it almost always leads you to a change that triggered the problem, such as:
- Somebody did something, or didn’t do something
- A new process or procedure was introduced
- A new piece of equipment or technology was introduced
- A way of working was introduced, or changed
You do, of course, have to recognise that your problem statement may actually only be a symptom of an underlying problem. For example, “our problem is poor morale” is probably a symptom of some systemic root cause such as poor leadership, processes or working conditions. In this example, it might be even better to define the problem in terms of its impact on the organisation; maybe poor morale is causing customer service issues, or product quality failures. There is invariably a cause and effect chain of problems and symptoms, so you need to be clear about your starting point. That’s why subsequent steps in the Problem Solving process make use of tools such as Cause and Effect Analysis and the 5 Whys to drill down to root causes, so you can eliminate these with permanent solutions, rather than sticking plasters.
So, when is a problem not a problem? When it’s poorly defined.