4 questions to ask before tackling a problem

In almost every single survey of employers and leaders on essential skills needed to succeed at work, Problem Solving (or Analytical) Skills ranks in the top ten.  These skills are needed to help us face and resolve difficult situations that we will face in our profession.  The problem may be technical or one of management. 

Some of the main reasons a problem may be a tough nut to crack are lack of clarity, incomplete information, multiple goals, complexity and time constraints.  Problem solving techniques such as Root Cause Analysis, Brain Storming, Lateral Thinking, Divide and Conquer and Reduction are commonly used to help us solve problems.  Problem solving methodologies like the GROW and PDCA models and Kepner Tregoe have gained much acceptance in the IT industry. 

While Project and Program Managers can benefit enormously from these techniques, I ask you, dear team members, to consider at the outset a few simple questions when faced with a problem or issue in the course of working on incidents or Service Requests in your projects.  These questions will help prevent you from barking up the wrong tree at the outset, and can save you considerable unnecessary pain and effort.  These questions are:

  1. Is this problem really for me to look at?  Or will it be more appropriate for someone else (or some other team) to tackle?
    If it turns out that the issue can be fixed by some other team, the client is best served by transferring the problem ticket to this team immediately.  If the ticket is a high severity ticket, a phone call as follow-up will ensure prompt resolution.  Delays in doing this can prevent the correct team from having adequate time to resolve the issue before the SLA clock runs out on them.  Be pro-active and alert.
  2. If the answer to (1) is Yes, then a good second question will be: is this really a problem?
    Many a time, I have found that patient uncovering of the facts can lead to insights on what may not even be a problem.  The code behind a report with anomalies does not really have a bug when the root cause is corruption of the incoming data. 
  3. If the problem is real, then we can ask: do we understand the problem correctly? 
    A good way to ascertain that we have understood the problem correctly is to restate the problem in easy-to-understand language that all key people can agree upon.  It may well turn out that the root cause is uncovered at this point, as in the above example.
  4. Once we establish that the problem is real and we have understood it correctly, we can ask: what is the criteria for a successful resolution of the problem?
    This is a vital question as it brings focus and discipline to the task of resolving the problem at hand.  Examples abound where hard work has been followed by dissatisfaction and disbelief as the customer is not satisfied with the problem’s resolution.  If this step is done correctly, we may well identify an opportunity to improve the application / process.

It is said that experience is the best teacher – let others’ experience teach us so our clients benefit immediately!!  All the best in solving all your problems.

Ravi Bhuthapuri