I had a stream of thought this afternoon – on the way Business Analyst’s think, and how that “way of thinking” can be applied to help define business problems. I thought I’d jot some of it down for my own future reference, and hopefully for the benefit of my readers.

Successful business analysts have an ability to draw ideas to their logical conclusions. An analyst’s work typically requires assessment of concepts following a progression from the general to the specific, and other times from specific to general.

Progression from the general to the specific is what Business Analysts are most known for. This is where we take a high-level business problem and objectives and decompose them into requirements that represent functions and attributes of a system or solution. Nearly every job posting you’ll see for a Business Analyst will mention this need to be able to elicit requirements and produce the accompanying documentation.

Less widely acknowledged – although equally important, in my opinion – is the progression of rolling up symptoms and side effects of business problems into higher-level root causes and problem statements.

Here’s a simple illustration of a logical thought progression during business analysis:

And the point is..?

It’s not rare that I hear about a business owner who has heard about a problem or defect or two and, based on a few scraps of information, is ready to dive head-first into solution details. More often than not, this approach will lead to a solution that addresses symptoms while leaving the larger, fundamental problem undiagnosed and unfixed.

Organizations seem to have a tendency to skimp on root cause analysis. It can be a wearisome job requiring time and intensive research. However, if we haven’t done due diligence to identify and solidify root causes of business problems, how can we have a level of confidence that our solutions are fixing them? I think this is where the BA can really add value outside the traditional “writing up specs” role.

If a BA can get involved with the business decision makers early enough and help ensure that symptoms are traced to their true causes (which, incidentally, often turn out to be the causes of multiple other symptoms) and the business problem is succinctly defined, then a project has a much better chance of successfully solving the business problem.

Summary & Conclusion

  • Business Analysts are skilled in tracing problems and ideas to their logical conclusions; from specific to general and from general to specific.
  • Business stakeholders often mistake symptoms for business problems because they don’t do sufficient root cause analysis.
  • Business Analysis skills can and should be leveraged to help define business problems.
  • Projects are more effective when they address real business problems and not just symptoms.

Wouldn’t we all rather be involved in projects that we know will effectively solve business problems?

Alright, thinking about thought is tiresome, so I’m going to put down the virtual pen for now. What are your thoughts on the topic?