Business Analyst Core Skills: Assess Your Gaps

If a stakeholder just handed back your requirements document covered in comments, or a workshop you ran went flat and you’re not sure why, the answer is almost certainly a gap in one of the business analyst core skills. The good news is that naming the gap is more than half the work. This article gives you a structured way to assess where you are across seven skills, work out which gaps matter most for your next role, and start closing them deliberately rather than hoping the next project fixes things by accident.

The Seven Business Analyst Core Skills

The BA role varies between organisations, sectors, and methodologies, but the underlying skill set is remarkably consistent. Whether I’m working in a government waterfall programme or an agile product team in a utilities business, I’m drawing on the same cluster of capabilities every day. They fall into three groups: how you investigate, how you think, and how you communicate.

Elicitation

Elicitation is the active draw of information from stakeholders, documents, and observation. It is not the same as taking notes in meetings someone else runs. Most stakeholders cannot tell you what they need directly. They tell you what they want, which is usually a solution, or they tell you what they assume you already know, which is usually wrong. Good elicitation means choosing the right technique for the situation. Interviews work for one-on-one depth. Workshops work when you need shared understanding or trade-off decisions. Observation tells you what people actually do, which is often very different from what they say they do. If you’re not confident matching techniques to situations, the guide on types of elicitation techniques for business analysts covers the landscape clearly.

Modelling

Modelling is how you take messy information and turn it into something a stakeholder can look at and respond to. A process flow, a context diagram, a data model, a use case. The model is the conversation, not the filing cabinet artefact. If your diagrams sit on a server and nobody ever points at them in a meeting, you are decorating, not modelling. Early career BAs often skip this because it feels formal or because they’re not sure which notation to use. The notation matters less than the discipline of stepping back from the words and drawing the structure underneath them. Pick two or three models you can produce confidently and use them regularly.

Analysis

Analysis is the thinking work. It happens between the elicitation session and the document. You are looking for gaps, contradictions, assumptions, and patterns. You are asking why three or four times until you get to something useful. This is the skill that separates a BA who collects requirements from a BA who shapes them. It is also the hardest to develop because nobody can see you doing it. The output looks the same. The quality of the output is very different.

Requirements Documentation

Once you have analysed what you’ve heard, you need to write it in a way that is clear, testable, and traceable. That might be a business requirements document, a set of user stories, a functional specification, or a one-page summary. The format matters less than the clarity. If a developer or tester cannot act on what you’ve written without coming back to ask what you meant, the requirement is not done.

Stakeholder Management

You can be technically excellent at BA work and still fail because you cannot manage the people around it. Stakeholder management is knowing who matters, what they care about, how they prefer to be communicated with, and how to keep them engaged without overwhelming them. It is also knowing when to push back, when to escalate, and when to absorb pressure quietly. A solid stakeholder analysis at the start of a project is one of the most practical things you can do to get ahead of this.

Critical Thinking and Problem Framing

The best BAs do not just solve problems. They question whether the problem they have been handed is the real problem. This is the skill behind every good business case and every project that delivers something genuinely useful rather than just something that was asked for. Building a habit of challenging the problem statement early is one of the highest-leverage moves you can make as a BA. The business analysis problem solving techniques article goes deeper on this if it’s an area you want to develop.

Communication and Facilitation

This is the visible end of the job. Running a workshop, presenting findings, writing an email that gets read and acted on. Facilitation in particular is undervalued and underdeveloped in most BA teams I’ve worked in. Many BAs can chair a meeting. Fewer can actually facilitate a group through a real decision when there is genuine disagreement in the room. If this is a gap for you, BA facilitation skills is worth a read before your next workshop.

A Worked Example: When the Gap Becomes Visible

On a major case management system replacement for Organisation B, I was brought in as a second BA to support a colleague who had strong documentation skills but was struggling with workshop facilitation. The project had three distinct stakeholder groups with competing priorities, and the workshops had been running for six weeks without reaching agreement on a set of core process flows.

