On Problem Solving

In my last project, the following discussion took place between me and a colleague. A bug was reported in a module that was supposed to be stable. As the bug was least expected, I had a discussion with the team members. The discussion went on like this.

Me: what is the problem?
Team Member: a comparator function is failing .
Me: how much time will it take to fix the problem?
TM: 3 hrs.
Me: why three hours if it is only a comparator function?
TM: … [No answer.]
Me: We are using a framework. Am I right?
TM: yes.
Me: Is the comparator function you are talking about a framework provided one?
TM: Yes.
Me: That means that the function you are talking about is being reused….
TM: Yes.
Me: That means that your problem statement is not 'a comparator function is failing' but 'a comparator function that is working in other places, is failing here'.
TM: Yes.
Me: you get maximum 30 minutes to fix this issue.

In 15 minutes, the member came back happily and said that he had fixed the problem and we delivered the fix to the customer as soon as possible.

I am sure that the team would have identified the problem even without this conversation. But the whole event set me thinking. Just a few questions and we were able to bring down a 3 hour job down to 30 minutes. I was wondering about the whole event, our ability to ask the right questions to understand the problems we face, about the cases where without proper thinking/ understanding the problem, we loose lot of time and in the process, delay solving the problem.

At school, we are first taught elementary arithmetic and then move on to solve problems. In all these cases, the problems are given to us and we are asked to solve it. The more difficult part was solving the problem. But higher education is very different. Here we are expected to define the problem statement and solve it. My Masters Thesis in Physics was all about forming a non-linear equation and solving it. The more difficult part was forming the equation and solving it was easy.

This has got lot of similarity towards the situation we face in real life. If we take the example of the comparator function, we have the know-how to solve the problem (which is functional knowledge and java knowledge), but we didn't know what the problem statement was and were looking at the wrong problem statement. Obviously, it is not going to be any easy since the problems that we come across in business or project management presents itself in an intangible way. We are no longer presented the problem and asked to solve it. We have to define the problem, solve it and see whether the solution satisfies our needs.

I was searching around to see if there is a way to make people look at issues presented in a more systematic manner, help people identify similarities between issues, how to make certain assumptions that are right and help us in actually solving the issue, how to ask questions and understand what the issue on hand actually is. I came across this book by George Polya titled 'Problem: How to solve it'. This book is a must read for all Software Professionals, starting from the Developer and upwards. This is a 'must read' because this is one of the few books that actually suggest a Systematic approach to problem solving.

I have given here the essence from the book and modified it for project management kind of problems. There is a difference between project management and programming issues as the unknowns and intangibles are more and the problem space is bigger in the case of project management issues. But the essence is that a problem is a problem, how we solve it is more important. A computer is just a tool that helps us in the whole process. That is all.

Please note that many or all the points mentioned below may not be new to the discerning reader. The fact is that this article doesn't claim to give anything new on problem solving, but aims to remind people what they already know and ensure that people consciously follow these steps when they have an issue to solve. People actually do many of the steps mentioned here unconsciously. The disadvantage is that we are struck for the lack of a systematic approach, when we find ourselves facing a difficult problem/issue.

Step 1: Understand the Problem [Identify the goal]
The first step is to understand the problem and make sure that we understand it clearly. This can be achieved by asking the following questions:

Is the scope of the problem clear i.e. are we very clear on what it is that we have to solve? If not, we should not get into solving the problem .
What are the unknowns? The unknown is usually the final solution that we seek. But in project management kind of problems, the end result is known. It is usually reaching a fixed target or ensuring that our goals are met. Most of the time, it is the means to reach the end that is not known.
What is the data available to us?
What are the given conditions? What is the environment in which we have to find a solution? ( Environment is an important factor in the final solution for e.g. a bug identified during system testing and during UAT need different kind of approaches)
Are there any constraints? Constraints can be anything like people availability, money, time, lack of knowledge and other resources. People have to understand that only in an ideal world will a problem not have any constraints.

Step 2. Devise a Plan

Once we have asked the above queries and have the answers to these queries, we have to find a connection between the given information and the unknown that will enable us to calculate the unknown. It often helps to ask explicitly:" How can I relate the given to the unknown?"
If we are not able to see a connection immediately, the following ideas may be helpful in devising a plan.

