The Community Blog for Business Analysts


How to solve problems?

As an analyst I almost daily have to solve some kind of problems and I bet you do also. Problems can be in different forms, but I’ve been noticing that the same pattern for finding the solution keeps coming up. I think this pattern is something essential and we use it often but i think it is a good idea to put it on paper.

First, every problem has its parent problem. Yes, EVERY problem! This means that whenever you have a problem you can ask why is it a problem and where it comes from. Consider an alcoholic. Is too much drinking his problem? Probably yes, but there is always the root problem that made him drinking in the first place. Depression maybe?

Now if we forget about alcoholic and think about software development then we can see that the idea stays the same. Our clients are those whose problems we mostly have to solve. For example, if the client comes and says that he needs a button to the user interface.The client has a problem that there is no button currently. This problem has a root problem… maybe the client wants to open a file with this button. The client definitely does not want a button but something else and he/she thinks that the button is going to solve some kind of problem.

We now know that instead of a problem we have a stack of problems. But how can we solve our problem then? The short answer is that we often don’t even have to solve the initial problem. It is OK if we manage to solve one of the root problems. From the previous example, it is fine if we don’t make the button but we manage to do something that the user gets the right information. Or even maybe the user does not get the information but gets the right answer to whatever he/she has to decide automatically. The initial problem is not solved, but the root problem is and we can consider the whole problem solved.

We can also model a process for the problem solving. It makes use of the problem stack and I think I use it very very often. The main idea is that every time the client asks for something, then I analyze two things:

  1. how it could be done
  2. is it relevant

There is always some kind of solution that we may consider the best to this certain problem, but we have to decide two things – is it doable and is it reasonable. The solution is probably not doable if it would take 10 years and too much $$$. If the answer to one of these questions is “no” then we have to move down in the problem stack. We have to focus on the root problem, because the child problem was “unsolvable”.

We have to move to the root problem until we end up with a reasonable and doable solution. This does not mean that we don’t have to think about the root problem before, but by moving down the stack we set our focus to some certain level. It is so easy to solve a problem! :)

Note that this idea is somewhat connected to the root-cause analysis. Read more about this here:


Karl Blum (
My blog:


This entry was published on Apr 26, 2010 / Karl. Posted in Analytical and Problem Solving Skills. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  1 members liked this article

Related Articles


zarfman posted on Wednesday, May 12, 2010 2:10 AM

You wrote: The main idea is that every time the client asks for something, then I analyze two things:

1. how it could be done
2. is it relevant

Zarfman asks: what is relevant? Do you mean is the problem relevant, the solution. I'm not following your very well.

The diagram as the end of your post is interesting. I feel that in actual practice you are at the mercy of your staff. BA's, systems designers, programmers and database people.

In my experience these skill set competencies very wildly from one individual to another. Moreover, when very significant difficulties arise, ones staff may not have the high level competencies to solve the problem at hand.

Moreover, in your diagram there is a three part lag. you must find the problem, then develop as solution, try the solution did it work yes,no,maybe. depending the length of these lags and the number of iterations and the effectiveness of the solutions. One can eat up some serious time.


Karl posted on Thursday, May 13, 2010 1:18 AM
Zarfman asks: what is relevant? Do you mean is the problem relevant, the solution. I'm not following your very well.

We assume the customer has some problem and he has proposed a solution. Then we have to figure out if the proposed solution is indeed relevant - does it really solve the problem?

Only registered users may post comments.

Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
11 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC