So, what does a Business Analyst do? We analyze the business! Just kidding – that was a cop out! I’ve gotten this question in one form or another a few times recently, so I thought I would post my thoughts on what a business analyst does within an IT organization. It should go without saying, but this is my experience only, and experiences can vary greatly from organization to organization.
Simply put, the business analyst (BA) is the bridge between the needs of the business and the needs of the software developers who are actually writing the code to fulfill the needs. If you ask the customer what she wants, she will probably say something like, “I need a website that has my contact information and my picture” (apologies for the boring example…I’m trying to keep things simple!). The software developers may ask a few questions, but would probably go to work developing the website for the customer.
Fast forward to the developers saying “we’re done” and the customer seeing the website. Hmmm…it’s nothing like what she thought. She wanted a simple black and white theme, they added lots of color. She wanted her picture in a circle shape highlighted in the center of the page, they put it in a square in the upper right-corner. They thought by “contact information\” she meant e-mail address, when in reality, she was more concerned with physical address and telephone. The customer thinks: It’s all WRONG!
However, the developers argue that they fulfilled their end of the deal: what she asked for was a website with her picture and contact information, and that’s what she got. Who is right here?
I hope this example illustrates the importance of the BA role. Just imagine how important it is for the business analyst to bridge the gap on much more complex (and expensive!) projects. The business analyst meets with the stakeholders on the project and asks lots of questions: questions to uncover what is truly important to the stakeholders, what is a “nice to have”, what aspects may not be worth the effort for the reward, etc. The BA must filter out the “noise” from the valid requirements elicited from the stakeholder. Considering the viewpoints of ALL the stakeholders, the analyst then goes back and writes requirements (even if they are rough) to run them past the stakeholders. There will likely be some changes, and once the requirements are relatively stable, it is time to share them with the developers.
So far, the business analyst has done a lot of interfacing with the customer, uncovering his/her wants and needs and coming up with a solution. Now, the BA must take that solution and present it to the developers so they can get started on it. This requires the analyst to break down the big solution into smaller chunks so that progress on the project can be reported. If it’s all worked on in one big chunk, it becomes almost impossible to track if the project is on target or not.
Undoubtedly, the developers will come up with scenarios and questions that the BA didn’t think of. This is when the BA may need to go back to the stakeholders for clarification, or make judgement calls/decisions based on previous interaction with the stakeholders.
As soon as the developers have demo-able work, it is best to get it in front of the customer for feedback. At this time, requirements will (of course) change, and the BA may need to go back and update the tasks, and the developers will have some re-work to do. This part is never enjoyable for the BA, Development, or QA teams, but it’s part of making sure the customer is happy and that the solution fits their needs.
I’d consider the following skills essential to being a good BA:
1.. Listening/Synthesizing skills – Not only listening, but separating the important bits from the noise
2. Ability to take big problems and break them down into manageable chunks
3. Ability to focus (and re-focus) conversations on productive information
4. Motivation to understand \”WHY\” on the business side – what is the business need for the project? What are the highest priority needs?
5. Ability to communicate effectively with both technical and non-technical audiences.
Next time you get angry at your friendly neighborhood BA for “missing” a requirement, try to think of all the things a BA must balance in order to make both the customer and the development team productive and happy. It’s not an easy job!’