Business Analyst Community & Resources | Modern Analyst

The Creative Business Analyst - Part 1

14697 Views

3 Comments

2 Likes

Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.

We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.

To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.

Author: Jan Kusiak

COMMENTS

Analyst_Naren posted on Saturday, November 1, 2008 10:15 PM

I completely disagree with the statement that Business Analysis has always been about 'gathering' requirements and converting them into specifications and only it i changing....

Business Analysis has always been about understanding business problem and designing a solution. As part of the process we 'elicit' requirements from users (which can be done only after we understand the problem 'as is')
Being a BA with formal education and experience in Business Process Re-Engineering, I do not like the use of the term 'gathering' which implies the requirements all there ready with the users, and all we do is 'gather' them.
We really have to 'elicit' requirements using good techniques and smart questions, which again can be done only after we understand the problem.

Jan posted on Tuesday, November 4, 2008 4:52 PM

Joel is completely correct as the second paragraph in the paper tries to state. As a training provide we see 2 types of analysts, those in more junior roles who quite literally just document requirements and the more senior ones who actively work to change the business. The paper's objective is to broaden the horizons of the more junior ba's. Elicit is not a word much used by us antipodeans although it's meaning is 100% applicable in this context...Jan Kusiak

Lakshmin posted on Monday, February 22, 2010 11:15 AM

@ Jan K this is Lakshmin and am relatively a kid inside the BA world. I concur to JanK's point.

@ Joel --> I believe as a Industry BA people define "Requirements gathering" where they use "Elicitation techniques". Most of the BA's do unfortunately serve as interface between busines and IT potentially with or without the systems knowledge or rather not at a detailed level which allows them to think outta box solutions to ask "why this and why not this way?"

I am sure both of you peers agree to the statement that doing a BA role is not guidelined, as we guys tend to wear multiple hats during a project activity and its one's own passion as a BA to create the value addition. The "Role" gets well defined when there is passion for what you do....