This post has already been read 5797 times!
Recently I have wondering a lot about the role of the ‘Business Analyst’, a role which I reluctantly use for myself, as it has such a wide variety of meanings and contexts.
By definition, the title ‘business analyst’ is very vague and naturally differs significantly depending on the context, corporate environment and personalities involved. I meet a lot of people who call themselves business analysts but really have no formal ‘analysis’ skills, would stare blankly when you asked them what a use case was and haven’t heard of the UML acronym. Now I’m not saying that every self-described BA necessarily needs to understand these traditional methods, but I want to drill into what I perceive to be the role of a BA and not the misnomer perpetuated by recruitment agents with a lack of understanding of the role.
The context – IT/Technology projects
The context of my definitions relate to the world of the IT, or whatever industry buzzword you want to call it, where software is developed to solve business problems.
The role – the generalist ‘Business Analyst’
In a simplified project model, we have several role types; developers, business analysts, testers and project management (remember I said simplistic model!). Within this limited and generalised role scope, business analysts are defining the requirements and assisting the development team with what they need to develop the application and solve the business problem.
Yeah, yeah. We all know what a business analyst does – they define requirements. They write a business requirements document. They either have a deep domain knowledge or liaise closely with those that do, and churn out documents which the development team diligently read and build from, right?
Well, while this certainly true and works in some organisations, this is not a good model. A business analyst does need to be a subject matter expert (SME) and being a SME does not automatically qualify you as being a business analyst. The larger an organisation is, the more prevalent and accepted this notion seems to be and how blurred the line between business analyst and SME becomes.
The cross-functional team and generalised specialists
A good project team consists of good people, skilled resources who work well together and apply their various skills to solve the over business problem, tackling small obstacles and changing requirements throughout the project’s lifecycle. Agile teams talk strongly about having cross-functional team members and there is interesting debate on the notion of the ‘generalised specialist’.
According to Scott (Ambler), a generalizing specialist is someone with a good grasp of how things fit together and as a result of this they tend to have greater understanding of what the team is working on.
In my view, everyone on the project team should be a generalised specialist. A business analyst does not need to know how to write code and participate in performance testing, but understands the concepts, participates in team discussions and has a few specialities which are accepted and can utilised the team. It is not uncommon for a cross-functional BA to perform comprehensive data analysis and modelling or a developer assisting the test team by writing a test harness to expedite performance testing.
So what’s wrong with the SME-as-BA model?
Nothing as long as it conforms to the above principals. The problem occurs with BAs who have strong subject (usually from many years in the business) but not a good grounding in analysis principals, methodologies and can not bring other skills to the project team. These SME resources are of course crucial to the project to provide insight and understanding of business operations, they may not be the best fit for the business analyst role.
Cross functional is the key
So how does a BA operate without having adequate domain knowledge? By having a varied functional toolkit, a BA can use their elicitation, modelling, analysis and documentation skills to engage the relevant stakeholders and produce the right outcomes (which are typically requirements documents but may be much more than just a single BRD) tailored for their audience.
I think the last part of the above statement is crucial – ‘tailored’ for their audience. Who are you producing the document for, is it a large development team, an offshore team, a single developer? Do they understand UML, do they like UML, do they prefer requirement statements, do they ignore documentation and develop from phone calls (most likely!) and how would you mitigate this by providing tailored documentation?
There is nothing worse than the template zombie phenomenon. Find the template, keep the structure, replace the content. This not only bores to death anybody who gets past page 5, it also severely constrains the BA to a certain way of thinking. Sure your organisation may have a defined process complete with templates but these can always be built upon – not blindly followed.
Tailor to your audience and challenge when there is a better way!
You might call it idealist, but challenging the status quo isn’t mission impossible. If you project/organisation has written BRDs with requirement statements as bullet points for 10 years that’s not a good reason for continuing to do so. Why not propose a quick use case model to structure your thoughts? PM doesn’t like use cases? That’s okay, you need them as part of your workflow so can do a use case model at least to map your thoughts, get the structure for things and take a few people on your journey, showing them how its useful, why you do it and how it all links in. Your PM still might not like it, but the development team finds it useful to get context and so you can include it. If you have found yourself being dictated what deliverables you need to produce and what they contain, you are not alone! Its not a great environment to work in but there is scope to change minds, and even if that is too politically challenging, then there is always scope to utilise your own methods and practices that might be beneficial for the team.