The Business Analyst (BA) is one of the key roles in any software development project. Many times it is their work which makes or breaks a software project.
But the job description of what a BA needs to do is a bit blurred as: 'the Business Analyst do not have a predefined and fixed role as they can take a shape in operations (technology architect or project management) scaling, sales planning, strategy devising or even in developmental process! Hence they get a different name for the played role. Even the International Institute of Business Analysis and its associates have had several editions of the roles and responsibilities of a person undertaking the Business Analyst (BA) role' (Wikipedia, 2008)
What does a BA really do?
This was a question I had for a long time. Consider this: the client gives the requirements, we code to those requirements, the QA assure that we meet those requirements, and the end-users use the software, where is a BA in this workflow? If there was one, what do I expect him/her to do?
To me, for a long time, a BA was someone who spoke about development to the end user & spoke end-user to the development team - neither groups really quite understood anything the BA said. So, a BA was someone to be avoided to get a successful project out of the door, period.
So, what does a BA really really do?
The answer stuck me one day when we were celebrating the release of a successful project in a restaurant. Ironically, we did have BA's on the project and we did not invite them for the release celebrations.
Toward the end of a really enjoyable meal, I happened to notice our waitress for the evening. Yeah - that was the moment I fell in love - not with the waitress, but with the profession of a BA.
I understood that BA's need to be like her and that their job profiles were very similar too. In my next project, I would definitely have a leggy, blond waitress!
Really Now - What Does a BA Do??
The Waitress we had took my complicated order, made a few nice suggestions of what I should flush it down with, conveying a deep understanding of what I needed (even through my thick Indian accent), assuring me that the food would turn out to be exactly like I wanted, went back to the chef with: "A Ceaser's Salad and a Diet Coke, table 13".
I got my order done perfectly & served with a dazzling smile. No wonder I was hooked, to the food of course.
So, BA = Waitress
The Waitress understood my need for food in my terms. But at a different level, she also understood what I was asking technically. When she went back to the development team, she spoke GeekSpeak to explain exactly what I wanted to the Geeks in the kitchen.
Her ability to converse both sides did the trick, in the process she did some value addition for me in terms of the drink I ordered, and generated extra income to the restaurant. It is this ability which I understood was most vital for a successful BA.
This lead me to re-define a BA as someone who understood enough of the business to make a meaningful conversation with the clients and who understood enough of the techinal aspects to be able to translate them to the development team and add value in the process.
Unfortunately I still find a lot of BA's who focus solely on defining an existing process for a software project, but don't have the technical ability or the drive (sometimes, both) to define what it means in terms of the development effort. In this process, software is loosing out in providing value to the end business.
After all - what is the value added if you have spent zillions of dollars automating your excel sheets? Nada, nothing - you just have an automated version of the same old way of doing what you were doing before. I am sure the development community need BA's who suggest Diet Coke & tells the chef that it really is Ceaser's salad that the client wants.
So the next time you see a BA's resume & feel inclined to hire that candidate, do check out if they have some experience waiting tables successfully.
Sunny, IT.Wox (www.itwox.com)