"We have had a series of power outages even though we have central and local uninterrupted power supply (UPS) systems. This disruption causes a loss of service to our customers. While we don’t necessarily lose data, it’s an irritant, and also results in loss of productivity. Perhaps we could attribute it to the lack of adequate UPS capacity. Alternatively, the independent UPS systems also contribute to the disruption, as we don’t keep track of these stand-alone units. Neither do we perform any maintenance on these units; thus some of these units may be past their useful life. This is generally accepted practice but not what’s called for in our procedures. We understand that this is reality and there will always be stand alone UPS units. We really need to solve the problem to avert future disasters. By the way, we don’t even know how many of these units we have in use and although our policies don’t allow the use of these stand-alone units, I have seen them in the IT department itself.”
This paragraph does not provide a clear problem statement; rather, it’s background information that helps in understanding the importance and relevance of the issue. You have to dig through this commentary to find the real problem. Often these types of statements are presented as problem definitions, when in actuality you have to sift through them to find the real issue.
A clear problem definition should transform the issue into a logical, sequential problem that can be investigated, analyzed, and solved. It should provide clear and common direction. When used as the context for a team activity, it should reflect the members’ purpose for getting together as a team in the first place. It should help establish clarity of the scope of the problem that the team has been asked to resolve.
“Well begun is half done” is an adage that’s true in problem solving, whether these are lean or Six Sigma projects. Many times projects are jumpstarted by either collecting data or implementing solutions without coming to a common, clear problem definition. Team members have their own definitions and assumptions, but don’t always recognize them.
An easy way to remedy this common problem is to take the time in advance to develop a problem statement and clarify any associated terms, background information, or assumptions. Starting the team at the same point will eliminate confusion and subsequent rework later. When coming up with a problem statement, think “action orientation.” Here are a few examples of potential problem statements:
- How to reduce the number of UPS power failures
- How to reduce the use of standalone UPS systems and the related power outages
- How to prevent power outages in the IT department to reduce possible loss of data
They all come from the same information and each of these statements leads a problem solver in a different direction. Each problem definition is concise and clearly states the expected end result of the problem-solving effort. It’s easy to understand and includes a statement of purpose with associated goals and leaves nothing to ambiguity. It doesn’t include any of the fluff seen in the earlier problem description. Clear deliverables will drive the type and activities associated with data collection and analysis.
This doesn’t mean that background information isn’t important. It provides a potential problem-solving team with general information to understand the topic and provide context for the issue and the associated rationale. Background information should be included for all available data or any related initiatives (successes and failures). The big picture should be kept separate from the problem statement itself. Many organizations spend a lot of time solving problems, yet don’t take the upfront time to state the problem clearly and succinctly.
Comments
Try the Problem Pyramid™
You are so correct that the problem often is not articulated adequately, which means the solution probably will be less effective and less efficient than desired. However, I've found that even consciously using conventional "problem statements" often misses the mark, because they tend to focus on complaining and pain points rather than identifying what actually is the problem. In contrast, the Problem Pyramid™ tool/technique described in my book and requirements/ROI seminars provides a much more systematic and disciplined way to get to the REAL problem/opportunity/challenge and REAL business requirements for solving and thereby achieving quantified REAL value.
Author of the recent Artech House book:
Discovering REAL Business Requirements for Software Project Success
Add new comment