When I reviewed the session notes, the issue was clear. The workshops were being chaired, not facilitated. My colleague was presenting information and asking if people agreed. Nobody disagreed openly in the room. They disagreed afterwards, in emails and corridor conversations, which meant decisions kept being revisited. The process flows kept changing because the real objections were never surfaced in the sessions where they could be resolved.

When I raised this with my colleague, the pushback was immediate. The view was that the stakeholders were the problem: they were inconsistent and kept changing their minds. That framing was understandable but it was not helpful. The stakeholders were not changing their minds. They were expressing views they had always held but that the sessions had not given them a safe or structured way to surface. I suggested we redesign the next workshop to explicitly surface trade-offs rather than seek consensus, and that was not a comfortable conversation. My colleague felt it implied the previous sessions had been run badly, which to some extent they had.

We ran the redesigned session. Within ninety minutes we had surfaced four genuine points of disagreement that had been invisible in six weeks of previous workshops, got them discussed openly, and reached documented decisions on three of them. The fourth needed escalation, which was itself a better outcome than continuing to circle. The lesson I took from that project was not about facilitation technique. It was about how a gap in one skill can mask itself as a stakeholder problem for a very long time.

How to Assess Your Own Gaps

Self-assessment is difficult because the things you are weakest at are usually the things you avoid, which means you have the least evidence about them. Here is a structured approach that gets past that.

Step One: Score Yourself Against Your Last Three Projects

Do not score the skill in the abstract. Score it against your actual recent work. On each of your last three projects, ask yourself these questions honestly:

  • Elicitation: Did you actively draw information out using structured techniques, or did you mostly take notes in meetings someone else ran?
  • Modelling: Did you produce any models that got used in stakeholder conversations, or did you write everything down in prose?
  • Analysis: Did you challenge what stakeholders told you and look for contradictions, or did you capture and pass on what you heard?
  • Documentation: Did developers and testers act on your requirements without needing to come back to you for clarification?
  • Stakeholder management: Did you know what each key stakeholder cared about before they told you?
  • Problem framing: Did you push back on the problem statement at any point, or accept it as given?
  • Facilitation: Did you run any sessions yourself, and did they reach decisions?

Step Two: Ask Someone Who Has Seen Your Work

Your self-score is one data point. A trusted colleague or line manager is another. Ask them specifically which of the seven skills they would say is your strongest and which is your weakest. Do not ask if you are good at your job. That question gets you a vague answer. Ask about specific skills and you will get specific feedback.

Step Three: Look at What You Avoid

The skill you avoid is usually the skill you most need to develop. If you always volunteer to write the document but never to run the workshop, facilitation is your gap. If you love workshops but your documents are consistently vague or get queried, analysis or documentation is your gap. Avoidance is data.

Step Four: Match Gaps to the Role You Want Next

Not every gap needs closing right now. A junior BA does not need to be a master facilitator. A senior BA absolutely does. Look at the role you want in two years and work out which skills that role demands at a higher level than you currently have. Those are the gaps worth prioritising. For a wider view of how skills evolve across a BA career, the guide on business analyst skills and competencies is a useful reference point.

Skill Level Comparison by Career Stage

Skill Junior BA (0-2 years) Mid-level BA (2-5 years) Senior BA (5+ years)
Elicitation Interviews with support; structured questionnaires Independently selects and runs appropriate techniques Designs elicitation strategies for complex programmes
Modelling One or two models with guidance Produces and facilitates review of multiple model types Chooses models strategically to resolve stakeholder conflict
Analysis Identifies obvious gaps with prompting Identifies contradictions and assumptions independently Frames analysis to influence strategy and scope
Documentation Follows templates; requires review Produces clear, testable requirements with minimal rework Sets documentation standards for the team or programme
Stakeholder management Maintains relationships with operational stakeholders Manages competing priorities across stakeholder groups Navigates political complexity at senior leadership level
Problem framing Accepts problem as stated Challenges problem statements with evidence Reframes problems to align with organisational strategy
Facilitation Supports facilitation; documents outcomes Runs workshops independently; manages disagreement Designs and leads high-stakes facilitation for senior groups

