The Impact of Defining a Project’s Problem
The Impact of Defining a Project’s Problem
By Paul C. Donehue
Few decisions have a greater impact on the likelihood of success of an improvement project than the definition of the problem. Stephen Covey says that the way we see the problem is the problem; and Albert Einstein warns that we cannot solve problems at the same level of thinking with which we created them.
The way we define and communicate the problem the team is expected to solve will greatly influence the speed and efficiency with which a team will complete its work, the degree of satisfaction between the team and the project sponsor, and the efficacy with which an organization prioritizes and sequences the problems to devote resources to.
It takes some careful thought, but a good problem statement is worth the effort because it helps you to ensure that:
- Team participants, leaders and sponsors, have a shared understanding of the problem that will be solved
-
The organization will give the project the appropriate priority and urgency
-
The team has a good baseline against which they can test the results of their solutions
-
The team is open to surfacing and testing a range of possible root causes so as to increase the likelihood of finding an effective and lasting solution
Four Practices That Lead To Better Results
A good problem statement requires some solid pre-work, thoughtful consideration & discussion, and the restraint to avoid speculating before the analysis. If you follow the four basic guidelines for problem definition, you will greatly improve the chances the right problem will get solved for good.
- Write it down. If the problem is not written, shared, and discussed, there is a risk that all participants will assume that everyone is on the same page about the problem they are trying to solve. In most cases, this will not be the case, and the blissful ignorance about their different expectations will eventually give way to a combination of bewilderment, conflict, frustration, disappointment, and a great deal of inefficiency.
Organizations can avoid the problem solving frustration and rework by surfacing right up front any different views of the problem they are trying to solve. The best way to surface and discuss any differences is to write it down and discuss it with all participants, to ensure it is well understood and agreed to.
In addition to getting everyone on the same page, only a written problem-statement can be tested against the next three qualities necessary to effective problem-solving teams.
-
Include a quantification of the waste the problem is causing. This, of course, means you have done some pre-work because no problem statement is as effective as it should be if it does not indicate why we care. Quantifying the waste makes certain that the organization does not invest scarce resources on something that will not have a significant impact. Every organization has more opportunities for improvement than capacity to execute on the improvements.
Quantifying the waste also helps elicit the urgency and support that the project merits. A problem statement that is “costing the organization $18,000 each week in excess charges” will receive more urgency than a problem “costing the organization $800 a week.” And problems for which no discernible and measurable impact can be found probably should not receive much urgency at all. Quantifying the waste in the problem statement helps an organization make sure that they are working on first things first.
-
Be specific about the metric you are using to size the problem. Malcolm Forbes once observed that “It’s so much easier to suggest solutions when you don’t know too much about the problem.” The rub is that you will have a hard time determining if your solutions are effective. To avoid this pitfall, your problem statement should incorporate the measurement you expect to move the needle on, the current baseline for that metric, and both the time and the place that your baseline measurement was taken.
By making the problem statement factual and specific about what observable phenomenon we saw when and where, we create for the team a clear and effective baseline against which to measure improvements.
-
Omit Judgments and Opinions about Underlying Causes. Maslow observes that “If the only tool you have is a hammer, you tend to see every problem as a nail.”
We all have biases, and when we make assumptions about the underlying cause, we bias the process to overlook other possible causes. In theory, this could be a time-saver – if you hit upon the correct root cause. However, in our experience this rarely happens. Making assumptions about the causes almost always makes a problem more difficult to solve instead of easier to solve. This is because if one or more important underlying causes are overlooked by the bias introduced in the problem-statement, the problem will not be solved before the project goes through quite a lot of rework.
Most people have some sort of bias or hunch, slight or strong, about possible underlying causes of most problems and they will consider these first. For example, some people easily incline toward thinking that the technology is not what it could or should be and theorize that this is the cause of most of the problems they encounter. Others are quick to suspect that the incentives are misaligned. And still others may speculate first that processes are not sufficiently defined and adhered to. These hunches are developed based on experience and people with diverse experience and biases tend to serve a project well. However, no matter how confident in the theory about the root cause, inclusion of an assumption about the cause or the solution in the problem statement is more likely to impede results than accelerate them. A hunch makes an excellent servant (in the problem analysis phase of the project) but a poor master. Leave any comment about possible underlying causes out of the problem statement.
Paul C. Donehue is a Senior Associate at Conway Management Company, an international management consulting firm that helps clients study, change and improve their work.
These are good points, more thorough than typical problem statement guidelines, which frequently focus just on complaining. Neither approach gives sufficient attention to making sure the problem is right, for agreement on it often can be deceptive. My powerful Problem Pyramid™ is a much more disciplined systematic way to identify accurately the REAL problem, measures, value, causes, and REAL business requirements deliverable _whats_ that provide REAL value by achieving objectives when satisfied by some product/system/software.
You can find out more in my seminars, book, and articles such as “BAs Will Falter Until They Learn to Discover REAL, Business Requirements” at
http://www.modernanalyst.com/Resources/Articles/tabid/115/ArticleType/ArticleView/ArticleID/1193/Default.aspx.