Jump to content
Nich...

Business Analysts

Recommended Posts

For a while now, I've entertained the notion that my backup career, should I stop finding desserts interesting, would be as a business analyst. It was sold to me as the person who liaises between the development team and the 'customer' to make sure realistic requirements and specifications are used for the project.

 

My favourite parts of doing IT in the past generally revolved around doing higher level/concept stuff. The problem being getting enough of an understanding of the basics to know how to deal with them in broad but accurate strokes.

 

What I've learned in the years since, however, is that it's not just about understanding the underlying hardware and software; it's also about understanding the business systems, to make sure you're actually calculating/delivering on what is needed, rather than wanted.

 

And, for some BAs, lots of statistics are involved, to help determine these kinds of things.

 

I know there are some Atomicans (past and present!) who have worked as or are working in BA (or similar) roles, and I am hoping some of you may share some of the day to day as well as overarching ideas/themes/tasks that make up your career/job.

Share this post


Link to post
Share on other sites

For a while now, I've entertained the notion that my backup career, should I stop finding desserts interesting, would be as a business analyst. It was sold to me as the person who liaises between the development team and the 'customer' to make sure realistic requirements and specifications are used for the project.

 

My favourite parts of doing IT in the past generally revolved around doing higher level/concept stuff. The problem being getting enough of an understanding of the basics to know how to deal with them in broad but accurate strokes.

 

What I've learned in the years since, however, is that it's not just about understanding the underlying hardware and software; it's also about understanding the business systems, to make sure you're actually calculating/delivering on what is needed, rather than wanted.

 

And, for some BAs, lots of statistics are involved, to help determine these kinds of things.

 

I know there are some Atomicans (past and present!) who have worked as or are working in BA (or similar) roles, and I am hoping some of you may share some of the day to day as well as overarching ideas/themes/tasks that make up your career/job.

Though not a Business Analyst myself, I'm often finding myself hiring them, or hiring people with other job descriptions who also need to fill the role of BA at some point.

 

Two things come to mind:

 

1) The role of a BA is to ask questions. Ask and ask and ask and ask. Then ask some more. Then, after you've asked a zillion questions, build the functional requirement. I hire based on the person wanting to ask a million questions and being unafraid to do so. The technical stuff is just icing on the cake.

2) Worry less about the software and even less about the hardware. Worry about what the business user/department/entity requires. What process needs to be fulfilled? How do you close the functional gaps? What is the business trying to achieve? What is the end goal? Then draw on the technical resources to help fill in the application or infrastructure specifics.

Share this post


Link to post
Share on other sites

I was a Business Systems Analyst towards the end of my IT career; or rather, it was one cap I wore. As Amiga said, software and hardware is distant second to the business user/department/entity requirements. Oh, and lots of meetings. Lots and lots and lots of meetings to go along with the Ask and ask and ask and ask. Then ask some more.

 

What process needs to be fulfilled? How do you close the functional gaps? What is the business trying to achieve? What is the end goal? Then draw on the technical resources to help fill in the application or infrastructure specifics.

Basically; this :-) Very well said :-)

 

My role was tangled up with SharePoint 2010, so often I pretty much had my delivery point handed to me. However, as a general rule, my basic interaction with a department would tend to revolve around the process of moving from gross to fine; broad concepts and requests from the team, through to full-scale implementation and deployment with all the details worked out and working well. I bounced back and forth between my desk and meetings with users many times whilst speccing projects. The basic process would run roughly:

 

- meet'n'greet with principle users wherein I would discuss with them exactly what problem they were trying to solve

- go away and deduce whether there was a technical solution my team, the IT team, could help provide

- meet with the users again, discuss finer details of the nature of the problem (not talking about solutions yet); what they want to achieve, when, what parties need to be involved, expectations (very important to get this part clarified and in writing), etc etc etc

- go away and begin speccing; if this was a SP solution, then we could jump to beginning initial spec/design (as that was my area of expertise)

- meet with users again to refine details

- meet with relevant managers for approvals

- go away and begin drafting/testing

- work alongside test usergroup to develop solution

--> determine a set of users who will help test the system/act as a 'think tank'

--> manage user feedback, incorporating into design where necessary, and managing client expectations (ie, ignore the bullshit whinging and focus on the solution)

--> depending on the size of the project, regular 'think tank' meetings might be necessary

- meet with users for sign-off

 

Obviously this is only a rough guide. Sometimes the back-and-forth is an interminably long process, and my role was a bit muddy as I was also the SharePoint admin/developer and my BSA'ing was often (not always) tied up with SP. But yeah, lots of meetings. Lots of handshaking. And lots of documentation.

 

Hell-fun, though. I loved it :-)

