One of the most frustrating things about being a BA is that not everyone really understands what your actual role is (and this includes some BAs!). It’s not just trivial frustration either. If one of your colleagues has a mistaken belief about what you do (or don’t do), it can cause real problems. When that person is a senior manager or decision-maker, the problems can be significant, and have a negative effect on progress or quality.
So, to tackle some of the misconceptions and misunderstandings surrounding business analysis, here’s my myth-busting top 10.
1. BA is about crunching numbers
While it’s certainly true that good numeracy skills are generally found among BAs, business analysis is not the discipline of analysing data… that’s data analysis. Numeracy skills are an indicator of logical and analytical thinking, which is clearly important for BAs, hence the pattern. However, business analysis is about looking at the component parts of the business system and identifying what could be improved. Sometimes this involves using data to understand performance, but more often it is about investigating the underlying causes of problems with processes.
2. BA is a technical, IT-based job
I always cringe when someone uses the term technical BA. What does it even mean? A BA is ultimately concerned with the performance of a business system, and performance relies on the 5 components of POPIT working together… and IT only makes up 40% of POPIT. More often than technology, it’s processes or people that play the biggest part in a business’ success.
3. BAs are junior PMs (or worse, junior to PMs!)
Please! Project Managers and BAs could not be more different. A project manager coordinates the different resources working on the project and ensures the work gets done according to schedule/scope/budget. A BA has a very specific role to play as one of those resources. The career path of a BA does not go to PM. BAs might sometimes manage smaller projects in order to get them over the line (for instance, the development of a PowerApp that they have defined the functionality for), but other than that, there is no crossover between the roles.
4. BAs are just general, non-specific staff
If you work with someone who thinks this, they need to be corrected. BAs deliver specific products which are then used to make big decisions upon, or to be used as critical information upon which to build important products. We’re not here to just take notes in meetings.
5. BA is just about requirements
This is the laziest description of what a BA does… and it’s also absolutely false. Requirements are often an important BA deliverable, but requirements do not exist in a vacuum. A huge amount of work and analysis has to happen before we get to the requirements stage. If all we did was document requirements, those requirements would probably not be very good, since they wouldn’t be based on solid analyses.
6. BAs mainly do documentation
Just no. Documentation can be very useful and important… if it is useful and important! Most projects tend to produce colossal volumes of documentation that never gets read or used in any way. In software development, Agile tried to stop all that. What really counts is value. Knowing what information needs to be documented so that it can be used effectively in the value chain is an important BA skill.
7. There’s no structure to business analysis
When starting out in business analysis, it can seem quite random and overwhelming. Where do you even start? Well, that’s exactly why structure is essential. And, that structure is there, although it can be quite difficult to get to grips with at first. But, that’s why a career in BA is so rewarding, because as you cut through the noise and confusion, it suddenly starts to make sense, and before you know it, you are a zen master… like Keanu Reeves in The Matrix… but with business process diagrams and acceptance criteria.
8. BAs build solutions
This is a common trope, especially seen in troubled projects where unexpected hitches keep popping up. Managers will frequently look to BAs to develop solutions. However, BAs develop requirements. Requirements are solution-agnostic, meaning they can be satisfied in several potential ways. It’s not (usually) the responsibility of the BA to develop the solution. That said, a BA who can also develop simple solutions, like PowerApps is probably a valuable asset.
9. Anyone can become a BA overnight
Business analysis requires a set of skills and qualities that take time and aptitude to develop. Some of those skills are easier to gain than others, and some qualities are simply either there or they aren’t. If a person has no empathy or they’re not naturally inquisitive, for instance, then they probably won’t be a great BA. Some of the more technical skills, like modelling in UML or writing good requirements, can take a lot of time and focus to learn. However, the real key to becoming a BA is understanding the bigger picture, the superstructure of business analysis, and being able to identify or determine what method or tool to use when, and why. And that level of understanding takes a long time to achieve.
10. BAs aren’t important on projects
Big projects rarely run smoothly. Often this is because something has been overlooked, or the reason for doing something has not been fully thought through. And this is often because good business analysis has not been done in the early (or even pre-) stages of the project. Many huge digital transformation projects set out their intentions in a big document, stating what the project will deliver. However, rarely do these projects consider the impact on the people or the processes that the new digital technology will support. Usually, these elements tend to be done (as an afterthought) during the project, and a raft of business change measures must then be developed. These are of course in the BA’s domain… but it would be nice to do them in the proper timely fashion!
Now, all we have to do is send a link for this blog post to everyone you work with who just doesn’t seem to get BA, and we’ll crack it!
Let me know what I missed in the top 10, and if you disagree with any.
Shout out to Andrew and Lucy for contributing with thoughts, ideas and discussion.
Comments