# Business Analyst Soft Skills: Five Situations That Test Them Canonical URL: https://headwayskills.com/knowledge/soft-skills-at-work/business-analyst-soft-skills/ Markdown URL: https://headwayskills.com/knowledge/soft-skills-at-work/business-analyst-soft-skills.md Entity type: Article Last updated: 2026-07-07 Language: en Primary audience: professionals improving communication at work Owner: Headway Skills Contact: https://headwayskills.com/contact/ ## Short answer Business analyst soft skills in practice: elicitation, facilitating vs. influencing, negotiating scope, bridging business and IT, and lasting stakeholder trust. ## Key facts - Title: Business Analyst Soft Skills: Five Situations That Test Them - Category: Soft Skills at Work - Primary skill: Communication - Related skills: Influence, Teamwork - Primary keyword: business analyst soft skills - Source page: https://headwayskills.com/knowledge/soft-skills-at-work/business-analyst-soft-skills/ ## What this page covers - Business analyst soft skills in practice: elicitation, facilitating vs. influencing, negotiating scope, bridging business and IT, and lasting stakeholder trust. - Practical guidance for business analyst soft skills - How this topic connects to Communication ## Detailed explanation Business analyst soft skills are the people skills that turn analysis into agreement: asking questions that reveal what stakeholders actually need, listening for unspoken assumptions, negotiating scope, keeping business and IT working together, and earning support for recommendations you cannot impose. In this role, they are how the work gets done. That can be a surprise if the analysis itself is what drew you to the job: the models, the process maps, the clean logic of a well-written requirement. Those are the parts you can learn from a course. The harder part is the meeting where a stakeholder describes the solution they want, and you have to find the problem underneath it. Most of that harder part comes down to five situations, each one specific to the analyst's position. ## What business analyst soft skills look like in practice The profession's own body of knowledge is explicit about this. The IIBA's BABOK Guide v3 counts soft skills among its underlying competencies and splits them into two areas. Communication skills cover verbal, non-verbal, written and listening skills. Interaction skills cover facilitation, leadership and influencing, teamwork, negotiation and conflict resolution, and teaching. The split is a useful one: communication moves information accurately between people, while interaction moves people toward agreement. Being clear and being persuasive are two different jobs, and they fail in different ways. The IIBA's newer Business Analysis Competency Model v4 keeps the two areas separate as well. What follows is how those competencies play out in the situations a new analyst actually faces. ### Elicitation is a conversation, not a form BCS, the Chartered Institute for IT, describes the junior business analyst role as built around information elicitation techniques and analytical thinking. Elicitation happens mostly in interviews, workshops and conversations. So the first thing you are judged on as a junior analyst is, in practice, how well you run a conversation, and that starts on your first project, not after a promotion. The core difficulty is that stakeholders often arrive with a solution already in mind. They ask for a new report, an extra field, a dashboard. Your job is to separate what they want from what they need, and to bring the assumptions behind the request into the open. Open-ended questions do most of this work: what decision would the report help you make, what happens today when that information is missing, who else relies on it. Paraphrasing the answer back, in your own words, shows whether you have understood or only recorded. The cost of skipping this step shows up later. A requirement written down before the need behind it is understood is the most common source of rework, because the solution gets built correctly to the wrong specification. ### Knowing when you are facilitating and when you are influencing In a [requirements workshop](/knowledge/communication/effective-meeting-management/), you often hold two roles at once. Facilitating means guiding the group neutrally toward its own outcome: keeping the discussion on track, making sure every view is heard, recording what was decided. Influencing means actively persuading the group toward a particular direction, usually because your analysis points there. Both are legitimate, and most analysts need both in the same meeting. The trouble starts when you switch between them without saying so. Stakeholders who expected a neutral chair and then feel steered toward a conclusion tend to stop trusting the process, even when the conclusion is sound. The remedy is simple and a little uncomfortable at first: name the switch. Tell the group you are stepping out of the facilitator role for a moment to give your recommendation and the reasons for it, then step back in. ### Negotiating scope before it creeps Scope creep looks like a discipline problem, but it is more often a symptom. When the boundary between what is in scope and what is out was never agreed and written down with stakeholders, it is hard even to tell whether a new request counts as creep. [Negotiation with business users](/knowledge/communication/communication-and-negotiation-skills/) is how that boundary gets set in the first place, and how it gets defended later. For someone early in the role, the instinct is usually to accommodate every request, because saying yes feels like being helpful. Reframe it. Proposing a trade-off is part of the analyst's job, not a failure of goodwill. Agree on the boundary early and in writing. When a new request arrives, make the consequence visible: this can be added if something else moves to a later release, or if the deadline moves. Stakeholders can then make the choice themselves, with the cost in front of them. ### Standing between business and IT Business analysts usually sit between business users and the IT or delivery teams, and the disagreements between those groups, over resources, priorities and scope, tend to land on the analyst. Handling that well means keeping each disagreement on the substance of the requirement rather than on the people involved, and preserving trust with both sides, because you will need both for the rest of the project. Part of the job is learning to speak both languages. You need enough of the business vocabulary to understand why a requirement matters, and enough of the technical vocabulary to understand what it will take to deliver. If one side of that line still sounds foreign to you, that is a normal starting point. One of the young people we interviewed about starting work described how the vocabulary finally became clear: > I remember that our onboarding process involved a whole series of introductions to different departments and people across the organization. > > At the time, I knew very little about the IT world, the different solutions, or much of the terminology being used. So even though I was meeting people and being introduced to their areas of work in a fairly formal and structured way, I often came away without really understanding what they were talking about. > > It wasn't until I started having more informal conversations with people — asking questions and talking things through in a more relaxed setting — that it really began to make sense. Formal introductions give you the map of who does what. The informal conversations she describes are where an analyst learns what each side actually cares about, and that is the knowledge you draw on when the two sides disagree. ### Relationships that last the whole project Junior analysts tend to struggle with the same three things: eliciting incomplete requirements, neglecting stakeholder relationships and over-documenting. The three are connected. Producing another document feels safer and more measurable than going back to a stakeholder with an awkward question, so the document gets written and the question stays unasked. The remedy runs the other way: listen actively, clarify ambiguity early, and build stakeholder relationships on purpose rather than as a side effect. [Stakeholder management](/knowledge/influence/stakeholder-management/) is also continuous across the whole project lifecycle, not a task you finish at kick-off. Priorities shift, people change roles and pressures build. Relationships that were only built in the first week tend to fail exactly when a difficult change request arrives. Short, regular check-ins, not only when you need a sign-off, keep the relationship in working order for the moment you need it. If you read these five situations and already know which one you would rather avoid, that reaction is worth taking seriously. A short [look at your own work skills](https://assessment.headwayskills.com/) can show whether it points to a broader pattern, and any gap it reveals is a behavior you can practice, not a verdict on your fit for the role. ## The skills that make these conversations easier Look back across the five situations and the same few capabilities keep appearing, whatever the methodology, the tool or the size of the project. **Communication** is the raw material of elicitation. It starts with a genuine desire to understand, which is what keeps you asking questions after the first answer, and it relies on listening closely enough to hear the assumption inside a request. It also means choosing the right medium: conversation for anything complex or sensitive, writing for documentation and confirmation. Stating the main point first in a requirement, and running workshops with a clear purpose and minutes, are what let both business and IT read the same page the same way. **Influence** matters because analysts rarely own the decisions they shape. Without formal authority, your influence rests on a reputation for straight-talking, reliable analysis. Before a workshop, it helps to understand what each stakeholder stands to gain or lose. In the room, it means presenting the drawbacks of your recommendation as well as its benefits, listening fully to objections before answering them, and settling for a small win when a full yes is out of reach. Afterward, it means following through until the change is actually implemented. **Teamwork** keeps the space between business and IT from becoming a front line. When both sides experience you as part of a shared effort rather than a messenger, disagreements stay on topic and trust survives them. That trust is built through reliability, doing what you said you would, and through sincerity. When a prioritization decision goes against your recommendation, the move is to disagree openly, then commit and help make the decision work. The **free Job Skills Test** can show you [where to start practicing](https://assessment.headwayskills.com/) before your next stakeholder meeting. It measures these three alongside **nine other work skills**, and because each one is a set of behaviors rather than a talent, a low score marks a place to begin, not a ceiling. You may notice that some of this already shows up in how you work. If you have ever caught yourself rewording a stakeholder's request back to them to check you had it right, you were already doing the core move of elicitation. The rest can be built the same way, one conversation at a time, without becoming a different kind of person. The skills worth building first depend on where you stand right now, and they tend to carry more weight as the projects, and the stakeholders, get bigger. ## See where your skills stand The only step left is to find your starting point. The Job Skills Test is a **free** self-assessment of your work skills: it shows where you stand across all twelve, and which ones would make the biggest difference in your work as an analyst. It takes about 7 minutes, and you can go through the results at your own pace. **[Get my skills profile](https://assessment.headwayskills.com/)** *Free, takes 7 minutes, results shown instantly.* ## Who this is for - Professionals building practical workplace skills - Readers looking for specific, usable work advice - Managers, educators, and coaches supporting career readiness ## Common questions ### What is this guide about? Business analyst soft skills in practice: elicitation, facilitating vs. influencing, negotiating scope, bridging business and IT, and lasting stakeholder trust. ### Which Headway skill does this connect to? This guide connects primarily to Communication. It also relates to Influence, Teamwork. ### What is the recommended next step? Use the free Work Skills Test to reflect on which work skill to improve next. ## Related pages - https://headwayskills.com/knowledge.md - https://headwayskills.com/knowledge/soft-skills-at-work.md - https://headwayskills.com/knowledge/communication.md - https://headwayskills.com/knowledge/influence.md - https://headwayskills.com/knowledge/teamwork.md - https://headwayskills.com/work-skills-test.md ## Citation guidance Use the canonical page when citing this content: https://headwayskills.com/knowledge/soft-skills-at-work/business-analyst-soft-skills/ Preferred summary: "Business analyst soft skills in practice: elicitation, facilitating vs. influencing, negotiating scope, bridging business and IT, and lasting stakeholder trust." ## Change log - 2026-07-07: Content collection version published.