So what does a business analyst actually do?

As a business analyst, I’m regularly asked what it is that I do. Often I’ll need to take a moment to articulate my job and my explanation always manages to sound a little ambiguous.

If you’re a business analyst like me, I’m sure you’ve also been faced with the same question at a dinner, BBQ or corporate event. The problem is, guidebooks rarely provide a clear answer – and good luck trying to find a consistent explanation on Google!

So why is there such a general lack of understanding around what a business analyst does (sometimes even for business analysts themselves)? After careful consideration and some soul searching, I think I’ve found a few answers:

BBQcol2

 

After careful consideration and some soul searching, I think I’ve found a few answers:

Business analysts help facilitate solutions for stakeholders

When a business needs to solve a current or future problem it’s a business analyst’s job to help facilitate a solution.

Mainly we help by working with stakeholders to define their business needs and extract their requirements for what must be delivered. We gather the business’ required conditions and capabilities, documenting them in a consistent, complete and, above all, useful way for the team that will eventually design and deliver the solution.

One of our main responsibilities is to ensure these requirements are visible to, and understood by, all relevant stakeholders regardless of whether the solution is a new product, service or computer system.

We do this by writing clear requirements and creating data models, process diagrams and design wireframes that will further support the business’ needs. We’ll also determine what additional information is necessary, what key details are missing and the potential impacts and challenges to the solution and/or other projects.

Business analysts offer guidance and advice on what requirements and solutions will best fit a business’ needs, now and into the future. Working closely with key business decision makers as well as development and testing teams, we ensure the solution developed will meet the business’ requirements in an acceptable and sustainable way.

Business analysts aren’t limited to one task or activity

One of the reasons it’s so difficult to explain exactly what a business analyst does is because we never perform just the one task.

We’ll often wear many hats as our tasks, activities and responsibilities are always changing. Here are just a few of the things we might do in any given day:

  • Analyse business needs
  • Define a business case
  • Elicit information from stakeholders
  • Model requirements
  • Validate solutions
  • Project management
  • Project development
  • Quality testing

What a business analyst ‘does’ greatly varies depending on what project he or she is working on, what stage of the project they’re in, the stakeholders involved or even the organisation itself.

It’s not just about the title business analyst

It’s important to note that you don’t have to be called a ‘business analyst’ to do what a business analyst does.

Many perform business analyst activities as part of their existing role – data analysts, process analysts, change managers and user experience specialists all typically exhibit business analyst behaviour.

In fact, if you’ve ever worked on a small project where a business analyst wasn’t ‘technically’ involved, think again – it might have been you!

Celebrity head co2l web

For instance, if your department needed a software solution, perhaps you:

  • Spoke with your team about what everyone required the new software to do?
  • Asked how it should look and behave?
  • Prioritised what was needed by determining ‘must haves’ and ‘nice to have’?
  • Communicated these requirements to your IT team?
  • Clarified any IT issues or questions to provide more insight into delivery specifications?

Or perhaps in the course of your work you’ve:

  • Discovered inefficiencies/waste in an existing process?
  • Determined ways to improve a process?
  • Implemented change?
  • Tracked the results of change and measured its value to your organisation?

If any of the above sounds familiar, congratulations! You were doing what a business analyst does!

Business analysts are information conduits

Every project I’ve worked on has encompassed a wide and varied range of stakeholders – from managers to end users, vendors to customers, developers to testers, subject matter experts, architects and more.

All these stakeholders have different needs, goals and knowledge of the business. So it’s my job to bring all this knowledge together, analyse the information gathered and provide a clear understanding and vision for everyone to work with. I’m also inherently responsible for bridging the gap that exists between IT and the business.

I often compare business analysts to interpreters. Like translating French into English, we translate our business stakeholders’ needs into a language their IT or development team can understand.

Vice versa, we’ll interpret tricky IT questions and technical complexities for our business stakeholders in a way that makes more sense to them – so they can decide on how best to move the project forward.

Interpret col2 web

The final analysis

I hope these thoughts have helped explain what a business analyst actually does, or given you a way to definitively answer curious questions at that next BBQ.

While the tasks we do and the projects we work on will always vary, one overlapping theme remains – a business analyst helps facilitate a business to implement change.

