So you want to be a Business Analyst 3— What good looks like
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 2 of this series I have discussed business analysis ‘specialisations’, why they are largely irrelevant and that, they provide for different entry routes into Business Analysis. In this post I will take a look at ‘What good looks like’.
Business Analysis defined
A bit of a rant here: In many traditional organisations the role of the Business Analyst is seen as a junior, clerical role (think ‘scribe’) who as part of career progression transitions into project management.
If you see Business Analysis as a junior role, basically a scribes, you are not only wasting your clients money, you are introducing major damage to your projects.
Let me explain why.
A definition first:
Business Analysis facilitates the ‘making sense’ of a problem domain by enabling teams to articulate information, explore items under discussion and converge towards a clear and common outcome.
Business Analysis consequently directly and indirectly drives a team’s efforts to deliver the most appropriate.
This cannot be a junior or clerical role. In fact, it is a highly difficult role to get right, as the answer to anything regarding this role usually is ‘it depends’. This is also the reason why straight forward knowledge of techniques and tools does make for an ok at best, dangerous Business Analyst at worst, certainly not for an Excellent one.
So what does ‘Good Look Like’?
Foundations
Excellence in Business Analysis is based on three aspects
- ‘hard’ skills (as foundation)
deep knowledge of the constantly changing landscape of available tools and techniques - ‘soft’ skills (as the core of what we do everyday and distinguishing factor)
capabilities that allow us to manage complexity and uncertainty and facilitate the journey from problem or opportunity to valuable solution - a mindset of high self-awareness and continuous learning (as working philosophy) to bring it all together and keep it alive
continuous (self) improvement and observation of one’s performance in general and in a given context is important for sustainable, quality outcomes, as well as motivation and joy in what we do
What good looks like
A good Business Analyst will help stakeholders and team members across all disciplines articulate information in the most appropriate way, at the required level of detail for that very moment, and shape this information into artefacts that drive incrementally towards an expected, valuable outcome. This will be based on the understanding that risk must be mitigate at the earliest possibility, complexities and unknowns tackled sooner than later, that change and uncertainty are facts and are to be seen as opportunities to learn and adapt; and that only high degrees of collaboration, (cognitive) noise reduction and high degrees of empathy and trust will allow for the autonomy and understanding required to get the best out of talent and thus the resulting solution.
This means being able to bridge the gap between finding the best way (process) to reason about the (domain) in the most appropriate way for those we work with (people).
Good Business Analysts understand that everything they create are either transient or supporting artefacts: requirements and specs are only valuable if they support implementation, manuals or guides are only valuable if they facilitate operation.
In the same way, any type of facilitation, be the strategy definition, requirements engineering or prioritisation has the only justification as little cog in the bigger machinery of facilitating delivery.
Good Business Analysts understand themselves not as creators but as crafts(wo)men-servants of their teams.
(If you have read my posts it should be obvious that I include clients and 3rd parties in my definition of ‘team’. Just saying…).
I have written more how Business Analysis will have to adapt to meet the demands of the 4th industrial revolution and about what I am looking for, when I interview Business Analysts. Both give more insight into the above.
