So you want to be a Business Analyst 2 — All the things you could do…

Marcel Britsch
The Digital Business Analyst
5 min readOct 3, 2018

--

Over the recent months I have been approached by a number of people asking how they can get into ‘digital’ (read ‘software’ or ‘IT’) Business Analysis, be this as a lateral (often from software engineering or project management) or vertical (usually from classic waterfall mindset to a more product centric agile mindset) career transition.

Unfortunately the answer is not straight forward, as there is no defined formal career path, Business Analysis can mean very different things, and is closely related to other new(er) roles such as that of the product manager or product owner.

Anyway, I will try and provide some pointers for those trying to enter this role and inspiration for those already in it.

In Post 1 of this series I have discussed that excellence in business Analysis is all about mindset and less about tools and techniques. In this post I will discuss the various ‘areas’ of work one may come across as a Business Analyst and understand how these affect one’s skillset and career progression.

The Business Analysis ‘Continuum’

As with many other roles, the role of the Business Analyst is not strictly defined nor delineated, but exists in a continuum 3 dimensions

Business2Product — Delivery2Strategy — Industry

with different ‘weighting’ by each individual practitioner.

The first two dimensions are the most important in the sense of generic, transferrable skills. The question basically is whether you work at organisational, product or implementation level. Often this translates into whether you are strategic, product centric or technical, or whether you are defining or managing delivery.

There is no right or wrong, I have seen business analysts across all areas, though the best ones I have worked with in digital agencies and software consultancies are along the orange spectrum, often with a bias towards product or technology. The former often crosses over into marketing / user experience design, the latter into technical design.

It should also be said, that there is the role of the product owner, who strongly sites in the feature definition space and the product manager who is even more value proposition focused.

It should be noted that as each area of this continuum is an area of advancement it also forms a natural entry route into business analysis.

Industry experience

Interestingly, I believe that we we can ignore the industry dimension as part of this discussion. It is an add-on on top of the above, i.e. industry experience alone makes you a subject matter experts but in no way a Business Analyst, while a Business Analyst does not need to have any industry or domain experience.

I should maybe clarify that while Business Analysis skills are hugely transferrable I do not believe that there is an easy transition from, say IT into construction. However, within the software / digital space, I believe it is of very limited relevance of whether the software is for a bank, an automotive or medical company (given that being able to quickly grasp a domain is a key skill for Business Analysts).

In fact, I believe that industry experience can even be detrimental, when it leads to bias and blinkered views. As an external consultant, I, and the teams I work with, position ourselves in the space of experts in software analysis, design and delivery, and see our clients as the (industry) domain subject matter experts. Having said this, there may be clients and projects who justifiably look for experts in a specific industry to solve a clearly defined problem.

Career progression

While there is something to learn in all areas of the continuum (and I strongly suggest you explore each one in great detail!) and Business Analysts may move towards one side of the the above spectrum, career progression within Business Analysis is not defined by how well you can prioritise requirements or write user stories.

Real career progressions, from beginner to master is defined by a shift from following process, to adapting processes and tools to creating new ways of working, which does not show in better artefacts, but in better substance of these artefacts: better decisions and more valuable outcomes achieved by clients and project teams under the facilitation of the business analyst.

But this progression happens across all areas outlined above.

As a well rounded Business Analyst, you will have knowledge across the above areas, focused towards the centre of the orange area, and may then have preferences or specialisations in individual parts.

As I have mentioned in the previous post, it is all about mindset, rather than techniques or tools.

It should also be obvious from this that a progression from junior to senior BA is a highly valid career choice. If any extension is needed, the move towards product owner or product manager are progressions.
Business Analysis is never a junior role that progresses towards project management or solution architecture. These are lateral career moves.

You want to be an ‘agile’ Business Analyst — or do you?

Right, let’s get this out of the way: To deliver value and work within today’s high functioning teams you need to adopt a lean and agile approach. This means you need to be comfortable with concepts such as product thinking, hypothesis driven design, continuous delivery, lean and agile, just to mention some. If this is all new, don’t despair, it’s all common sense, and I will explain in a later post how to get there.

This shift in mindset, supplier to customer, from linear to agile, upfront to lean, must be internalised by any BA, no matter the actual methodology applied for delivery!

However! — and this is super important — I do not believe that all projects are best delivered following an incremental methodology, and not all of our ‘waterfall’ thinking that has so dominated the 80s and 90s is useless.

So if you have experience with waterfall methodologies, you will have a lot of valuable experience. The (hard) work that’s on you is then to make that tiny yet massive jump from avoiding to allowing for change and from upfront to incremental design. Again, I will explain below some inspiration on how to make the leap.

--

--