Some years ago, I was attending as a participant in a workshop for new managers. One of the sessions was a case driven one where a group of us were asked to work on a business problem and come out with solutions. The case was about a firm that was the market leader in mattresses and which has been losing market share rather heavily over the past couple of years and was looking for solutions to arrest the trend. There were a number of items mentioned in the 10 page case study including market information, financials, product variants etc., Our group was a diverse one with folks primarily from a technology background. We had a 1 hour slot to come out with some options.
Barely had we started reading the case, when one of the guys who was the oldest in the group and who had been a Siebel CRM consultant started out
Siebel Consultant: “Guys, this is a ridiculous waste of time. The solution is to implement Siebel CRM and move on. That should just help them get market share. I have done 7 Siebel implementations and every time the market share of the firms increased.“
“Hold on” came a rather harsh voice. It was a close acquaintance of mine who at that point in time had been asked to build a SAP Practice.
SAP Consultant: “SAP has just launched some cool features that will help their call center executives get upto date order information as it seamlessly integrates with the SAP SD and FICO modules”
I was furiously running through the pages to see if I saw the word “SAP” anywhere as I wanted to see where my SAP mate had got this rather interesting information. Another thing that intrigued me was the issue around call center executives for a firm which sells mattresses. Well stranger things have happened and I just listened to the group continue. It was now the turn of the Open Source guy, a Java expert to talk out
Java Expert:”Come on folks. The future is all about open source technology. While the packaged tools have their advantages, you need Java folks to build the interfaces to the legacy applications to ensure smooth flow of data”
The last part of the straw was the data warehousing expert who was skilled in a rather rare skill at that time (Ab Initio).
Ab Initio Expert: “Remember all these implementations are useless unless the management can have robust reports. Make sure that you include that as part of your solution”
Within a few minutes, what was mooted as a business problem became a technical architecture piece as each of the guys started talking about different ways to implement the system.
The meek “generalist” in me was overwhelmed with all this technical know-how and watched the drama unfold. One of the guys was actually polite enough to ask me about what I felt. I started out by saying “Should we probably look at the case to help define the problem”. This was met with a startled “You moron” looks and the group returned to their animated conversation.
When it was time to present, the CRM Expert proudly went to the board and announced “Our group has discussed the case and we think that Siebel is the way to go. We should implement a Siebel solution which will interface through Java interfaces with the SAP modules and support it with a strong reporting system in Ab Initio to provide management with the necessary reports to take the right decisions.” He then went on to describe how this can be implemented in a rather accelerated fashion using some assets (that his team has developed). He finished it with a rather arrogant flourish which seemed to indicate “This is just too simple for my level”
Our arbitrator who was a management consultant took a few minutes to digest the information and then started out what was actually a profound response.
“Team, excellent solution. But can somebody just tell me as to what problem is this solution intended to solve? If you had bothered to look at this case properly, you would have noticed that it is about a mattress company that is losing market share. It is also rather intuitive that Mattress firms don’t sell their products through a call center. A little bit of analysis on their financials and product portfolio would have told you that. And you are telling me that you want to implement a Siebel-Java-SAP-Ab-initio solution which will generate reports that will very likely tell me the info that I already have today?”
While this may appear rather intuitive, this kind of behavior is increasingly becoming the norm today. People are ever so eager to apply their skills on problems that they don’t bother to define the problem in the first place. As my boss once said “This is akin to a doctor who performs a heart surgery on a patient (because he is a surgeon) only to realize that the patient actually came to him for a common cold”
A close pal of mine who is looking for the next big job opportunity thinks that getting his resume updated by an expert will probably help him get that coveted job. Again a great solution but what is the problem that he is trying to solve? Does he have evidence that his existing resume is sub-standard? Not really but somebody mentioned it as a solution which has got his thinking going.
Problem definition is the first and the most important step in any problem solving exercise. It is very important to hold on to solution finding till we have probably defined the problem. But any good problem definition requires the participants to analyze the landscape fully and come out with the right facts that would help put the jigsaw of the problem in perspective. Many a times, people come to the table with half-done analysis and then try to define the problem in a haphazard manner which further confounds the problem solving. A common mistake is to identify a symptom and conclude that it is the problem. A headache is rarely a problem but is a symptom. The problem for this symptom could be as drastic as a brain tumor or as simple as not having had adequate breakfast. To identify which is the problem, the physician has to systematically go through the diagnosis including analyzing various medical reports. Only then is a solution recommended.
A systematic approach to problem definition will go a long way in finding the right solutions to the problems. It will take effort but it will be well worth it as very often than not, solutions turn out to be very simple once the problem has been properly defined.
8 comments:
Ram, analysis of this topic is really an eye-opener.
In addition to business/office problems, I guess this also applies to many of our day to-day home life. Many times, I & my wife argue on the solutions without defining the problem clearly.
Well Kumar, you are not alone there. Especially at home, emotions and biases rule the roost and completely colors our ability to define the problem.
nice analysis, and unfortunately this is what happens in real life situations as well and not just in case studies. A large number of IT folks are hell bent on getting the technology solution right rather than thinking of the problem
Well Raghu, that is indeed a problem and also an opportunity for the smart ones :)
True Ram. A very good blog.
As the adage goes -
If you have a tool as hammer, you tend to view all problems as nails.
You hit the nail on the head!
Rams, Nice analysis and well articulated. However, I have a followup Q.
Do we need to pay attention to the low-level details for every task that are part of our daily chores? Consider an example of a busy Doctor's daily consultancy services. Many patients comes to a physician in a flu season with a complaint of fever, While the Dr knows very well that fever could be a potential symptom of Cancer,HIV and many more serious ailments. However he gives a typical paracetamol and a anti antibiotic. and his medicine may not work for 1% of patients. If the Dr is trying to define the exact problem statement and asks many questions (due to fear of 1% failure ), he needs to spend 15 mins per patient instead of 5 Mins and the Dr would be ending up with 100% success ratio and treating only 33 patients per day instead of 100 patients (including 1 patient ill treated). Your analysis could be true for a typical solution architect who pitches in for a solution to a client, however may not work for a typical IT operations analyst who works on a incident management and knows his one solution (like restating the PC) would work for 10 different problems, especially when the IT operations analyst performance was measured based on number of tickets closed per day instead of number of tickets reopened. I guess my analogy was, we need to know when to spend time on defining the problem statement also important.
Post a Comment