Occupation commonly found within an
information-driven organisation. A business analyst (or BA) is the meat in the
sandwich between the people who devise projects (
sponsors), and the technical staff (
techies)who actually do all the coding and implementation.
They navigate the different viewpoints, interests and egos from both sides, and ultimately bring projects to completion. Thus they need both knowledge of business processes and some technical expertise to liaise with both sides, plus their own design and testing methodologies particular to their profession (such as Edge or Agile). They then check to see what capabilities their system has to meet business requirements and gives general support to the techie to do their job.
BA's communicate using user specifications (which usually are cut-and-paste versions of earlier specifications with earlier irrelevant stuff embarrasingly left in). They also like entity and data-flow diagrams (which they do with the kind of smile of accomplishment that you see on a two year old who just mastered toilet training). Unfortunately, most coders find system analysis torturously boring and irrelevant, and although they usually can find something wrong within the BA's proud work, they dare not raise it in a walk-thru less their morning is hijacked debating a moot point of Cobb's law. Instead, both the BA, coder and the sponsor find pseudocode a far simpler and more humane method of communication.
To date I do not believe any child has ever sat on Santa's lap and said they wanted to be a business analyst when they grew up. It is easy to understand why : the profession can be quite myopic and focussed on specific industry groups and processes, but a BA will never enjoy the perks of jet set corporate life like strategic planning or wining and dining clients. Instead, until their retirement day (when they can look back at a lifetime of writing user specifications for the printing of electricity bills), they are regarded as goffers by sponsors and masochistic failed programmers by techies. In a worst case scenario, a business analyst could orientate their self-identity and self-value on an obscure piece of business engineering, and take things very personally if somebody reckons it is redundant.
But good ones are definitely worth their weight in gold, and if they are prepared to move out of their comfort zone they could do very well for themselves in private practice.
So, what frustrates a BA ?
sponsors who don't know what they want.
sponsors who keep changing their minds.
sponsors with a love for vague buzz words strung in long passive-voiced sentences.
sponsors who think they can do the coding themselves.
technical staff who speak to them in long-winded technical jargon with the only understandable words being can't and unable.
technical staff who design systems the way they want it to be ...nice though the abattoir.
technical staff and sponsors who choose to speak to each other and sideline the BA.
technical staff and sponsors who refuse to speak to each other and force the BA to take sides.
technical staff and sponsors who cooperate with each other to blame the BA if something goes wrong ( we had a miscommunication...).
technical staff who quit half-way through a project.
sponsors who loose their funding.
either staff who mistakes a BA for a coffee wench.