Self Reflection and Correctly Defining Problems
In part four of my six part series, I am going to discuss the importance of problem definition. This is one of the topics I am most passionate about and will sure to be expanding upon in other posts.
If you have not read my previous posts and what this is all about, head on over to my first post Words of Wisdom and a Customer Focus which describes my self-reflection journey. After that you can check out What it Means to Take Ownership and Self Reflection and How to be a Dot Connector.
As we have done previously, here is the email I sent to my team and what reflection I have had six months later.
A Problem Well Defined is a Problem Half Solved – Charles Kettering
“Go slow to go fast and use 5-whys to really understand what your customers want (need). I modified a quote (italics) from the book “Winning the Brain Game” to remind myself of this every day:
What initially appears to be the problem, isn’t
What initially appears to be the solution, isn’t
What initially appears to be impossible, isn’t
Don’t jump to conclusions. Correctly identifying the actual problem and not the perceived problem drives the success or failure of what you do and is the single most important piece of problem solving. Most people think of “cost” as real money, but cost can also be opportunity cost. The cost of defects, in either real dollars or opportunity cost, exponentially increases the further along in a project you go. The more you do up-front (ie “problem definition”), the better your solution will be and the lower the “cost” will be. Below is a diagram of the cost of defects (problems) over the lifecycle of a project, so find the flaws early and save yourself the headache.”
As I mentioned, this is one of my favorite topics to talk about because it can be applied so many different ways such as data, analysis, and reporting or project management. Now that I am back in a traditional process improvement role, my passion for this topic has only strengthened. The reason for this …I love change, but I hate re-work or change without purpose.
Going back to the quote that I modified, I want to expand upon that’ Let’s start with why I added the word’s “initially” to May’s Winning the Brain Game quote. So many times in the business world, especially in Information Technology (IT) where I previously spent a good amount of my career, the initial problem is actually the perceived problem so therefore the initial solution is really only a Band-Aid. It is important that we identify the real problem before solving it. I recently read an article that said leadership needs to stop with the mindset of “I don’t want problems, I want solutions.” Another way to look at correct problem definition is, “I don’t want solutions, I want problems.” I say this because many times customers or leaders come to a group with a “problem” but really it is a “solution.” Let’s check out on of my favorite examples of a perceived problem initially being confused with an actual problem and the customer presenting the solution as part of the problem definition!
The background is my team was also responsible for help-desk type functionality for a healthcare electronic medical record (EMR) and one of the taks for this role was taking enhancement suggestions from customers. The following is how one request came in and how it was presented to me by my team.
Customer: “We need a second after visit summary (AVS) that only shows the patients’ upcoming surgical cases”
My Team Member: “Why do you need this information?”
Customer: “Because we are wasting paper printing the AVS twice and throwing the first two pages away just to keep the surgical case information.”
It was at this time that my team member came to me because she knew that the word “printing” gave me heartburn. When she came to me and summarized the conversation, I expressed concern that we hadn’t really gotten to the root of the problem. The perceived problem was the wasting paper and the perceived solution was a new report they could print with only their desired information. I have seen these kind of things enough to know that “What initially appears to be the problem, isn’t” and “What initially appears to be the solution, isn’t.” So let’s continue…
Me: “What are you doing with this extra page with the surgical case information?”
Customer: “We are faxing it to the surgeon’s secretary”
Me: “What is the secretary doing with this fax?”
Customer: “He is adding the case to the surgeon’s Outlook calendar.”
Me: “Why does the surgeon need the case on their Outlook calendar when our tool already has a calendar?”
Customer: “Because the surgeon wan’s both her administrative appointments (in Outlook) and clinical schedule (in the EMR) on one calendar.”
Me: “So what the surgeon actually needs is the tool that another team is developing that syncs these two calendars together. Let me put the surgeon on our list of pilot customers.”
Do you see what happens when you correctly define the problem? If we would have totally stopped where we initially did, we would have had a “happy” customer because their perceived problem would have been solved. The surgeon would have remained happy because this change wasn’t going to change their schedule (both current state and desired stated both ended with the Surgeon getting their calendars in sync). The issue though was the initial solution (a new report) was not good for the business. Why do we need all this extra people, process, and paper to solve a problem that a technical solution was already being developed to solve this actual problem?
There are many tools and techniques to help correctly identify the problem and if this is something you are interested in, stay tuned because there is a lot more posts on this topic coming.
If you are not already following me on LinkedIn or Twitter to get my updates, please follow me. Alternatively, fill out the form on the Contact page and I will add you to my email list for when I post topics you are interested in.