What a Business Analyst needs to know...

There is a never-ending discussion about the role "Business Analyst" and if you ask 4 experts about it you will get 6 answers....

I am in the IT since more than 30 years and I have worked in many different environments, always passionate about "Requirements" which I consider the most important thing for Business Analysts and affilliated roles.

The question behind this article "What a Business Analyst needs to know..." is IMHO very much related to the term Requirements and all its forms and ingredients, like User Stories, EPICs, Acceptance Criteria etc. Let's simply call all of them Requirements for now.

Given my history as "mature" IT consultant, I am used to looking at Requirements from different angles/roles like

• Sponsor
• Business Owner
• (Domain) Subject Matter Expert
• Product Owner
• Program Manager
• Portfolio Manager
• Project Manager
• Business Analyst
• Enterprise or IT-Architect
• Scrum Master
• Software Developer
• Tester
• User
• ...

All these stakeholders see Requirements from their perspective or viewpoints, therefore different views on Requirements become helpful or even necessary.

Let's try to start with a maximally simplified set of views: Why, What and How. It is no coincidence that these fundamental views correspond to the three BABOK? main types of requirements: Business requirements, Stakeholder requirements and Solution requirements.?

For a better understanding, here are examples for typical (here high-level for simplification) Requirements of these views at a fictional newspaper publisher.

Why: We need to strengthen our online presence as paper newspapers are read less and less.

What: Online content should be tailored to the reader's preferred interests to enhance their overall reading experience.?

How: For registered and logged in readers, an (artificial) intelligence selects and organises the content on the webpage, based on their reading behaviour so far. ?

For the Business Analyst, of course all viewpoints are of interest in the course of an appropriate stakeholder management. He or she needs to understand the Why from Sponsor, Portfolio Manager and Business Owner's perspective as well as the technical How aspects from the Developer Team. A Business Analyst is kind-of sandwiched between the Why and How, he or she is sitting on the What.

An for the What, the so-called Stakeholder Requirements, a Business Analyst should build up as much Know How as possible, since this is the core of the BA work. Let's enrich the drawing with two more circles of Know How:

The blue area shows the recommended knowledge areas in a sense, that a BA should be able to understand the stakeholders and their viewpoints, i.e., their concerns. For the outer light red area this applies as well, but with a lower intensity. E.g. for a BA it is mandatory to understand what a Domain SME and a Product Owner are about, while he or she will rarely go deeper into the analysis of the Sponsor's or Business Owner's thoughts. Of course this cannot be generalised, some BAs might be positioned differently, but I am sure that for most of the BAs these sketched relationships reflect the reality.

It goes without saying that a BA can better understand experts if he or she has a profound knowledge in the relevant area. A BA who has managed a project can better work with PMs, a BA who has been in a PO role can better support a PO. Depending on the situations in larger initiatives it is even possible that BAs slip into their neighbor roles - temporarily or permanently?- given they have sufficient skills. I.e., a BA can become a PO, a PM or an Architect. Try to experience this!

My recommendations for building up a broader Know How as a BA:

1. Get certified, study the BABOK? and become CBAP?! This proves that you have made yourself more than just familiar with the accepted Business Analysis best practises.
2. Gain Business Know How as much as you can! The more you know about your companies' business the better you can deliver value to Business.
3. Try to understand Enterprise and IT Architecture and work closely with architects, eventually study TOGAF? or other frameworks.
4. Project Management knowledge is mandatorily needed! Try to plan a certificate like PMP? or Prince2?. It generally helps and increases your sovereignty in difficult situations. If you don't want to lead projects and prefer staying in the analysis group, fine, but don't miss out equipping yourself with a profound PM knowledge!
5. If you are working with agile teams (who's not?) you MUST be able to be a Product Owner, at least from your knowledge point of view. If you don't want to become a PO yourself, you shall at least be able to be his or her stand-in e.g. during annual leave. Agile Knowledge more and more becomes a MUST, justified! Get certified, the best way to learn and proof that you have learned.

What's you next goal? Where are going in terms of improving your knowledge? What is your next certificate? Please let us know!

Check out what we do under www.masventa.de or join us at the European Business Analysis Day, in-person or virtually, March 23th 2023, www.ba-day.com.

It's all about Requirements, Requirements, Requirements !!!

Best

Rainer