A difficult task…

“What it is to be a Business Analyst”, believe it or not, a challenging question to answer. It’s not like “what is a software developer” or “what is an accountant?” It’s challenging to answer because while there are aspects of Business Analysis that are generally accepted in a broad way across the industry of IT, different companies and industries require their BAs to do different mixtures of these aspects. Then, on top of that, they will often require their BAs to do things that are NOT generally associated to Business Analysis.

Defining Business Analysis

Textbook

Personal opinions

More of a marketing line would be: “Business Analysts provide specialist analysis capability across both business and technical requirements, facilitating clear communication through documentation and understanding context.”

A bit more realistically: “Business Analyst tends to be a jack-of-all-trades or a T shaped individual with specialist skills in requirements elicitation, interpersonal skills and contextual documentation, with a broad range of other knowledge/skills varying from technical to domain-specific, which often results in Business Analysts filling gaps required for successful delivery of a project or body of work.”

Types and Responsibilities

Textbook

The problem solving model (Isaksen and Treffinger, 1985) provides another view on BA’s common activities/functions:

1. Mess finding – Understanding the complexity of a problem situation
2. Data finding – Discovering and documenting opinions, concerns, knowledge and ideas
3. Problem finding – Isolating the specific issue that needs to be addressed
4. Idea finding – brainstorming and working with subject matter experts to propose solutions
5. Solution finding – evaluating ideas and testing their validity prior to implementation
6. Acceptance finding – managing implementation of the change and measuring the benefits.

In the ideal world, a traditional Business Analyst will gather business requirements. A Solution Designer will convert to functional technical requirements. System Analyst will make sure it fits with existing processes. A Solution Architect will make sure it fits the technical platform/environment. A Strategic Business Analyst will make sure it fits the strategic goals.

Reality

In reality, all of this work gets done by whoever whenever wherever if at all. Most businesses move faster than technology and human resourcing can be delivered. Managers, promotions and budgets all add additional complications that make the Business Analyst role ambiguous. With all this in mind, a Business Analyst tends to be a jack-of-all-trades or a T shaped individual with specialist skills in requirements elicitation and other skills tapped when the need arises.

Because of this, a Business Analyst might have a range of tasks they’re asked to perform:

This means you benefit from gathering a wide range of skills:

You are not expected to be an expert in all of these skills (beyond the interpersonal), but each provides value to your role and position.

The BA Mindset

Since the perfect world and reality don’t line up, it helps to have a healthy mindset about the role and work itself. A few good ones to keep in mind:

• “Relationships are your most important tool”; Your job is around understanding the needs and wants of your stakeholders, so having trust is critical to ensuring they give you honest and useful perspectives. You will need to network and be friendly with people you wouldn’t normally meet, and try to smooth out political (or personal) sensitivities when they arise. You never know when you’ll need to call on a favour or a friendship to help get things done.
• “Empathy and active listening go a long way toward being effective”; As mediators and liaisons between business & technical teams, we have the unique responsibility of understanding and communicating two different perspectives. On the same day, we may have to dive into a business problem and understand the impact to the customer, then later, dive into a proposed technical solution and understand the implications of a decision. We have to grasp and inform both sides of the importance of these two perspectives. We have to morph these two perspectives into one unified goal. That can only be done by truly understanding what each party is going through; what are their pain points, what are the options, why should we choose one option over another.
• “The more perspectives, the better”; A range of stakeholders engaged captures more detail for your requirements and thus leads to better solutions, even if some of the advice/considerations are in conflict.
  • “Honest feedback and anecdotal evidence is gold”; Akin to above, people tend to give you some really quality feedback in person. You get some BRUTAL thoughts/advice/considerations/feedback that people wouldn’t be willing to put in writing, and that is where you can create absolute quality requirements/observations/recommendations.
• “I’ve not done it before, but I’ll give it a shot”; We tend to get thrown on projects without experience in the product or tool, so you might have to learn it in part. An attitude to pick it up and try learning a new skill helps your knowledge base, your ability to relate to people with lived experience, and will assist in the crunch of delivery.
• “Undocumented knowledge doesn’t exist”; People leave and their knowledge leaves with them, so take notes and keep your work well documented to reflect that you’ve actually done something. Otherwise everyone questions why you’re just in meetings not doing anything all day, plus when you leave the org loses all the insights you’ve gained.

Frequently Asked Questions & Reading recommendations:

Is Business Analyst the only title?

No, it’s definitely not! Most people think of a “Technical/Functional Analyst” when they think BA, as that the traditional view, but there are lots of varieties in titles that still fulfil that BA function we’ve elaborated on above. Some include “Strategy Analyst”, “Systems Analyst”, “Process Analyst”, and in some respects even the architect career path. The iiBA have a really good visual, that shows the entry level(ish) roles at the centre and go further out:

Why not just go into a technical role if you already have the technical knowledge?

For one, BA’s “generally” have more standard hours and don’t have to deal with weekend/on-call work. It also gets boring and limiting in your career being tied to a single technology, whereas a BA has a bit more flexibility to move around. You don’t have to code the tech yourself, nor do you have to run the business – you can sit in the middle and help make dreams become a reality.

Do you guys just attend meetings all day? Do you do any actual work?

It’s pretty common to spend half your day or more in meetings whilst you’re engaging stakeholders, seeking perspectives, etc. Plus there are the agile ceremonies that take up some time, and the general networking to retain favours and seek background. But there are points where you’ll spend days documenting, writing reports, formulating these perspectives into consice insights. And the times you do odd tasks like building reports, configuring systems, testing tools, and all the other odd tasks BAs are asked to do.

If you just talk to people all day but you’re not on the tools directly making things, what do you actually contribute to a project/team?

That’s a painfully, hurtfully common one. BAs capture and validate the needs/requirements of our customers/end-users, translate technical jargon into tailored business friendly language for simple understanding, document systems and processes. It’s largely a supporting role; understanding the context and doing the investigation to ensure the right decisions are made, and that everyone understands. One way to look at this is that BAs do a lot of the engagement and documentation work on behalf of technical teams, so they don’t have to.

If there is a break down in understanding, individuals are not clear in their needs/requirements, poor stakeholder management, incorrect context or assumptions, then a lot of resources get wasted on building/buying the wrong tools/systems/software. BA insights clarify these to yeild better results for everyone involved.

Book recommendations?

• ‘Business Analysis Body of Knowledge’ aka BABOK published by IIBA
• ‘BCS Business Analysis Foundations’ by Debra Paul, James Cadle and Donald Yaetes, published by BCS
  • Paperback ISBN: 978-1-78017-277-4
    PDF ISBN: 978-1-78017- 278-1
    ePUB ISBN: 978-1-78017-279-8
    Kindle ISBN: 978-1-78017- 280-4
• ‘User story Mapping’ published by O’Reilly

Other sites recommendations?

We made this as we found a few sites tend to be more prescriptive, whereas we generally try to take the approach that each BA role is unique and there isn’t a universally set standard of documentation or work.

• Practical Analyst
• Bridging the Gap
• Modern Analyst
• BA Times (they even have a decent templates section)
• Business Analyst.com
• The BA Mentor

Stefan Carton, Iannelli

Updated: 02/08/2022