How to be a BA – become a Scientist.

How to be a BA – become a Scientist.

The number of Blog posts, articles and discussions that ask or attempt to explain “How to be a BA” is a good indication that nobody really knows the ‘silver bullet’ answer. If you think you’ll find the perfect answer here…. don’t waste any more time reading on: I don’t have a ‘one size fits all’ answer either!

This is not because nobody actually knows what a Business Analyst is or does (although there are many Recruiters and Hiring Managers who obviously don’t!). It is perhaps because there are so many different types of BA, who do different things, in different roles, for different Projects and in different Organisations.

Click button to Read more…

While the techniques and skills a BA uses are common across a range of scenarios, just as Project Managers use common skills & techniques across their Projects and Developers in different environments using different Programming languages also use some common techniques, the sheer variety of roles and activities a BA can be found doing and the variety of Organizations that utilise BAs for their own purposes results in a wide variety of BAs. Asking someone to explain what a BA does will likely only result in an explanation of what ‘their’ BA did in ‘their’ Project – and much of it will have been invisible to most Stakeholders anyway!

There are a number of common activities a BA needs to be aware of and strive to master:

• Requirements Elicitation & Analysis
• Documentation & Communication
• Modelling & Diagramming

Much of what a BA does will usually fall within one or other of these very general headings. Some BAs are excellent at some but not so great at the others. With experience, we hope to improve on every facet. However, the most important thing a BA needs to do (in my view anyway) is not so much an activity as it is a mindset – and it is not so obvious.

BAs need to think like Scientists.

Now, I know that statement will cause some to respond with “Huh?!” and a raised eyebrow or two – but let me explain… I believe we are all born as scientists (note: without a capital ‘s’). As children grow and then go through school, they spend years asking curious question after curious question after curious question until they frustrate the patience out of the all-knowing but less curious adults around them. As a result, we ‘train’ this natural curiosity out of them and – for some, at least – we try to train it back in at University and then call them Scientists.

Curiosity is a gift and a curse, yet it is inherent in every one of us. It is what forms the basis of invention, innovation & progress – and it should be what forms the basis of everything a BA does. We just have to know when to stop asking questions, right around the time we are about to frustrate the patience out of the less curious (or all-knowing) adults – by which I mean Stakeholders, Sponsors and Matter Experts of course – around us.

The “Scientific Method”, on which modern Science (and, in a way, all modern R&D) is based, starts with a simple question or variation of a question: “What if…?”

Everything after that is about technique, skills, processes, results & conclusions. A BA should take the same approach, starting with “What if…?” or “Why?” (or a similarly questioning approach).

In my view, the most important thing a BA can do is to learn to ask questions in a deliberate and structured manner, whether that is just in their own mind or directed to Customers, Users, Business Stakeholders or Subject Matter Experts.

As a former University Lecturer myself (to both Undergraduate & PhD students), and having been an ‘Academic Researcher’ with a number of my own Research Papers published – all of which came about as a result of the ‘formal’ method – I am conscious that society views Academic Research as highly formalised and theoretical. It often is, but that’s not because it must be – that’s so the results can be be understood fully & repeated and so that anyone else can understand enough to reproduce the same results (or not!). In other words, it is necessitated by the intended use and the intended audience.

On the other hand, having also spent approximately 15 years working in the Commercial sector, in environments ranging from cutting edge Startup to highly Regulated and Governemnt sectors, I can also appreciate that many of the same personal characteristics that make for effective Scientists are also prevalent – and very, very useful – in BAs.

They include:

• Curiosity
• Observation
• Logic
• Creativity
• Skepticism
• Objectivity

In my work as a Business Analyst for more than 20 Clients/Projects over the years (some of it before I even knew what a Business Analyst was!), I deliberately try to play a particular role and I advise all BAs to take a similar approach, at least sometimes:

