Bulls**t Jobs

Business Analyst

Monkey with Banana

A reader from Pennsylvania writes...

Analyze and interpret other peoples' work in order to pass on requirements in order for other people to continue doing said work. You get to tell people what they already know and tell them what they already expect. You get to attend ""Meetings"" that are not much more than stating problems and pawning off the responsibility of fixing said problems to someone who actually knows something and gets paid far more because they actually have a skill/trade.

The Business Analyst is the facilitator of time consuming numbness. As simple as a monkey opening a banana.

3 Comments Add Comment

Wow, you seem to have only worked with some lame or unneccessary business analysts. If you don't need a banana to be peeled, then don't hire the monkey. I work with intelligent and skilled ba's that know what our clients need though we developers need to guide them with technical issues, it works pretty well.

The BA job is what you make it. Some are stuck in that position for years just doing what they are "supposed" to do. What they are "supposed" to do is best summed up by the old maxim "those also server who merely stand and wait". As is the case in most positions, you don't get very far just doing what you are "supposed" to do.

Could be or couldn't be a BS job, depending on the organization. How many Project Managers are there in addition to the Business Analyst? My perspective is IT-oriented, so I would also ask if the organization considers its developers to be Systems Analysts, in which case there could be some overlap between the S.A. and the B.A. Some of the Telecom companies were had overkill with 5 layers of Analysts between the Project Managers and the developer, in the heyday of the late 1990s. If the B.A. is also a Project Manager, they could be performing a valuable task simply by pressuring the users to define their requirements for a system before the project begins (You'd be amazed how many users within Fortune 500 companies think it is acceptable to change requirements after code has been installed to production systems). Interpretation of the requirements could be a secondary task for them, and as you point out not needed quite as much if the developer/S.A. has a good background for the organization. Having a good Project Manager is priceless for hammering the requirements out of the users, who typically want to mind-meld in some weird manner and expect the developers to "just know".