Why are BAs so undervalued?

Perhaps I have a chip on my shoulder but of the standard Troika that kicks off most projects (BA, PM, Arch) the BA is the most often undervalued role. In every single metric I can come up with to measure organisation esteem (Salary, reporting lines, training budgets) of these roles BAs come out third.

Considering the calibre of BAs in most organisations this is pretty understandable, with little organisational support, no clear career path in, no clean career path up or out, a fledgling professional body, and little formal power over a project it's no suprise that BAs end up being dogs-bodies instead of drivers. This is a symptom not a cause though.

In reality a good BA does more to make a project delivery exceptional business value than any one besides the business representatives. Good project management, architecture, technical delivery, etc, all these help you deliver well, and make it cheaper and faster; but if you want it to be actually better for the users - getting the requirements and functional design right is the way to do it and that's the BAs job.

So why the disconnect between the high value and the low valuation? At source I think it comes down to four things:

A) Most BAs are bad at their job, so even if the good ones are tarred by association
B) Deliverables are not as visible or "epic". PMs and Architects get to produce big gannt charts, architecture road-maps, present to steering committees etc. BAs sometimes get this level of visibility much less often, and generally only as a project representative - not as part of something bigger,
C) No organisational power centre to promote the role, and ensure the wider concerns of BAs get an ear. There's no equivalent of the PMO or Enterprise Architecture office for requirements.
D) Facilitators less valuable than deciders in the eyes of modern business culture. This is the big one. Deciding is just considered more powerful and important than facilitation. The ability to allocate resources and make calls is just intrinsically higher status than the facilitating and agreement promoting role that BAs play. It's just our culture.

Categorising Tools for BAs

People talk a lot about "BA tools" and "Requirement Management" without really defining terms.

I think it's worth at least defining some of the different types of tools that are out there so you can compare apples with apples. As a candidate list:

Collaboration: Systems that help groups of people work together to build a body of knowledge. Word documents on share drives, Wikis, doc management systems, etc in this area. These sort of tools can be used for everything.

Requirement Tracking: Systems that allow BAs to collect "requirements" as a list of statements and then track which are in and out of scope, which are included in a release, who approved them, and the like. These tools are primarily used in the Elicitation and Requirements Analysis knowledge areas. As mentioned Adam's "Bright Green Projects" looks like a great pre-rolled offering in this space. Requisite Pro falls mainly into this camp.

Solution Modelling: Systems that assist you in building a rigorous description of the systems functionality. This covers tools like Enterprise Architect, any of the BPM tools, ERWin, etc. These tools are primarily used in the Solution, Assessment, and Validation knowledge area

Solution Validation: All of the testing tools, coverage, execution, automation that this conversation has been conveniently ignoring.

All of these are "Requirement" management according to the BABOK definition of a requirement - and no tool falls neatly into any camp, but neither does any tool adequately cover all areas.

IBM's suite probably covers every area but it really is a behemoth.

P.S. Tools are the caps one of BA Capability improvement - not the foundation. Tools can often do more harm than good in an immature environment.

BA work is about building bridges between different domains, and tools (almost) invariably hurting in one domain, as much as they help in another. Microsoft office is worse in a completely different way though. Wiki & Issue tracker is a decent compromise - but is also not without problems.

Changing tools without a mature BA practice will likely just leave you with a new set of problems and higher monthly licensing costs. I would strongly suggest that the money and time you could spend on tool setup is better spent setting up a BA Community of Practice and put on a spread so your BAs can tell War Stories to each other over lunch.

Plan vs Change Centric

The definition the latest BABOK has for Plan and Change centric project delivery methods is very useful. It's not exactly ground breaking to break methods/processes into different camps based on whther they are Agile or Waterfall - but the terms are pretty loaded. I think these terms capture the essential differences between these two camps.

It's not that one camp has different component tasks, it's just that one puts the plan as the central tool for delivering change, the other puts the change being delivered at the centre of planning.

You see this really clearly in the way that BABOK 2.0 describes the Requirements Anlysis tasks. The same basic activiteis are always done, but how and when they are done changes depending on process.

It's just nice to have a neutral non-emotive term.

It also reinforces that good BAs are good BAs regardless of methodology. If you know how to do it right for Waterfall you're going to be able to hit the ground running with Agile. The hardest bits don't change. Empathy, communication, listening, lateral thinking, modelling, and problem solving are always the core-skills.