Business analysts: why are there so many of you?

[munkee]

It depends what level the BA had reached as a developer. If we are talking a few years, and the person bailed without having achieved much then that type of BA is a disaster amongst devs because they think they know something about how things should be implemented- but they only know enough to be dangerous.

Failed developers to not make good BAs.

The BA doesn't need to know anything about how things "should be implemented". That doesn't mean they aren't entitled to an opinion though just like the dev has an opinion on other aspects.

One of the core BA principles is to offer options not solutions. A requirement would fail its quality criteria if it infers solution.

Once again your view is skewed by only knowing bad BA's. That's fine though as I have said I understand your point of view.

[Lance]

The BA doesn't need to know anything about how things "should be implemented".

They should at least know what can be implemented though.

[Cirrus]

Back in the day of steam powered computers, there were no BAs and no developers. Just analyst programmers.

Before that there were systems analysts and programmers. For people like NotAllThere, systems analysts were exactly the same as today's business analysts. Programmers would be given a spec and they would write to that. I don't remember there being many testers. Or any.

Then came analyst-programmers . The analyst-programmer could analyse the requirement and come up with his own design as well as program it. And test it. It was a great step forward.

Sadly like so many things, we regressed. Analyst-programmers became 'developers' and developers got pushed back into their cells to be replaced by a hoard of suities - PMs, scrum masters, architects, PMO's, BAs, etc etc.

[munkee]

They should at least know what can be implemented though.

Requirements feasibility? Yes agree. But that wasn't the question.

[LondonManc]

When the question of what a business analyst does is asked, this needs qualifying, surely?

I've seen the expectations placed upon a BA to vary considerably between industries and even different organisations within an industry. Some see them more as systems analysts, some as purist business analyst; by that, I mean that they may carry out anything from assisting the PM with PID preparation through to assisting the testers with test script preparation in a consultancy capacity and participating in the lessons learned and support handover sessions at the end of a project. In terms of the functional boundaries, it could be anything from business interviews to clarify requirements, pareto analysis, assistance with project planning, actually preparing the detailed stage plans on larger projects, carrying out SWAT analysis and engaging in feasibility studies.

That's without establishing whether you're expecting any SME specialisation - e.g. an insurance specialist, a pharma specialist and so on, or if they're expected to have any technical expertise (e.g. being reasonably proficient at SQL). The other thing to consider is how the role would differ between a Waterfall project, a true Agile project and a JFDI with Agile tools approach.

In short, there's no single answer as to what a business analyst is, but everyone has their own perceptions of what they should be.

[eek]

My usual complaint about BA's is that they try to be things they are not.

Prime examples I've seen in the past are them trying to be architects (I mention that as that disaster of a business appeared on my radar earlier this week), trying to design the system (because they think they know the business better than the developers) or over promising because they know no better.

A BA that knows what they can and can't do and where they add value is a good addition to a project. Sadly most overstep the mark...

[LondonManc]

My usual complaint about BA's is that they try to be things they are not.

Prime examples I've seen in the past are them trying to be architects (I mention that as that disaster of a business appeared on my radar earlier this week), trying to design the system (because they think they know the business better than the developers) or over promising because they know no better.

A BA that knows what they can and can't do and where they add value is a good addition to a project. Sadly most overstep the mark...

It's nearly as bad as developers coding a solution and then trying to find a business problem to solve with it.

[Fronttoback]

The BA doesn't need to know anything about how things "should be implemented". That doesn't mean they aren't entitled to an opinion though just like the dev has an opinion on other aspects.

One of the core BA principles is to offer options not solutions. A requirement would fail its quality criteria if it infers solution.

Once again your view is skewed by only knowing bad BA's. That's fine though as I have said I understand your point of view.

What if I told you that I've worked with a top gun BA or two. And then you get a sense that the problem is understood to the same depth needed to implement it properly. There are no logical gaps in the analysis. It makes sense. A good BA combines architectural knowledge, domain knowledge, analytical skills (classification and categorisation of masses of detailed information), ability to grasp business logic quickly, ability to get to the root of the matter and ask the right questions, good documenting skills (both content and document management)- this last one is often done poorly by ex-dev BA types.

We don't need an admin person- we need someone to fully understand the problem, if you are taking that responsibility from us you must do it fully. Anything else creates more work than doing the work ourselves in the first place- because we must go back to the business, analyse both your analysis and the real problem, to see what you have missed.

This is a non-trivial undertaking- that's why most BAs fail to do the proper job.

[Lance]

What if I told you that I've worked with a top gun BA or two. And then you get a sense that the problem is understood to the same depth needed to implement it properly. There are no logical gaps in the analysis. It makes sense. A good BA combines architectural knowledge, domain knowledge, analytical skills (classification and categorisation of masses of detailed information), ability to grasp business logic quickly, ability to get to the root of the matter and ask the right questions, good documenting skills (both content and document management)- this is often done poorly by ex-dev BA types.

We don't need an admin person- we need someone to fully understand the problem, if you are taking that responsibility from us you must do it fully. Anything else creates more work than doing the work ourselves in the first place- because we must go back to the business, analyse both your analysis and the real problem, to see what you have missed.

This is a non-trivial undertaking- that's why most BAs fail to do the proper job.

Sounds like a dream to work with. I'd then have to just get on with designing a solution just once and not constantly reworking every time someone had another bright 'idea'.

[Fronttoback]

My usual complaint about BA's is that they try to be things they are not.

Prime examples I've seen in the past are them trying to be architects (I mention that as that disaster of a business appeared on my radar earlier this week), trying to design the system (because they think they know the business better than the developers) or over promising because they know no better.

A BA that knows what they can and can't do and where they add value is a good addition to a project. Sadly most overstep the mark...

Agreed, and they often get away with it because they have "business" in their job title.