We use our various skills, tools and techniques to clarify and define a business problem or opportunity, then work closely with all stakeholders to develop a solution that fully meets the business’ needs, today and tomorrow.

Suggested reading

My Job Title Is Not Business Analyst, But Am I One?

Explaining Business Analysis To Laypersons, Including Ourselves

7 comments

  • James Beck

    I loved the way this was explained and the use of cartoons. This is something all IT BAs should bookmark to share with people who don’t understand what they do. I personally believe the "problem" with defining what a BA does comes from the fact that there are actually 2 different levels of business analysis.

    The "high" level of Business Analysis will be hopefully be encapsulated by a future BABOK version. The meaning of the term at this level is vague because it does encompass so many different flavors of jobs and activities. Some of the items contained in this are Business Analyst, Process Analyst, Implementations Architect, Business Architect, Enterprise Analyst, Financial Analyst, etc. At this level it truly comes down to the IIBA trademark phrase of "Helping Business Do Business Better." There are so many jobs and activities which fit under this that it can seem impossible to combine them into one. I look forward to the future date when IIBA truly represents all the people under this level.

    The "low" level is where you get into specific types of positions. Historically this is what IIBA has focused on and BABOK v2.0 attempted to describe a guide for. You can see a lot of different titles at this level as well, with examples such as Business Analyst, IT Analyst, IT Business Analyst, Systems Analyst (sometimes), Business Systems Analyst, Requirements Engineer, Requirements Analyst, etc. It’s almost as if we try to confuse ourselves and each other!

    BABOK v3.0 is coming out April 15, 2015 and will be expanding the range of business analysis activities / roles that are "officially" covered by the BABOK and IIBA. I look at this as a good step towards that future where IIBA represents ALL Business Analysts of every stripe. It’s going to be a long road and will take time but I think that if we all work together we can succeed in getting there.

  • Kane Barton

    Great post Nina 🙂

  • Pauline

    Well done Nina!

  • Carlo

    Excellent article!

  • David Morris

    There is one main thing I would like to pick up on. BA’s “used to be” the “conduit” between the technical and non-technical members of the team. This is not the case these days, especially in an Agile development team. BA’s now focus on being the “facilitator” between the techo’s and non-techo’s, not the “conduit”.

    You may ask what is the difference between being a “conduit” compared to being a “facilitator”?

    As a conduit the non-techo’s leave it up to the BA to decipher the information from the techo’s and to translate it into something that the non-techo’s can understand. The BA is quite literally the meat in the sandwich here. Playing the role of the interpreter. BA’s were good at this and it allowed the techo’s and non-techo’s to not get frustrated with each other. After all the techo’s used to be propeller-heads speaking their own language and some lacked the ability to know how to communicate with the average person who possibly had very little involvement with anything more technical than using a VCR or microwave oven.

    Things have changed over years. The average person is now much more technically aware than they used to be.

    As a facilitator the BA is helping the techo’s and non-techo’s to talk to each other directly. You are there “along side” them, not “in-between” them. This does not suggest however that there is no need for a BA if the two teams can just talk to each other because the BA is required to use one of their key skills – Facilitation. The BA can help the two teams to ask and answer the “right questions” to ensure the right solution is delivered.

  • Donella

    Hi David, thanks for your comment! You’re right – as a lot of companies are increasingly evolving to become more agile, so too is the role of the business analyst. As you’ve pointed out, traditionally they were essentially the conduit whereas their evolution sees them becoming more of a facilitator.

    Arguably though, the business analyst as a conduit and as a facilitator is not necessarily mutually exclusive. A business analyst can be both simultaneously or at different times within the same project. The hat that they wear depends upon a variety of different factors.

    As Luka (Elabor8 Alumni) mentioned, the tasks business analysts perform depend “on what project he or she is working on”. Certainly in a waterfall type of project, a business analyst will more likely wear the “conduit” hat. However in a more agile environment, they will more likely wear the “facilitator” hat. Whatever role they assume, it doesn’t have to be at the exclusion or expense of the other.

    In an agile context, ideally the team is capable of self-organising. This means that they are theoretically able to determine the capacity in which their business analyst will be able to provide the maximum value. Whether this is as a “conduit” or a “facilitator” is at the team’s discretion. The role of the business analyst is by nature fluid and responsive and can easily serve either function.

Leave a Reply

Your email address will not be published. Required fields are marked *