CIO magazines article on the importance of BAs to IT and CIOs is an interesting read. In particular it reinforces the difference between BAs who slavishly “flog the dead template horse” and those who are communicators and analytical thinkers. Take a look at the article here. Which type of BA are you (really)?
I had one person explaining to me, that the role of a business analyst was similar to a waiter in a restaurant. Going to the customer, asking for his wishes, reporting them to the cook who then makes the dish.
Well, I don’t think that a business analyst should be anything like that. We do not need a person to replace the face to face comminucation between those who have the needs and those who try to make tools to fulfill these needs. Those who have a problem to solve and those who solve it should work as closely together as possible, with no intermediary in-between.
Helpful and sometimes invaluable is somebody who understands the daily business of different users, recognizes differences and similarities and thus can act as an informant to the developers. Especially if the real users are difficult to gain access or have little time.
Most IT project I encounter are in urgent need of a person who is able to address the customers need with a non-technical solution. Many issues and needs can be solved by making people work more efficiently rather than adding more complex technology to it. We need somebody to resolve the raging wars between departments, improve workplace and procedures, and generally is able to develop a company further.
Definetely we need somebody with a business vision. A person who knows why a project will significantly improve the situation and keeps a project to that vision.
Regards
Markus
I feel there are two additional roles here.
1) to Facilitate Communication: Often the Business people and Technologists use the same words, however, sometimes these words have different meanings in the two contexts. Highlighting differences in meaning may seem trivial, however, it can be vitally important when trying to get the job done.
2) to ask Dumb Assed Questions: Okay, so there is no such thing as a DAQ. I have repeatedly ask dumb questions in my requirements analysis roles and, more often than not, I get multiple different answers or even synchronized head scratching (which confirms the DAQ’s are worth asking)