I was just wondering what you all do day in and day out....
I would say 60% of my position is coding, peeling back layers of data or aggregating data for reports. A close second is the use of report engines such as Business Objects. It may actually be more like 70%. Project Management comes in around 5% and requirements analysis maybe 10%.
What's confusing is these frameworks out there seems to really focus on the 5 or 10% of my role but fail to mention anything about managing data or analyzing it. Don't get me wrong, I have to manage stake holders expectations and all that jazz, but it seems like a very small piece of my job. What gives? Did I get into a fake BA role or is this how it's supposed to be? What's weird from my view is that a lot of our senior (not all) have compiled either very good VBA, .Net or SQL skills. Some senior BA's get by with domain knowledge, but it seems those that do leverage the domain knowledge get promoted to other positions such as Product, Program, Project or some other type of manager while the senior BA's are programmer hybrids or techno functionals.
This was at my last position as well. The senior BA's were masterful with their SQL but weren't special at requirements gathering or stakeholder expectations. In fact they were bad, it hurt them but not enough to keep them from "moving on up".
Sorry for the Rant but the BA title seems more concept than real world when reviewing these popular frameworks, RUP, BABOK, PMBOK etc.
I understand what you feel. Based upon the setting a BA can be 'all for one' or 'one for all'.
My job is to gather requirements to build IT applications in a wide variety of telecom sub domains, facilitate dialogues with all stakeholders, create high level design documents, assist in Project Management and check on delivery in terms of schedule, budget and quality.
In addition to that, I also volunteer for proof-of-concept like work in my organisation, respond to RFPs and RFQs and everything in between. Oh yes..I also perform data analysis, run SQLs and suggest technical solutions to the dev/test community.
My take towards the ambiguity in the definition of a Business Analyst is: There is no definition and there is no point trying to conform oneself to a framework. As long as I am solving problems that directly or indirectly affect my clients' businesses in a positive manner, I am satisfied with my job.
brought to you by enabling practitioners & organizations to achieve their goals using: