The Problem is...Your Problem Statement Sucks
My father was a Master Electrician. He learned his trade while serving aboard a Balao Class Diesel-Electric submarine in the early 60s. Like many tradesmen he would constantly be asked to do some "side jobs" by friends and family. I learned the craft from him, serving as his apprentice during these unsanctioned works. I was 9 or 10 when I started.
My Father loved his trade, but the one thing that ALWAYS got him frustrated was when he'd have to come in behind someone who first tried to do the work themselves, made a mess and then wanted him (and tradesmen like him) to fix and/or finish the job.
"It would have taken half as long and I would have charged them half as much if they'd just called me first". Today, as a professional problem solver, I feel his pain. Many business owners and executives think that because they're in charge they're supposed to have all the answers, so they focus on providing answers instead of asking better questions.
By the time I'm brought in there is usually a complicated maze of issues all tangled around a bunch of unnecessary processes and tools and worse, the team is exhausted and demoralized by the issue that just "can't be fixed".
Far too often the biggest problem plaguing an organization is that they jumped right into problem-solving without spending enough (if any) time defining the problem and its potential contributors.
The problem statement really needs to be a statement that clearly and completely captures the "pain" of the issue, nothing else. The hardest part of my job is remaining completely detached from the outcome, a position I recommend to any project leader in order to remain objective.
Here's my crash course on writing an effective and unifying problem statement.
- In one or two sentences, concisely describe the pain, all the pain, and nothing but the pain. Be careful not to draw in prejudices.
- Provide background to set some context. This is best accomplished by setting extent, time frame, impact and conditions.
- Capture just how far the actual condition deviates from the established expectation or norm. If it's measurable, that's best.
- Now ask how this effects the customer. If you're not framing the pain in terms that effect the customer, you're not addressing a business problem, but more likely it's personnel or personal.
In my experience poor or weak problem statements are vague. The problem is defined as "too" this or "not enough" that, quantify the problem whenever possible. Next be sure you trust your measurement system. If your problem statement says "always" or "never" you've accidentally included bias or qualifying information instead of facts.
But, by far the most common failure in problem statement writing that I see is the inclusion of a solution within the pain. There shouldn't be any conclusions in a problem statement like, "therefore" or "so we need to".
And last, but not least, always strive to include the voice of the customer. After all the elimination of their pain is the real goal.
Please let me know what you think by commenting below.