Establish sub goals (divide into sub problems): In a complex problem it is often useful to set sub goals. If we can first reach these sub goals, then we may be able to build on them to reach our final goal. This is something that we all do when we manage a project by splitting the project into phases, phases into milestones and milestones into tasks and so on.

Try to recognize something familiar: Relate the given situation to previous knowledge. Look at the unknown and try to recall a more familiar problem that has a similar unknown or involves similar principles. This can be done by asking the queries "have we executed a similar project?", "Have we faced a similar issue?" and "do we know some one who has solved a similar problem?"

Try to recognize patterns: Some problems are solved by recognizing that some kind of pattern is occurring. If we can see regularity or repetition in a problem, we might be able to guess what the continuing pattern is and then prove it. [This is one reason experience and reading about other people's experience count. This enables us to develop a base of patterns!]

Use analogy: Try to think of an analogous problem, that is, a similar problem, a related problem, but one that is easier than the original problem.

Introduce something extra: It may sometimes be necessary to introduce something new, an auxiliary aid, to help make the connection between the given and the unknown. An example can be bringing in an expert whose expertise can be made use of to solve the problem.

Take cases: We may sometimes have to split a problem into several cases and give a different solution for each of the cases. We should not try to generalize the problem and try to identify a generic solution. Many times, solving the issue/problem for the particular case that we are facing is good enough. The generalized solution can wait or there won't be a need for the same. Prioritizing can also help when there are multiple scenarios.

Work backward (assume the answer): It is often useful to imagine that your problem is solved and work backward, step by step, until you arrive at the given data. This helps a lot in Project Management. Instead of asking 'how do I get this person to solve the problem?', if we ask, 'what should be in place to solve the problem and does this person have the capabilities?' then the whole problem takes a different perspective.

Indirect reasoning: Sometimes it is appropriate to attack a problem indirectly. Trying to understand why the problem is there and whether it is actually a symptom helps. Employee attrition (symptom) can be due to a poor project manager and handling the poor project manager is the best way to solve the problem. Anything else will only be a short term solution.

Step 3. Carry out the Plan
In step 2, a plan was devised. In carrying out that plan we have to check each stage of the plan and write the details that prove that each stage is correct.

Carrying out the plan in project management scenario is the most difficult part and how well we execute the plan determines how successful we are. The following tips help us when we execute our plan.

• Be patient – most problems are neither solved quickly nor on the first attempt.
• If a plan does not work immediately, be persistent.
• Do not let yourself get discouraged.
• If one strategy isn't working, try a different one.

Step 4. Look Back

After we got the solution/result that we wanted, we have to look back and analyze the steps that we have taken to arrive at the solution. Many a times, we don't get the opportunity to do this step, as we move on to some other pressing issue. This can also be done later, when we have free time and is ok – as long as the purpose of doing this step [Looking for flaws in our solutions ( e.g., inconsistencies or ambiguities or incorrect steps)], is met.

Checklist of checks:

• Is there an alternate method that can yield at least a partial answer?
• Will the same approach work for some similar but simpler problem.
• Trends. Does the answer vary as you expect if you vary one or more parameters? For example, if number of person days is involved, does the answer change as expected if you vary the factor?
• Check limiting cases where the answer is easy or known. Take the limit as variables or parameters reaching certain values.
• Check special cases where the answer is easy or known.

The above points are very important since this helps us in the following ways.

• Ensuring that our approach is optimized and can be made in to a process ( of course subject to certain limitations) or
• It can be made into a lesson learnt and can prove to be a beacon to people on solving issues of similar nature .

In the example I gave at the start of this article, had my colleague thought through the problem, he would have had an answer ready when I asked the question about the time. Even if it were three hours as he mentioned, I would have been ok if he had had an explanation. This brings us to another important point.

We are all answerable to some one for our actions (no I don't mean it in the philosophic sense :-)) as project managers. It may sound contradictory, but higher our position is, the more people we are answerable to. If a person is a developer, he is answerable to only the team lead. But as a project manager, we are answerable to our subordinates, superiors and customers. As Uncle Ben said to Peter Parker in the movie Spiderman, " With Great Power, comes Great Responsibility ". So it is even more important that we have the right answers for the problems that we face and I am sure that the steps mentioned above will help us.