The top 5 skills every Business Analyst must have
Updated: Apr 18
Business analysis is composed of many techniques and methods, but some are more commonly needed, more useful and more powerful than others. While some of the more esoteric ones (e.g. Boston Box or Cynefin) might impress your colleagues when you pull them out of your hat, you might struggle to shoe-horn them into your actual work. Whereas other methods are so general, it may raise a few eyebrows around the office if you weren’t able to just do them on command.
It stands to reason that many of the most common methods are going to be among the most useful, since those are the ones that are most frequently called upon. That said, there are others that are extremely useful (and absolutely essential, in certain circumstances) but are a bit tricky to learn, so get left on the shelf.
From my own personal experience, working as a Business/System Analyst, in different environments, there are some techniques that every BA should have a strong working knowledge of, and be able to perform competently without too much revision or resorting to Google.
In the list below, I name the 5 most useful, powerful techniques that are absolutely essential in every BA’s quiver… in my opinion!
1. Business process modelling (BPM)
BPM is so important that it easily tops my list. It’s one of my favourite things to do (in a work context), is easy to learn and is highly effective. To really understand and appreciate the value of BPM, let’s look at what is, how it’s used and why it’s important.
A business process is a sequence of activities or tasks that produces a product or service for a given customer.
A model is a simplified, artificial representation of a real world thing, minus any unimportant tiny details.
So then, a business process model is a diagram that represents a real world business process, drawn at a level of detail that enables investigation, measurement and analysis.
BPM has many uses, but here are the main ones:
To enable analysis of the process (to identify inefficiencies)
To enable automation (finding where tasks could be done by a machine, for example)
To identify weaknesses in the process
To communicate how something is done (e.g. for training purposes)
To ensure consistency of process execution
I go into more detail about BPM in my Intro to BPM blog, but suffice to say, it’s one of the skills every BA should have a strong capability in.
A well organised workshop is the most efficient way to capture information and perspectives from a group of stakeholders. It is also a great way to reach consensus, without having to go through subsequent, painful rounds of review and approval with stakeholders individually.
Workshops also give everyone the opportunity to discuss and debate issues, and therefore can be good for baselining understanding within the group… an added bonus.
There’s a lot to consider when executing a decent workshop, and the relevant section in BCS’ excellent Business Analysis Techniques (James Cadle, Debra Paul, Paul Turner) covers the subject comprehensively. For now, all I’ll say is that the workshop technique is a 3-step process: Plan, Conduct, Follow Up, and there are 3 roles: Participant, Scribe, Facilitator (ideally the BA). Ignoring the process and the roles will land you in difficult territory and you risk a wasted afternoon and a lot of disgruntled stakeholders.
The thing about workshops is this: they are difficult and unpredictable to run, which is why the planning step of the process is so important. It’s very easy to hold a bad and/or ineffective workshop, but running an effective one, which delivers the desired outcomes, takes skill, courage, preparation and confidence, which in turn can take a lot of practice and experience to develop. Probably why it’s such an important competency to have in your quiver!
While workshops are the big, powerful move for getting information from stakeholders, interviews are the more subtle and precise method. This is because they are (almost always) one-on-one, and therefore conducive to the interviewer being more inquisitive and the interviewee being more open and honest. You are much more likely to get ‘off the record’ comments, which reveal aspects of the situation being investigated that just wouldn’t be surfaced when everyone is on their best behaviour in a workshop.
Interviews are also a great way for a BA to get professional exposure to more senior stakeholders, giving them the opportunity to impress and earn their trust, which can only be a good thing for improving the credibility and profile of the BA profession.
Interviews are less technical than other methods, but require more personal qualities, such as empathy, emotional intelligence, strong communication skills (which includes listening as well as articulating), persuasiveness, inquisitiveness etc. That said, a good bit of preparation is highly recommended. I suggest, as a minimum, you go into the interview with an understanding of the facts about the situation, some awareness of subjective opinions and different perspectives, but an open mind. Therefore, a decent amount of contextual research is in order. Not only will this background knowledge enable you to hit the ground running (and mitigate the risk that you’ll get completely lost in unfamiliar detail, fast), but it will also likely impress your interviewee and foster a good interaction between you.
4. Business Activity Modelling (BAM)
BAM is another favourite of mine, and frequently overlooked and under-used. BAM is the technique of mapping out the things an organisation needs to do in support of its central purpose in order to create a conceptual model. It is the What, whereas BPM is the How.
BAM is done using 5 types of activity:
Do: this/these are the central activities aka primary tasks of the organisation. It’s the purpose of the business, especially from a customer’s perspective. For instance, Audi’s Do activities would be make cars, and sell cars.
Enable: these are the activities that supply the inputs and resources required to execute the Do activities. In our Audi example, they would be procurement of the raw materials required for car production, hiring skilled employees etc.
Plan: Plan activities are more strategic and are about determining and defining how to move the organisation in the right direction. A good example for Audi might be to set out milestones for switching to electric vehicles, and the research and objective setting activities to realise those plans.
Monitor: these are the activities that collect and review performance information. As the Do activities are performed, the results are collected and reviewed by the Monitor activities, to enable performance management and decision-making to take place. An example would be to monitor sales volumes of cars, in order to identify if strategic actions are paying off. Thus, this type of activity is downstream of the Do activities.
Control: with monitoring in place, the organisation is enabled to make informed decisions as to how to manage the business. Control activities can impact on any of the other types of activities.
You start with the Do activities (since these are the things that deliver value directly to the customer). From there, you determine what those activities are directly dependent upon – any activity you identify as a dependency is an Enable activity. Once you’ve identified all the Enables, you then work out what Plan activities they are dependent upon. After completing this process of working backwards, you now have the majority of the model done. You can then determine which of your activities can be monitored (again, linking them through dependency), and each Monitor activity should lead to a Control. And, you’re done.
What makes this technique so powerful is that it’s a very easy and simple way to model an entire organisation. And from there, you can start to consider the resources that will be needed to undertake these activities. If I were asked to design an entirely new organisation, this is how I would start. And I reckon if you were to present a BAM diagram to a senior manager in your current organisation, you’d definitely grab their attention right off the bat, since BAMs are easy to read and interpret, yet provide a great deal of information.
5. Ishikawa Root-Cause Analysis
One of the absolutely essential responsibilities of the BA is to lead the problem-solving effort when serious failures occur. Strategic and developmental BA work is great, but ultimately, if there is emergency in business-as-usual operations, or a persistent bug causing the organisation relentless irritation, like rubbing a raw nerve (wince), then the reality is, that will take priority over the good stuff.
For this reason, the BA should be able to roll out the trusty Ishikawa, or, fishbone diagram, named after Karou Ishikawa, the Japanese engineer who popularised the technique, as well as other contributions to the field of quality management.
Ishikawa diagrams are an accessible way to undertake root-cause analysis for a problem. In brief, the method is to draw a fishbone diagram – a fish head, a straight spine leading from it, and several (usually 5 or 6) bones splaying out from the spine. The head represents the observed problem, and the bones represent the primary causes of that problem. Before you start identifying the causes, you should give each bone a theme. The classic themes (since the technique arose through the manufacturing industry) are: Manpower/Mind Power, Machine, Material, Method, Measurement. However, there are many variants that can be used, and a little online research will help you find which categories work best for your context. Then, you simply brainstorm (ideally, in a workshop setting, with relevant stakeholders) what factors contribute to the problem, prompted by the themes. Write these down on post-its and stick them onto the corresponding fishbone on your diagram. Then, and here’s the beautiful part, you simply identify the causes for each of the causes you’ve identified – these are known as secondary causes. Repeat this process (5 steps are commonly needed, hence the related technique: 5 Whys) until you arrive at the root causes.
You now have a list of several root causes, which you can take to your next management meeting to address.
It’s an interesting and challenging process, because it will inevitably unearth unpopular conclusions regarding root causes of problems, often cultural, top-down issues. But, the key thing to note is that you have arrived at these root causes through a logical, methodical, and ideally, unbiased process, so if the organisation genuinely wants to address performance problems, it cannot ignore the findings.
When writing this post, I had to ruthlessly edit in order to keep the list short. However, it wouldn’t be right to not give the following methods an honourable mention:
Use case diagram/Use case description
State machine diagram
So, that’s my list. What do you think – agree or disagree? What have I missed out? Leave a comment, hit like, share…