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:

how it could be done

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!

Related Articles

COMMENTS

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.

Modern Analyst Blog Latests

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-...

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...

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