Edited by elvenwhore

Share this post


Link to post
Share on other sites

I haven't been one but from those I've worked with it seems to be days filled with data analysis, meetings, report writing, meetings, project work and also meetings.

 

It gets so a day where you don't have a meeting is like winning the lottery because you can get some work done. It's satisfying though because you get to achieve things and own or influence the direction that the unit/department/company is going in.

Share this post


Link to post
Share on other sites

I'm currently a Lead Developer, which means I'm the guy that meets with clients (and tells them what their requirements are :p). In the past I've been a Team Lead / Scrum Master (in charge of a team of 2 BA's, 1 SME, 5 Devs, and 2 Testers), Principal Systems Developer (the highest up technical guy responsible for all software being outputted from a particular govt dept), a Software Development Manager (responsible for hiring BA's, assigning to projects, monitoring and coordinating multiple development teams across different software projects), Senior Software Engineer, Programmer Analyst, and lowly programmer. I've also spent the better part of the last 15 years being the guy that is responsible for the contents and quality of software project requirements and specifications.

 

As has already been said, a BA's primary output is to produce functional and non-functional specifications. The BA typical typically utilizes a number of artifacts to this end: Data Flow Diagrams, Process Flow Diagrams, Entity Relationship diagrams, User Stories, Use Cases, UML, and so on. Some BA's (the bad ones) will simply jot down notes in dot point form and leave the technical team to figure out what they're meaning, or usually to come back and ask a zillion questions. Making use of the previously mentioned artifacts is better, because it forces the BA to break down each problem and explorer the concerns.

 

A BA doesn't need to be a subject matter expert (SME's). Big projects will have SME's running alongside the BA's. If a team doesn't have an SME, then Customer will act as the SME and the BA will consult directly with the customer to gather requirements. There's also interaction with senior technical staff: architects and team leads or senior developers to ensure sufficient and appropriate information has been captured. Naturally, if a company is working in a particular vertical the developers that have been around for a long while will have picked up some domain knowledge along the way too, making them a valuable source of information, especially if BA's are contracted on a temporary/project basis.

 

I've found the best BA's have a detailed understand and experience with process and documenting process, with a bit of domain knowledge (SME) and a bit of development knowledge. Some BA's are able to produce technically accurate entity relationship diagrams and database schema's, some are former developers who are more comfortable utilizing pseudocode to get processes across to the developer. The key is it doesn't matter what form is used to document the system, as long as it can clearly convey the information. In the past I've used a number of methods to look at the one problem from multiple angles. As a BA you can even analyse requirements from different stakeholder perspectives, IEEE 1471 defines that, though it is more a document for an architect to produce.

 

Certainly, identifying the stakeholder or "Actors" and then analysis how each Actor will interact with the system aids in developing "User stories", such as "As a Customer purchasing good I want to receive a Tax Invoice once the sale is complete so that I have a record of my purchase". User stories take the form "As an <Actor> I want to <goal>, so that <motivation>". Writting short user stories in this manner convey a lot of information. From that one sentence I have described a role, the outcome, and the motivation. roles imply a need to identify security, authorization and authentication. outcomes provide a source for Acceptance Test writing, and motivations provide some background context and understanding for the task, which is often helpful for asking more questions. To this end, when I'm talking to clients I ask questions to enable me to write a requirement down as a user story and that really helps discover other requirements.

 

Often on smaller projects, the BA's are senior developers (programmer analsysts - ok, realistically the'yre also junior developers - or any developer that happens to be available :p), and analyst skills are taught as part of a software engineer/comp sci/IT degree.

 

Your success as a BA may also be determined by the style of project you're working on.

* On a Waterfall SDLC, you're job is to get in early on in the project and generate the documentation that will be used by the technical team to produce the software in a subsequent phase.

* On Agile projects you'll work with the development team, collaborating through the life of the project. You will likely start my talking to with the client to collect a series of "User Stories" which will make their way into a backlog. Then you or other BA's will add detail those user stories. Once enough detail has been added (as determined by you and the developers at sprint meetings), the stories will be added to sprints. As each story is worked on you'll meet with the developers and testers to fine-tune the exact requirements and expected output. <-- This method is by far the more successful and the more enjoyable to work on, if you're at all a people person. It's my favourite way to do software :)

 

I've also had teams/projects suffer from "Analysis Paralysis" (sounds catchy hey!) where we all go round and round in a meeting after meeting unable to decide in requirements. That sucks and is down to the quality of BA.

 

Also, as the person that dictates what it is the dev team produces, your arse is on the line if what comes out of the code factory (haha :p) is not what the customer wanted. More times than I like (I like none!) I've had BA's let go because of this exact problem.

Edited by kikz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×