• Deliberately be the person who asks the “stupid question”. I often advise Clients / Teams that I plan to look stupid ‘so nobody else needs to’. Conveniently, this also allows me to ‘cover’ for when I really am completely in the dark, all the while appearing to be supremely professional!
• Deliberately be the person who challenges “the Boss” or “the Expert”. Many teams defer to experts or managers, sometimes without even noticing. An effective BA should ask for explanation / justification, as being knowledgeable or ‘in charge’ does not always equal being correct & often only represents one perspective. After all, there were times when the ‘experts’ and the ‘bosses’ insisted the Earth was flat and the Sun revolved around it.
• Deliberately challenge the Status Quo, particularly the idea that knowledge is correlated with Organizational or Team hierarchy. The most junior Stakeholder or the most newly-hired Team member is probably the one with the most unobstructed view of the real Requirement. Longer term stakeholders are often aware of the pain point more than the underlying Requirement and are often, understandably, more interested in removing the pain point than delivering on the Requirement.
• Deliberately be the person to ask “Why…?” or, just as importantly, “Why not…?”. Requirements are often stated by Stakeholders in the form of solutions. They might say “We want the system to do XYZ…”, as they think this will deliver on the Requirement. In fact, they might well be right – but it might not be the only (or even the best) way to do so. They might also be very wrong. The “Five Whys” is a great technique for getting to the heart of the requirement.

It all comes down to not being satisfied until your curiosity is properly, effectively & verifiably satisfied, no matter who you need to question to get there …in other words, be just like a pre-schooler, but more structured (and hopefully better paid!).

In the Classroom, I advised my Students “If you have a question, you can be sure someone else has a similar question”. By asking it, everyone benefits – even if it is only to confirm what everyone believed anyway. The same goes for Requirements Elicitation. If a BA has a question, it’s almost certain that someone else either has the same question or eventually would have. Some might even have answered it, and the answers can be used to explore what they see as the underlying justification. This is particularly the case when the question is something like ‘Why do we do this particular thing or do it this particular way?’. This tactic also allows BAs to draw Stakeholders out – particularly for BAs new to a Domain or Organisation (including Contractors or Consultants who can sometimes jump in and out of a variety of different Domains and Sectors every year). This is not to suggest that BAs are telepathic geniuses – but we’re usually good at thinking of appropriate (and sometimes inappropriate!) questions. Asking them – and actively listening to the answers – is one of the most important skills a BA can possibly have.

If a BA does not like asking (sometimes stupid) questions of (apparently) Expert Stakeholders, this is the area I would recommend they focus on. I can appreciate how hard it is to deliberately make yourself the centre of attention in a group of people with expertise, authority or seniority. Equally, I can appreciate how powerful a position that can be, particularly as an ‘outsider’ brought in to a Project. If you are not comfortable (or not at least capable of pretending to be comfortable) at the centre of attention, there are still other BA-type roles that require less interpersonal interaction but becoming comfortable in the middle & in the spotlight will widen the scope of an effective BA’s career.

Finally, at the heart of it all, what a BA does is about Communication. Whether that means conducting a group workshop to tease out requirements, leading a ‘blue-sky’ session of experts to discover potential solutions, or documenting and diagramming processes or systems, communication is key to the majority of all we do.

When I Lectured, I would often start with a statement on the Screen or Board behind me:

‘The purpose of Communication is for one person to provide information to another in such a way that it can be understood by the Recipient, not the Provider. If information is provided in a way the Recipient can not understand, then it is useless – and this is the fault of the Provider, not the Recipient’.

This was deliberately to encourage my Students to ask for clarification if they didn’t understand something – because their lack of understanding was my fault, not theirs. I try to take the same approach as a BA, especially in situations where the Organisation or the people involved are not familiar with the BA role (which happens surprisingly often – many Organisations think we exist just to write down a list of Requirements!). The BA’s task is simple in reality: gather, summarise and communicate information in such a way that the recipient will understand it. Given that there are a potentially wide range of types of recipients, it is important to understand the intended audience and produce appropriate documentation. If it’s for Programmers, a little bit of pseudocode or sample Code can be very useful. If it’s for Project and Business stakeholders, throw in some Diagrams, Charts or Screenshots (note: they especially like colours and pictures). The point it so allow them to easily understand it, so use something familiar to them – not just familiar to you!

So, while formal Training & Certification certainly have a role to play in developing a BA’s skills and career trajectory, as do the skills to produce models and diagrams, I believe the interpersonal characteristics and mindset are equally, if not more, important. In reality, everyone has the capability to be a BA, as long as we don’t train it out of them.