Introduction
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 they '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 the developmental process! Hence they get a different name for the played 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 assures 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 and 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 BAs on the project and we did not invite them for the release celebrations.
Towards 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 BAs 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, and went back to the chef with: "A Caesar's Salad and a Diet Coke, table 13".
I got my order done perfectly, and 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 led 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 technical aspects to be able to translate them to the development team and add value in the process.
Unfortunately, I still find a lot of BAs 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 losing 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 BAs who suggest Diet Coke and tells the chef that it really is Caesar's salad that the client wants.
So the next time you see a BA's resume and feel inclined to hire the candidate, do check out if they have some experience waiting tables successfully.