How to Close the Gaps Once You’ve Found Them

Reading about elicitation will not make you better at elicitation. Running an interview, getting specific feedback, and running another one will. The same principle applies across every skill on the list. Deliberate practice with real feedback beats passive study every time.

  • Pick one skill per quarter. Trying to improve everything at once means improving nothing. Identify the gap that matters most for your next role and focus on it for three months before moving on.
  • Find a project where you can practise. If your current project does not stretch you, volunteer for a piece of work that does. Offer to run the next workshop. Offer to draft the business case. Visible practice beats private study.
  • Get feedback fast. After every workshop, interview, or document you produce, ask one person what could have been better. You do not need a formal review process. You need one honest answer from someone who was in the room.
  • Build a working toolkit. Templates, checklists, and prompts you actually use will move you forward faster than any course. The point is not to collect tools. It is to have a default approach you can lean on under pressure.

If you’re actively working on closing gaps and want to understand how this connects to your broader career direction, the article on how to close BA skill gaps fast covers the practical mechanics in more depth.

Core skills are not glamorous. They are not the thing that gets you promoted in isolation. But they are the foundation that everything else rests on. A BA with strong core skills can pick up any methodology, any domain, any tool. A BA with weak core skills will struggle regardless of how many certifications they collect. Start with the assessment, score yourself honestly against your last three projects, ask one person who has seen your work, look at what you avoid, and pick one gap to work on this quarter. That is how the best BAs I have worked alongside over twenty-five years have actually grown.

Frequently asked questions

What are the core skills of a business analyst?

The core skills of a business analyst are elicitation, modelling, analysis, requirements documentation, stakeholder management, critical thinking and problem framing, and communication and facilitation. These cluster into three areas: how you investigate, how you think, and how you communicate. Every BA needs a working level of competence across all of them, regardless of methodology or industry.

How do I know which BA skills I need to improve?

Score yourself against your last three projects rather than in the abstract, then ask a trusted colleague which skill they see as your weakest. Pay attention to what you tend to avoid at work, because that is usually your biggest gap. The combination of self-assessment, external feedback, and avoidance patterns gives you a reliable picture.

Is elicitation the most important business analyst skill?

Elicitation is foundational because everything downstream depends on the quality of information you gather, but it is not more important than analysis or communication. A BA who elicits well but analyses poorly produces neat documentation of the wrong things. The skills work as a system, not a hierarchy.

How long does it take to develop business analyst core skills?

Basic competence across the core skills typically takes two to three years of varied project work. Mastery in any single area takes longer and depends on deliberate practice with real feedback, not just time served. Focusing on one skill per quarter will move you forward much faster than waiting for experience to accumulate.

Can you be a successful BA without modelling skills?

You can survive without strong modelling skills, but you will hit a ceiling. BAs who avoid modelling tend to produce wordy documents that stakeholders skim and developers misinterpret. You do not need to master every notation, but you need two or three models you can produce confidently and use in real stakeholder conversations.

Try Ash, Your Virtual BA

If this article has helped you identify gaps in your core skills, Ash is built to support you as you work on closing them. Ash draws on a deep BA knowledge base including terminology, techniques, and structured approaches across every skill covered in this article, so you can look things up, test your understanding, and get practical guidance in the context of real work rather than abstract study. Whether you’re unsure which elicitation technique fits your current situation or you want to stress-test a problem statement before your next stakeholder session, Ash gives you a knowledgeable resource that speaks BA. Try Ash Virtual BA.

Further reading


Written by Sam Cordes, founder of the Business Analyst’s Toolkit.

We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept