What do business analysts really do?
May 11, 2011 5:27 PM Subscribe
Are you a business analyst in IT? What is it like?
Please describe what your BA job / role is like. For example, what are your daily tasks? What do you spend the bulk of your time doing? What are some pros and cons in this career? Do you enjoy your job? If you were to advance, what kind of role would you advance to?
If I remain with my current company, I'll be groomed to be a BA. I'm taking an IT diploma and I know what business analysis is for, but I don't have a good picture of what BAs really do day in, day out. Please clue me in.
Please describe what your BA job / role is like. For example, what are your daily tasks? What do you spend the bulk of your time doing? What are some pros and cons in this career? Do you enjoy your job? If you were to advance, what kind of role would you advance to?
If I remain with my current company, I'll be groomed to be a BA. I'm taking an IT diploma and I know what business analysis is for, but I don't have a good picture of what BAs really do day in, day out. Please clue me in.
I am, and here's how I spend my day:
Testing: ~2 hours
Working directly with clients: ~1 hours.
Researching issues: ~2 hours
Writing specs, discussing business processes or decisions: ~1 hour
Project management: ~ 2 hours
Other things I do: internal and external training, meetings, writing regression tests, writing and reviewing documentation, and on-site visits. I'm probably missing some things.
I think it's a great job. It helps to be able to maintain focus while moving between multiple, demanding tasks. I am rarely bored; there's always something to do and it's a challenging position. I enjoy advocating for my clients. I have a surprising amount of influence both in my company and with my clients. And I find problem-solving incredibly satisfying.
Things that aren't great: having to balance client needs and wants with the product's limitations and the company's aims. Translating technical explanations into something clients can understand.
I'll update with more later, stupid onscreen keyboard is frustrating.
posted by punchtothehead at 6:12 PM on May 11, 2011 [1 favorite]
Testing: ~2 hours
Working directly with clients: ~1 hours.
Researching issues: ~2 hours
Writing specs, discussing business processes or decisions: ~1 hour
Project management: ~ 2 hours
Other things I do: internal and external training, meetings, writing regression tests, writing and reviewing documentation, and on-site visits. I'm probably missing some things.
I think it's a great job. It helps to be able to maintain focus while moving between multiple, demanding tasks. I am rarely bored; there's always something to do and it's a challenging position. I enjoy advocating for my clients. I have a surprising amount of influence both in my company and with my clients. And I find problem-solving incredibly satisfying.
Things that aren't great: having to balance client needs and wants with the product's limitations and the company's aims. Translating technical explanations into something clients can understand.
I'll update with more later, stupid onscreen keyboard is frustrating.
posted by punchtothehead at 6:12 PM on May 11, 2011 [1 favorite]
Response by poster: Another thing I'm curious about: what's the 'right' personality for business analysis?
posted by kitcat at 6:19 PM on May 11, 2011
posted by kitcat at 6:19 PM on May 11, 2011
One of my last gigs as a business analyst involved maintaining and expanding a Cognos BI (Business Intelligence) system, which drove a management "dashboard" application for a large national business facilities service firm. Essentially, the job involved analysis of new business indicators and controls for managing cash flow, direct labor and controllable expenses for about 27,000 physical sites in North America; then, translating that into stored queries and procedures in the Cognos BI application, including building indexes and data access paths to optimize DB performance. It was a fairly technical gig at times, involving translating management requests for daily, weekly, and monthly reports, against "real time" dashboard indications, versus the systems cost of supporting whatever index rebuilds, stored procedures, and DB activity needed to guarantee acceptable dashboard "accuracy."
20% of time spent dealing with senior/middle/lower management regarding dashboard "wish list" vs standard cyclic or "on demand" reporting. 20% of time designing, testing, and applying new queries/reports/data cube processes. 40% of time training management on use of new dashboard indicators, drill down reporting, cyclic/on demand reporting support, etc. 20% of time pruning back obsolete reporting/dashboard indicator support/data cube elements (really like pulling teeth, generally, but very necessary in a such a large, dynamic BI environment, if you weren't blessed with an unlimited hardware/systems upgrade budget).
"Another thing I'm curious about: what's the 'right' personality for business analysis?"
posted by kitcat at 9:19 PM on May 11
Depends on your level and job experience. At the entry level, being pleasant, approachable, humble, helpful, and thoughtful are usually minimum requirements. At the very senior level, a certain personal remove and a somewhat taciturn demeanor can be helpful in preserving your ability to focus on the work at hand, as opposed to being everybody's guru; but when a senior BA speaks to senior level management, he never condescends, or fails to speak English, even when it is absolutely necessary to have a technical discussion, or make a technical point.
posted by paulsc at 6:32 PM on May 11, 2011 [1 favorite]
20% of time spent dealing with senior/middle/lower management regarding dashboard "wish list" vs standard cyclic or "on demand" reporting. 20% of time designing, testing, and applying new queries/reports/data cube processes. 40% of time training management on use of new dashboard indicators, drill down reporting, cyclic/on demand reporting support, etc. 20% of time pruning back obsolete reporting/dashboard indicator support/data cube elements (really like pulling teeth, generally, but very necessary in a such a large, dynamic BI environment, if you weren't blessed with an unlimited hardware/systems upgrade budget).
"Another thing I'm curious about: what's the 'right' personality for business analysis?"
posted by kitcat at 9:19 PM on May 11
Depends on your level and job experience. At the entry level, being pleasant, approachable, humble, helpful, and thoughtful are usually minimum requirements. At the very senior level, a certain personal remove and a somewhat taciturn demeanor can be helpful in preserving your ability to focus on the work at hand, as opposed to being everybody's guru; but when a senior BA speaks to senior level management, he never condescends, or fails to speak English, even when it is absolutely necessary to have a technical discussion, or make a technical point.
posted by paulsc at 6:32 PM on May 11, 2011 [1 favorite]
When I did the job at a largish retail company it was a lot of requirements gathering, creation of functional design documents, gathering of approvals, creating use cases and functional test cases, refining those cases, gathering more requirements, getting the business to explain why these new requirements were absolutely necessary, getting buy in from the developers and tech leads, getting more approvals, doing more use cases/test cases, performing functional testing, scheduling UAT, overseeing UAT, logging defects, following up on defect resolution, re-testing, getting test results approved, assisting with rollout and rollout documentation, hanging around while implementation took place, doing a quick check before handing the system over to the users, inevitably dealing with the fallout when the scenario we didn't test for came up within 24 hours and crashed the system, working with developers to quickly fix and retest and reimplement the system, often repeating this a few times. Oh and also working with a project manager to schedule deliverables and track time if the project was large enough to get a PM assigned to it. And often doing user documentation since there often wasn't someone available to do it in the business. And also running interference with the PMO so the developers could actually get their jobs done with minimal interference. And doing this for multiple projects at any given time.
I did it for around five years and mostly enjoyed it (moved into a different field a few months ago), but I don't miss it at the moment. I should say I came from a retail merchandising background (buying and replenishment analysis). Most of my BA colleagues came from a developer or operator background and took a more hands on technical approach (often pissing off the developers in the process, but often offering better help in some pinches than I could).
What the job of BA actually is isn't particular well defined yet, no matter what the IIBA might tell you*. I've known BAs who would never do the kind of QA work I describe above, and others who were shocked that I didn't do any programming.
On preview: you have to be able to speak both the business' language and the developers' language, and be able to respect both, and work as an advocate for both. If your personality is strongly aligned against one or the other of those groups you probably won't enjoy the job.
*BA certification from that body isn't currently worth anything by the way (it's not a widely recognized spec the way PM certification is), though the meetings are good for networking and learning how other people do the job, if you have a local chapter.
posted by Lentrohamsanin at 6:32 PM on May 11, 2011
I did it for around five years and mostly enjoyed it (moved into a different field a few months ago), but I don't miss it at the moment. I should say I came from a retail merchandising background (buying and replenishment analysis). Most of my BA colleagues came from a developer or operator background and took a more hands on technical approach (often pissing off the developers in the process, but often offering better help in some pinches than I could).
What the job of BA actually is isn't particular well defined yet, no matter what the IIBA might tell you*. I've known BAs who would never do the kind of QA work I describe above, and others who were shocked that I didn't do any programming.
On preview: you have to be able to speak both the business' language and the developers' language, and be able to respect both, and work as an advocate for both. If your personality is strongly aligned against one or the other of those groups you probably won't enjoy the job.
*BA certification from that body isn't currently worth anything by the way (it's not a widely recognized spec the way PM certification is), though the meetings are good for networking and learning how other people do the job, if you have a local chapter.
posted by Lentrohamsanin at 6:32 PM on May 11, 2011
as I've seen it (not a BA myself) the day-to-day is highly company specific, but the common thread is providing a translation service between the Business and IT people - helping Business turn their squishy "it should be great!" desires into useful requirements for IT to implement, and providing enough business perspective to stop IT from rushing off down the "ooh, shiny cool new technology" rabbit hole.
posted by russm at 7:13 PM on May 11, 2011 [2 favorites]
posted by russm at 7:13 PM on May 11, 2011 [2 favorites]
I do BA work more or less.
Answers are great above.
Great communication skills (including asking right questions and listening) are very important.
You'll be writing alot of documentation and e-mails, you'll be in meetings a ton, so if you don't like doing any of that, you probably won't enjoy the work.
Big pros of the work is that I think there's alot of transferable skills and makes you more marketable.
If you're building stuff now, you might not be able to get alot of stuff "produced", which could be a con.
posted by sandmanwv at 7:34 PM on May 11, 2011
Answers are great above.
Great communication skills (including asking right questions and listening) are very important.
You'll be writing alot of documentation and e-mails, you'll be in meetings a ton, so if you don't like doing any of that, you probably won't enjoy the work.
Big pros of the work is that I think there's alot of transferable skills and makes you more marketable.
If you're building stuff now, you might not be able to get alot of stuff "produced", which could be a con.
posted by sandmanwv at 7:34 PM on May 11, 2011
My last role was working as a BA in a large bespoke development project for the state government. The role was workshopping requirements with the business SMEs (Subject Matter Experts) minuting the meeting and ensuring all agreed on the outcome. The requirements was fed into a functional specification document which was then peer reviewed and reviewed by the dev company to ensure that the requirements fell within the agreed deliverables.
Often there was negotiation around these, so another workshop would be held to realign the client's requirements. The functional spec was then submitted to the client who would check it and provide feedback. This was delivered in a spreadsheet with each item enumerated. The functional spec was then altered to accept the client's feedback, the client was not meant to add anything material to the artifact, but often they did, or when they reviewed it they wanted changes, so back through workshops and review.
Apart from the functional spec, all functional touch points needed to be understood, and included in the spec, often these changes, so the FS (functional spec) needed updating.
Once the FS had been signed off, development commenced. The developed item was then sent to testing which involved a separate test crew writing test plans against the functional spec. Many of the requirements were highly complex and involved a lot of workshopping with the client - to then expect a test crew (especially an offshored test crew) to digest these and understand was an exercise in frustration.
testing would show defects that were often to do with the business process, so back through the workshop route... On it goes. As a job? It's OK.
posted by the noob at 7:52 PM on May 11, 2011
Often there was negotiation around these, so another workshop would be held to realign the client's requirements. The functional spec was then submitted to the client who would check it and provide feedback. This was delivered in a spreadsheet with each item enumerated. The functional spec was then altered to accept the client's feedback, the client was not meant to add anything material to the artifact, but often they did, or when they reviewed it they wanted changes, so back through workshops and review.
Apart from the functional spec, all functional touch points needed to be understood, and included in the spec, often these changes, so the FS (functional spec) needed updating.
Once the FS had been signed off, development commenced. The developed item was then sent to testing which involved a separate test crew writing test plans against the functional spec. Many of the requirements were highly complex and involved a lot of workshopping with the client - to then expect a test crew (especially an offshored test crew) to digest these and understand was an exercise in frustration.
testing would show defects that were often to do with the business process, so back through the workshop route... On it goes. As a job? It's OK.
posted by the noob at 7:52 PM on May 11, 2011
Response by poster: I really appreciate the answers so far. Unfortunately, this sounds so, so boring. I'd really like to be convinced that it's not.
posted by kitcat at 8:01 PM on May 11, 2011
posted by kitcat at 8:01 PM on May 11, 2011
My experiences as a BA are in line with the above for the most part. When I worked for an IT consulting company as part of on-site project teams, my time was split between more technical tasks (like detailed system designs and data modeling), system testing (ensuring things work according to the documentation prior to putting out the build), and working with the client when they perform the user acceptance testing.
Supporting a state agency's system was a bit different. The help desk logged reported issues. I was responsible for reviewing the issues and determining whether they were actually bugs, due to user error or working as designed. The latter required digging into existing documentation (which frankly was lacking in many ways). I was also responsible for working with the vendor's report developers to develop new reports, modify old ones and test the reports. Having in-depth knowledge of the system and the ability to learn the business was required. Problem-solving and critical thinking skills were essential as was the ability to translate between the users and the vendor. My group was also responsible for doing training on the new functionality either in person or via webinars.
Pros: BAs are always needed. Any manager or developer who tells you otherwise is likely having to rework their product when it doesn't meet the requirements (as seen by one group in my agency).
Cons: As an introvert, some days I have no interest in talking to anyone. But I do because it's required. If you're doing issue resolution like I did, it never ends. There's always something else reported that you have to look at. There always seem to be too many meetings.
Project management seems the default moving up role (e.g., running a project, doing budgets, running interference between your team and the business/client). I have little interest in it so I'm still working on what I'll do next.
I think it is a boring job so I can't convince you that it's not. But it speaks to my detail-oriented personality and I'm decent at it. If you're more of an ideas person, you probably wouldn't like it. I would suggest talking with BAs at your company to get a complete understanding of what you would be doing at your company.
posted by bluesapphires at 8:28 PM on May 11, 2011
Supporting a state agency's system was a bit different. The help desk logged reported issues. I was responsible for reviewing the issues and determining whether they were actually bugs, due to user error or working as designed. The latter required digging into existing documentation (which frankly was lacking in many ways). I was also responsible for working with the vendor's report developers to develop new reports, modify old ones and test the reports. Having in-depth knowledge of the system and the ability to learn the business was required. Problem-solving and critical thinking skills were essential as was the ability to translate between the users and the vendor. My group was also responsible for doing training on the new functionality either in person or via webinars.
Pros: BAs are always needed. Any manager or developer who tells you otherwise is likely having to rework their product when it doesn't meet the requirements (as seen by one group in my agency).
Cons: As an introvert, some days I have no interest in talking to anyone. But I do because it's required. If you're doing issue resolution like I did, it never ends. There's always something else reported that you have to look at. There always seem to be too many meetings.
Project management seems the default moving up role (e.g., running a project, doing budgets, running interference between your team and the business/client). I have little interest in it so I'm still working on what I'll do next.
I think it is a boring job so I can't convince you that it's not. But it speaks to my detail-oriented personality and I'm decent at it. If you're more of an ideas person, you probably wouldn't like it. I would suggest talking with BAs at your company to get a complete understanding of what you would be doing at your company.
posted by bluesapphires at 8:28 PM on May 11, 2011
I've been in a BA role for the past 3 years. I can pretty much second everything that's already been posted. Personally I like my job a lot, for some reasons related to the actual role and some reasons related to the company itself, so this stuff depends a lot on where you work:
My favorite aspect of the job is the challenge of taking complex ideas and distilling them into something that humans (whither business folks or coding folks) can understand and make decisions on.
That said, my day-to-day is basically:
Read specs., talk to folks (clients and coworkers), write requirements and use cases, clear the air via meetings/emails when things hairy, help support people, etc...
Personally I think it's fun because I get to work with technology, I get to write, I get to travel internationally (obviously this is business specific) and I have a generally stable, 9 to 5 job in which I've made a gazillion contacts and learn new things every day.
posted by jnrussell at 8:53 PM on May 11, 2011 [1 favorite]
My favorite aspect of the job is the challenge of taking complex ideas and distilling them into something that humans (whither business folks or coding folks) can understand and make decisions on.
That said, my day-to-day is basically:
Read specs., talk to folks (clients and coworkers), write requirements and use cases, clear the air via meetings/emails when things hairy, help support people, etc...
Personally I think it's fun because I get to work with technology, I get to write, I get to travel internationally (obviously this is business specific) and I have a generally stable, 9 to 5 job in which I've made a gazillion contacts and learn new things every day.
posted by jnrussell at 8:53 PM on May 11, 2011 [1 favorite]
One of the skills I've always recommended for the job is diplomacy. I've often found myself operating between IT and a department where there is a history of bad blood. It doesn't make the job easier per se, but I always enjoy the easy wins you get early on with just a good attitude and a reasonable customer service ethic.
posted by sapere aude at 9:12 PM on May 11, 2011
posted by sapere aude at 9:12 PM on May 11, 2011
I am not a BA, but I know a lot of people who are BAs, and what they tell me about their jobs sounds roughly the same as what everyone's saying. And yes, it sounds boring to me too, so maybe it's not for you (just like it isn't for me).
posted by Xany at 9:26 PM on May 11, 2011
posted by Xany at 9:26 PM on May 11, 2011
I really appreciate the answers so far. Unfortunately, this sounds so, so boring. I'd really like to be convinced that it's not.
it's so so boring
You need a high attention to detail and be very organised. I did find it enjoyable. Designing a good system. frankly the worst part of the ob was using HP Quality Center. If ever there is a piece of software that needs HP Quality Center - it's HP Quality Center.
posted by the noob at 10:38 PM on May 11, 2011 [2 favorites]
it's so so boring
You need a high attention to detail and be very organised. I did find it enjoyable. Designing a good system. frankly the worst part of the ob was using HP Quality Center. If ever there is a piece of software that needs HP Quality Center - it's HP Quality Center.
posted by the noob at 10:38 PM on May 11, 2011 [2 favorites]
I fill multiple roles at my company, and the stuff people are writing above about what a BA does is pretty spot on. Man, I actually feel drained reading it because that's the type of language I'm fed every day...
As far as what personality is best, I'd say there are multiple ways to approach the job so you can adapt your style accordingly. I can try to be specific on one point: If you're young (which it sounds like) and this is going to be your job coming out of school, I can tell you that there might be an additional challenge due to how you'll be perceived by the client. Most clients will have IT staff and management who are older than you and might be... suspicious. If your company doesn't already have a ton of credibility, you'll need to work on your diplomacy skills and be able to engage them on their terms to win their trust. I'd call this the "Champion" approach, where you show that you understand them, that their interests are your #1 cause, and that you'll do anything necessary to get the job done right. Other projects I've worked on require more attention to detail and demand stepping through things more systematically, and I would call this the "Supervisor" approach - you engender trust by imposing order. The level I aspire to is what I'd call the "Guru," where your cred precedes you because you've already been through "the shit" and the client can tell, and you can just ask the right questions all day and lead the clients into doing the work themselves.
What do I like about it? There is that rare project that makes it all worthwhile - the project where we are asked to propose and implement a solution, where the client was motivated and did their jobs right, and where we delivered a system that totally fulfilled the client's needs, on schedule and within budget. In the years that I've done this (almost 9 now), there have been 3 of these complete successes. That's not great but it's something. The other thing that keeps me somewhat fulfilled is that I like knowing how organizations work, and as a BA you get a pretty good view of the entire organization from multiple perspectives, and you can even learn some dirty little secrets. I've worked for clients in the financial, non-profit, health care, and government sectors, and it's really interesting to understand how these orgs operate and in turn, I feel like I know a little more about the world. Kind of like how, in The Wire, you're gradually introduced to how crime, police, politics, unions, education, and media operate and how they are inter-related and how the overall collapse of the city is due to the corruption and dysfunction eating up each sector. Well, it's not as depressing as The Wire, but that's the best analogy I could come up with.
And yes, the next step after doing BA stuff is being a Project Manager, where analysts are part of your team. After PM, at my company, it's pretty much just the executive-level. Longer term benefits of BA/PM experience: Eventually my goal is to get out of this game to run my own business, and what I've learned about other businesses is going to be nothing but beneficial, I'd hope.
posted by krippledkonscious at 1:59 AM on May 12, 2011 [1 favorite]
As far as what personality is best, I'd say there are multiple ways to approach the job so you can adapt your style accordingly. I can try to be specific on one point: If you're young (which it sounds like) and this is going to be your job coming out of school, I can tell you that there might be an additional challenge due to how you'll be perceived by the client. Most clients will have IT staff and management who are older than you and might be... suspicious. If your company doesn't already have a ton of credibility, you'll need to work on your diplomacy skills and be able to engage them on their terms to win their trust. I'd call this the "Champion" approach, where you show that you understand them, that their interests are your #1 cause, and that you'll do anything necessary to get the job done right. Other projects I've worked on require more attention to detail and demand stepping through things more systematically, and I would call this the "Supervisor" approach - you engender trust by imposing order. The level I aspire to is what I'd call the "Guru," where your cred precedes you because you've already been through "the shit" and the client can tell, and you can just ask the right questions all day and lead the clients into doing the work themselves.
What do I like about it? There is that rare project that makes it all worthwhile - the project where we are asked to propose and implement a solution, where the client was motivated and did their jobs right, and where we delivered a system that totally fulfilled the client's needs, on schedule and within budget. In the years that I've done this (almost 9 now), there have been 3 of these complete successes. That's not great but it's something. The other thing that keeps me somewhat fulfilled is that I like knowing how organizations work, and as a BA you get a pretty good view of the entire organization from multiple perspectives, and you can even learn some dirty little secrets. I've worked for clients in the financial, non-profit, health care, and government sectors, and it's really interesting to understand how these orgs operate and in turn, I feel like I know a little more about the world. Kind of like how, in The Wire, you're gradually introduced to how crime, police, politics, unions, education, and media operate and how they are inter-related and how the overall collapse of the city is due to the corruption and dysfunction eating up each sector. Well, it's not as depressing as The Wire, but that's the best analogy I could come up with.
And yes, the next step after doing BA stuff is being a Project Manager, where analysts are part of your team. After PM, at my company, it's pretty much just the executive-level. Longer term benefits of BA/PM experience: Eventually my goal is to get out of this game to run my own business, and what I've learned about other businesses is going to be nothing but beneficial, I'd hope.
posted by krippledkonscious at 1:59 AM on May 12, 2011 [1 favorite]
Best answer: I agree with everyone else. When I was a Business Analyst- it boiled down to being the liasion between technical and non techincal folks. The toughest part (for me) is trying to work on and design a system that's built for non-techincal business users. It's very important to have really good communications skills-if the system goes live and it's missing an enchancement that business users thought they were getting (but weren't)-they will insist it is a bug. It takes alot of work to try to put out those types of fires. The best path is to get clear requirements and communicate which features a system will end up having. Being organized and documenting everything is important-expecially when it comes to supporting the sytem.
Good luck!
posted by duddes02 at 6:16 AM on May 12, 2011
Good luck!
posted by duddes02 at 6:16 AM on May 12, 2011
From what I've seen as a not-business-analyst (programmers / sysadmin), there's two kinds of business analysts:
A. people who observe and document existing business practices. They gather requirements, figure out who does what etc.
B. people who measure and analyze well documented processes. They look at where the costs are in the process and examine how to improve it.
A is the kind of stuff we use business analysts for at my public uni employer. B is the kind of stuff my father used to do as a business analyst. A and B require vastly different sets of skills; you can get do A without knowing much SQL or statistical analysis. I find B kind of fun on occasion, but the risk of getting those boring / tedious A duties is enough that I'm not going bother with that route.
posted by pwnguin at 6:58 AM on May 12, 2011 [1 favorite]
A. people who observe and document existing business practices. They gather requirements, figure out who does what etc.
B. people who measure and analyze well documented processes. They look at where the costs are in the process and examine how to improve it.
A is the kind of stuff we use business analysts for at my public uni employer. B is the kind of stuff my father used to do as a business analyst. A and B require vastly different sets of skills; you can get do A without knowing much SQL or statistical analysis. I find B kind of fun on occasion, but the risk of getting those boring / tedious A duties is enough that I'm not going bother with that route.
posted by pwnguin at 6:58 AM on May 12, 2011 [1 favorite]
I've always wondered, do BAs make more than developers or is it about the same? I was told that BAs make less than developers if you had an apples to apples comparison (same industry, same experience). This seems right to me, especially if the developers aren't just turning out CRUD applications.
I don't have much experience in a huge corporation, but it seemed that BAs had the ability to get promoted up into upper management roles, where developers always seem to languish. A large part of this, at least in my experience, is the refusal of a lot of developers to take on roles that aren't ... well programming, but didn't know if BA had a better long-term career path.
I realize this is a huge hijack, but this just got me thinking.
posted by geoff. at 7:48 AM on May 12, 2011
I don't have much experience in a huge corporation, but it seemed that BAs had the ability to get promoted up into upper management roles, where developers always seem to languish. A large part of this, at least in my experience, is the refusal of a lot of developers to take on roles that aren't ... well programming, but didn't know if BA had a better long-term career path.
I realize this is a huge hijack, but this just got me thinking.
posted by geoff. at 7:48 AM on May 12, 2011
nthing the answers posted here.
I will say that the exact components of the job (that is, how much time you personally spend testing, writing requirements, writing specs, smoothing over managerial fears, writing use cases, schmoozing developers, etc.) depends very much on the organization you are in. If you have a proper QA person or team, you may not do very much testing at all, and your role in testing may be limited to riding herd on the UAT. OTOH if there's no QA resource, guess what, you are now wearing your QA hat. Some BAs never write specs; they only write biz requirements and then hand off to a more technical person. If you don't like writing, and you can't write a clear, organized document about a complex system, you will not like being a BA.
If you like variety (and I do), it's good. I find I like being the bridge between the (sometimes clueless) business user and the (sometimes clueless) developer. But if you are really a developer at heart, I can see where this would be frustrating. And if you are a pure business type, you will not like talking to the developers and it will be a learning curve for you to understand what questions to ask and how to ask them. IMHO it also helps to have some cross-cultural communication skills, particularly if you are going to be working with remote teams. By cross-cultural I mean both "across business and IT cultures" and "across Western, Asian, Latin American, and Middle Eastern cultures." (I haven't had any SMEs in Africa yet. But you never know!)
posted by tuesdayschild at 8:17 AM on May 12, 2011
I will say that the exact components of the job (that is, how much time you personally spend testing, writing requirements, writing specs, smoothing over managerial fears, writing use cases, schmoozing developers, etc.) depends very much on the organization you are in. If you have a proper QA person or team, you may not do very much testing at all, and your role in testing may be limited to riding herd on the UAT. OTOH if there's no QA resource, guess what, you are now wearing your QA hat. Some BAs never write specs; they only write biz requirements and then hand off to a more technical person. If you don't like writing, and you can't write a clear, organized document about a complex system, you will not like being a BA.
If you like variety (and I do), it's good. I find I like being the bridge between the (sometimes clueless) business user and the (sometimes clueless) developer. But if you are really a developer at heart, I can see where this would be frustrating. And if you are a pure business type, you will not like talking to the developers and it will be a learning curve for you to understand what questions to ask and how to ask them. IMHO it also helps to have some cross-cultural communication skills, particularly if you are going to be working with remote teams. By cross-cultural I mean both "across business and IT cultures" and "across Western, Asian, Latin American, and Middle Eastern cultures." (I haven't had any SMEs in Africa yet. But you never know!)
posted by tuesdayschild at 8:17 AM on May 12, 2011
They have people skills; they talk to the engineers. They also talk to the end users, and translate those lessons into IT language ilke business rules, requirements, SLA terms, and risks. They are analyzing the business on behalf of the technologists.
posted by wenestvedt at 8:56 AM on May 12, 2011
posted by wenestvedt at 8:56 AM on May 12, 2011
Oh yeah, putting out fires is a huge part of my BA job. But I like putting out fires (usually, as long as I don't get any on me).
posted by jnrussell at 10:05 AM on May 12, 2011
posted by jnrussell at 10:05 AM on May 12, 2011
This thread is closed to new comments.
posted by tehloki at 6:06 PM on May 11, 2011