The Community Blog for Business Analysts


Come to me with problems, not solutions

 “Bring me solutions, not problems”. How often have we heard those words uttered by management? In the main it’s a sensible ask however, for a Business Analyst, quite the opposite is true. Our job is to define business problems when often we are presented with solutions.

“We need a new reporting tool because the MI we receive isn’t always correct”.

We could initiate a project on this basis; gather detailed requirements, develop a new reporting tool and roll it out across the organisation but would this address the issue and if it did, would it really be the most effective way to do so?

Could it be that there is a problem with the data entry or with the way the MI is being interpreted?

The above problem statement is merely a symptom of a problem and does a poor job at describing what the real problem is.

Would a Doctor simply prescribe pain killers to a patient who complains about headaches or would he probe further, try to identify the reason for the headaches and offer treatment accordingly? So too must the Business Analyst probe deeper and recommend appropriate options.

The above illustrates why we cannot always rely on stakeholders to provide an accurate problem definition alone. There are other reasons too. For example, different stakeholders will have different (and sometimes conflicting) perspectives on the problem and for that reason, it is essential that the right people are engaged and the right information is elicited.

CFO - “We need a new reporting tool because the MI we receive isn’t always correct”

MI & Reporting Manager - “I need more resource because the demand for MI exceeds our current capacity”

Senior MI Analyst (Team Lead) - “There is too much re-work” “Team morale is very low”

MI Analyst - “The reporting suite is to complex. The MI that I provide is always correct but I’m often asked to redo work with slightly different parameters”

Night Watchman - “I’ve no idea. All I know is that boy seems to work awfully late!”

So maybe you might not interview the Night Watchman – but useful information does often come from surprising places!

In order to develop a true problem definition we must explore and challenge all of the problem statements that we have captured. In reality, there will be many and we must analyse each in turn to develop a short list of problem candidates.

There are many ways to explore the problem statements some common techniques are:

- 5 Whys

- Root Cause Analysis


An explanation and templates for these techniques are readily available online.

Once we have our problem candidates, we should assess each of them in turn to determine whether they are in scope, relevant, a true problem or feasible. This should then lead to a clearly defined problem definition or in some instances a number of defined problems. When a number of valid problems are identified, the Project Team and Sponsor should decide which one to address.

So, the final step will be to get the problem owner to confirm and accept the problem definition but remember, never, ever go to management with a problem! Not without an appropriate solution anyway!

- See more at:

This entry was published on Mar 28, 2014 / Pjbussol. Posted in Business Analysis, Analytical and Problem Solving Skills, Career as a Business Systems Analyst. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  7 members liked this article

Related Articles


Only registered users may post comments.

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


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.


Copyright 2006-2024 by Modern Analyst Media LLC