OUR DISCIPLINES
Business Analysis
in South Africa.
A system can be built perfectly from a poor spec, Business analysis is the work that stops this very thing from happening. Every other role in a delivery team owns how well it gets built, the BA owns what gets built and whether it still answers the need by the time it lands.
This is how business analysis really works in South Africa: the people who turn business intent into something a technical team can build, and who carry the cost when the intent was never properly understood. The roles, the market, and what it takes to get the hire right, whether you’re building the team or building your own career.
A LOOK AT THE MARKET
The business analysis
market in South Africa.
When looking at the varying disciplines that make up the tech market, almost every discipline is judged by what it produces. While Business Analysis is judged largely by what it prevents, and prevention leaves no evidence. Nobody walks past a working release and thinks about the six weeks of build that never happened because somebody asked the right question in week one.
South Africa has a very large population of business analysts, considerably larger than most technology disciplines, because the banks, insurers, retailers and telcos built substantial BA functions over two decades and the consultancies trained a steady stream more. Depth of supply is not the problem here, reading the supply is.
The pool is wide and the standard inside it varies more than in any other discipline we recruit for. Two people with the same title, certification and years of experience can be doing fundamentally different jobs. One focused on writing down what a stakeholder asked for, the other working out what the business actually needs and being willing to say so to someone senior, while both are called a business analyst, you’ll find only one of them changes an outcome.
Agile made this harder rather than easier with the introduction of squads. As a result some businesses moved their analysts into product owner roles, some kept both and never defined the boundary, and others quietly decided that analysis was a tick box rather than a skill and let the function thin out. A few years on, a lot of businesses are hiring analysis capability back, sometimes under a different name, usually after a delivery that went exactly to plan and still did not land.
The other force driving demand is change the business did not choose. POPIA, payments modernisation, new reporting standards, core platform replacements, old systems being switched off. All of these produce work where the analysis is the hard part and the build is comparatively routine. That work is disproportionately where the strongest analysts sit, and it is the reason a business that has never hired for regulated change often struggles to compete for them.
THE TITLE
What 'Business Analyst' in a job title actually means.
Business Analyst is the least standardised title in the South African technology market. It’s used for a requirements writer, a process re-designer, a data analyst, a systems specifier, a project coordinator, a product proxy and, in some businesses, a fairly senior person who is effectively deciding what gets built. The title tells you almost nothing on its own, which makes reading a CV in this discipline a genuinely different exercise from reading one in software engineering for example.
The question worth asking is whether the person has the authority to change the answer, or to only record it. This distinction impacts everything the BA touches.
An analyst who records requirements produces a document that reflects what they were told, and their skill is judged on completeness and clarity. But an analyst who changes the answer goes back to a stakeholder and says the request will not achieve what the business is trying to achieve, then holds that position despite the response.
There is no doubt that the first job is useful, but the second job is the one that saves you money, and requires something the first one does not, which is the willingness to be the least popular person in the meeting to ensure the right outcome.
When looking to hire, be aware that BA Certifications will not tell you the difference between the two. Plenty of South African analysts have solid formal foundations, often through the IIBA, and it’s worth having, but that just tells you they’ve been taught a method. It doesn’t tell you they’ve ever used it to stop something going ahead.
Years of experience will not tell you either. Someone can spend eight years capturing requirements accurately, inside a process somebody else designed, and come out with a great CV and none of the experience that actually matters.
If you’re hiring, write the job spec around the decision the person will own rather than the documents they will produce. If you’re deciding your own next move, be honest with yourself about which of the two jobs you have actually been doing, because the interview in a serious business gets to it in about twenty minutes.
THE ROLES
The roles, and what each one involves.
Each of these roles is essentially a translation job. What changes from one to the next is who sits on either side, how far apart they are, and how much authority the analyst has in the middle. When it comes to tooling in this discipline, it changes slowly and matters less than in most
however, the shape of the gap matters far more.
Agile business analyst
Works inside a squad, close to the build, breaking business intent into work a team can pick up and refine. Judged on whether the team stops asking questions the analyst should have answered before the sprint started. Often the level where the boundary with product ownership needs deliberate definition rather than assumption.
Common tools: Jira and Confluence, user story and acceptance criteria practice, backlog refinement, process and journey mapping, and BDD-style specification.
Business analyst, financial services
Operates where product rules, regulation and legacy systems meet, which in this market usually means banking, insurance, lending or investment. The domain is the value: knowing what a premium, a reconciliation, an affordability rule or an interest calculation actually has to do saves months of clarification. Overlaps closely with the fintech engineering discipline.
Common tools: regulatory requirement mapping, product rule documentation, SQL, data mapping and lineage, and core platform functional specification.
Business architect
Works above individual projects, describing how capabilities, processes, systems and information fit together, so that change can be assessed against the whole rather than one programme at a time. A small field in South Africa, mostly found in large institutions, and valued when a business has learned the hard way what uncoordinated change costs.
Common tools: capability and value stream modelling, TOGAF or similar frameworks, ArchiMate, operating model design, and roadmap and impact assessment.
Business process analyst
Studies how work actually happens rather than how the process document says it happens, and redesigns it. The role most likely to surface the uncomfortable finding, because the real process usually contains a workaround somebody built years ago and nobody has mentioned since.
Common tools: BPMN, process mining and time and motion analysis, Visio or Lucidchart, workshop facilitation, and control and handoff mapping.
Change analyst
Handles the part of delivery that determines whether anything is actually used: who is affected, what they will have to do differently, what training and communication is required, and what will break operationally on the day of go-live. Frequently the difference between a system that is live and a system that is adopted.
Common tools: impact assessment, stakeholder analysis, training needs analysis, adoption and readiness tracking, and structured change methods such as ADKAR.
Data & reporting analyst, business-facing
Sits between the business question and the data that might answer it, and is responsible for whether the number on the report means what the person reading it thinks it means. Distinct from the engineering-heavy roles in our data and analytics discipline, and hired for business judgement as much as technical depth.
Common tools: SQL, Power BI or Tableau, data dictionary and definition management, reporting requirement specification, and Excel at a level most people overestimate in themselves.
ERP & platform functional analyst
Specialises in a specific platform, most commonly SAP, Oracle, Dynamics or a core insurance or banking system, and works out how a business process should be configured inside it. Scarce, expensive, and worth the money during implementation or upgrade, because platform-specific judgement is not transferable from general analysis experience.
Common tools:platform configuration and functional design, fit-gap analysis, test scenario design, data migration mapping, and vendor and systems integrator management.
Integration business analyst
Specifies what moves between systems and what it means on both sides, including the parts everyone assumes are obvious: field-level meaning, timing, failure behaviour and who owns the truth when two systems disagree. Unglamorous, chronically undersupplied, and the source of a large share of late-stage delivery surprises when the role is skipped.
Common tools: API and interface specification, data and field mapping, message and payload design, sequence and flow diagrams, and Postman or similar.
Lead business analyst, BA practice lead
Sets how analysis is done across a programme or a business: standards, quality, how work is sized and assigned, and who is capable of what. Also the person who protects analysts from being reduced to note takers when delivery pressure rises, which is a bigger part of the job than most role profiles admit.
Common tools: analysis standards and templates, estimation and resourcing, quality review, stakeholder governance, and capability development.
Product owner
Owns what gets built and in what order, with accountability for the value rather than only the specification. Related to analysis but not the same job, and businesses that treat the two as interchangeable tend to end up with an analyst holding a backlog and no mandate to prioritise it.
Common tools: backlog ownership and prioritisation, outcome and value definition, roadmap management, product analytics, and stakeholder negotiation.
Systems analysts, technical business analyst
Works closest to the build, translating business requirements into something engineers can implement against, including data structures, logic, edge cases and system behaviour. Usually the analyst who reads the existing system rather than asking someone what it does, which is why the role carries a premium in legacy heavy environments.
Common tools: SQL, data modelling and ERDs, API and interface documentation, system and logic specification, and enough reading knowledge of the codebase to check a claim.
Other disciplines we recruit in
AI & Machine Learning · Software engineering · DevOps and cloud engineering · Fintech · Project and programme management and more
IF YOU'RE HIRING
Hiring for job whose value is invisible when it goes well.
The strongest evidence of a good analyst is a set of things that did not happen, which puts the assessment burden squarely on the interview. Start by resisting the artefact, we know it’s tempting to ask for a requirements document, a process map or a set of user stories, and yes those will tell you whether somebody is organised and literate.
However it will not tell you whether the content was right, because the document looks identical whether the underlying thinking was rigorous or whether the analyst wrote down what the loudest stakeholder said. A polished artefact is evidence of craft, not of judgement, and this discipline has a great deal of craft attached to weak judgement.
Where we’ve seen great success is when the interview is built around disagreement. Some thought starters:
- Ask for a time they told a senior stakeholder that the ask was not achievable and what happened next.
- Understand what (if ever) they’ve removed from a scope and how they made that case.
- Have they ever been in a situation when the requirement turned out to be wrong after it was built. What the cost impact was and what in their process would now catch it.
- How did they understand a system when the documentation was data and the person who built it has left.
The key is to listen for whether the answers contain other people, pressure and a decision, or only method. Then look for two specific capabilities that separate the top of this market.
Scepticism: the habit of checking a stated requirement against the data, the system or the actual process rather than accepting the account of it. An analyst who can write a query and look for themselves is worth materially more than one who cannot, and in South Africa that is still a minority skill inside the discipline.
The ability to hold a room: analysis produces conclusions that are frequently unwelcome, and an analyst who cannot deliver an unwelcome conclusion to an executive audience is, in practice, an analyst whose conclusions do not reach the decision.
One practical warning on job briefs and specs, while a large proportion of business analysis vacancies in this market are written as a list of methods and tools, which attracts the population trained in methods and tools and screens out nobody.
If the role exists because a programme keeps building the wrong thing, say so. The analysts you want are the ones who read that and recognise a problem they have already solved.
WHY LEVELS MATTER
Understanding seniority.
Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A junior BA works inside a structure somebody else set up: documenting a defined process, writing up requirements from sessions they did not run, preparing test scenarios, chasing detail to closure. In this discipline the thing to hire for at this level is curiosity about the business rather than fluency in the method. The good ones ask what a field means, what happens to the customer, and why the process exists at all, and they are noticeably uncomfortable writing down something they do not understand.
-
A mid-level BA owns an area of analysis end to end: running the sessions, resolving the contradictions between what different stakeholders want, producing a specification a team can build against, and staying with it through delivery and testing. Usually the level at which someone starts noticing that the request and the underlying need are different things, and starts raising it.
-
A senior BA is trusted with the ambiguous work: the area where nobody can describe the current state, the process that spans four departments who each believe they own it, the regulatory change where the obligation has to be turned into system behaviour. Seniors here are measured by the problems they surfaced early and by whether business and technical audiences both leave the room with the same understanding.
-
A lead or principal BA carries the judgement calls where the analysis meets the commercial decision: what the change is really going to cost, what is not worth doing, where the business is about to automate a process it should be retiring. At this level the work is as much about persuading an executive audience as producing analysis, and the value sits in decisions avoided rather than documents delivered.
Where the money is, and where it isn't
What pushes pay up here is not the title, it is what somebody has already been through. A lot of analysis work is fairly interchangeable, and the market prices it that way. The work that is not interchangeable is where someone has faced that exact problem before and knows how it tends to go wrong.
Three kinds of experience move it most
- Regulated change, where somebody has taken a legal obligation and turned it into something a system actually does, then defended that translation to risk or audit.
- Core platform replacement, where the hard part is not designing the new system, it is working out what the old one really does.
- And integration work, where somebody can pin down what passes between two systems precisely enough that neither team can later say they assumed something different.
Under all of that, the fundamentals still carry, like SQL, or enough of it to go and look at the data instead of trusting somebody’s description of it. Enough data modelling to spot when two departments are using the same word for two different things. And enough understanding of how your systems are actually built to specify something a team can realistically deliver, rather than something that costs them a fortnight of rework.
The rarest combination is the analyst who can sit with an executive in the morning and an engineering team in the afternoon and be believed in both rooms. No dumbing it down in one, no hiding behind detail in the other. That person is hard to find, hard to replace, and usually knows it.
What the package is really worth
Business analysis pay in South Africa is all over the place, and the reason is the title rather than the market. Because one title covers very different jobs, most published ranges squash a wide span into a single number and mislead both sides of the table.
What that means in practice is that the level sets the figure, not the title. A senior business analyst doing specification work and a senior business analyst who owns regulated change analysis for a bank can be a long way apart, and both are correctly titled. Benchmark on title alone in this discipline and you will be wrong about half the time.
The big institutions put real weight into the structured parts: retirement and medical contributions worth having, formal bonus schemes, study support, and a level of stability that matters more to some people than they will admit in an interview. Smaller businesses and consultancies compete on exposure and pace. In the consultancies especially, the number of different businesses somebody sees in three years is a real part of the package here, because context is the asset.
Two other things shape the decision. One is access to the domain. An analyst who gets into the regulated, core or integration work is buying their own future earning power, and the businesses that understand this use it deliberately. The other is how close they sit to the decision. Whether somebody is in the room when scope gets agreed, or hears about it afterwards, changes the job, and within a few years it changes what they are worth.
THE COST
Contract vs Permanent.
The contract market for business analysts here is one of the most established in technology, particularly in banking and insurance, where programme work has been resourced this way for years. The infrastructure exists, people are used to it, and nobody needs convincing that it is normal.
The work that suits contract is easy to spot. A platform implementation, a regulatory change programme, a migration, a specific integration, a defined process redesign. Real scope, a real end date, and a depth of platform or domain experience no business can justify carrying permanently. Paying a day rate for somebody who has done that implementation three times usually costs less than a permanent hire learning it once on your programme.
Where we would draw the line is institutional memory rather than cost. Business analysts hold something no other discipline holds in the same way, which is the reasoning behind decisions. Why a rule was set that way, which department objected, what got left out and what would break if somebody put it back. Documentation captures the decision. It almost never captures the reason. Businesses get caught out by contracting the people who hold the reasons, then finding a year later that everyone who knew why the calculation works like that has moved on to another programme.
So it is usually a mix rather than a rule. Contract the programme, keep the domain permanent, and make sure somebody permanent is close enough to the work to pick up the reasoning while it still exists. That handover is worth planning, because it does not happen on its own.
For the analyst, contract here is a strong route and it builds context faster than almost any permanent path. What you give up is depth in one business, the slow-built trust that gets you into the rooms where scope is decided, and the chance to see whether what you specified actually worked a year later. That is a real give and take, and worth making on purpose rather than by default.
Business Analyst salaries
in South Africa.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Junior BA
R600 – R650
> Mid-level BA
R750 – R900
> Senior BA
R950 – R1100
> Lead or Principal BA
R1200 – R1300
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Junior BA
R650K – R700K
> Mid-level BA
R750K – R950K
> Senior BA
R1M – R1.3M
> Lead or Principal BA
R1.5M – R1.7M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: September 2026
IF YOU'RE BUILDING A CAREER
Nobody builds a career on accurate notes.
What compounds in this discipline is not method, it is domain. Two analysts can spend four years at the same insurer and come out worth very different money, because one of them worked on the product rules and the other wrote up whatever came through the intake process. Nobody tells you this while it is happening. You find out in an interview where the questions go one layer past anything you were ever allowed to see.
So the useful question about a role is not what the business does, it is what you would be responsible for deciding. Ask whether you would run the sessions or sit in them. Ask who signs off scope, and whether you are in that conversation. Ask what happens when your analysis says the requested thing is the wrong thing, because the answer tells you exactly what kind of job this is.
Two things are worth building on purpose, and both are unfashionable. Learn enough SQL and data modelling to check things yourself, because the analysts who can go and look end up trusted with the work that pays. And get comfortable with the regulated and technical material most people route around. It is not hard to learn. It is just dull, which is exactly why so few people bother, and why the ones who do end up with the most leverage.
And here’s how we work with you. We take the time to understand where you’re trying to get to, not just what’s already on your CV, and we only put you forward for roles that move you that way. You stay in control the whole way through, and we’d rather point you at the right role than hurry you into the nearest one.
COMMON QUESTIONS
Business Analysis questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
How do I tell a strong business analyst from a well-presented one?
Stop reading the artefacts and start asking about the decisions. A requirements document looks the same whether the thinking behind it was rigorous or whether the analyst wrote down what the loudest person in the room said. The questions that separate them are about conflict. A time they told a stakeholder the request would not get the business what it wanted. Something they took out of scope and how they argued it. A requirement that turned out wrong after it was built. Strong analysts answer with people, pressure and an outcome. Well-presented ones answer with method.
Do I need a business analyst or a product owner?
It depends on whether the gap is understanding or deciding. If your teams keep building things that turn out to be wrong because nobody worked out what the business actually needed, that is analysis. If they are building the right things in the wrong order because nobody owns priority, that is product ownership. The trouble starts when a business hires one title and expects both jobs, usually an analyst handed a backlog and no mandate to prioritise it. Work out which decision the role owns before you write the brief and the title tends to sort itself out.
How do we hire a business analyst who challenges rather than documents?
Two things have to change and only one of them is the hire. Write the brief around the problem rather than the method, because a list of tools and certifications attracts exactly the population you already have. Then look for people who check things for themselves against the data, the system or the real process rather than taking somebody’s word for it.
The second change is structural. An analyst who challenges scope needs access to the room where scope gets agreed. Hire that capability into a role with no standing and you will be back to documentation inside six months.
We're replacing a core system, should the Business Analyst be a contractor or a permanent hire?
Both, on purpose. The hardest analysis in a replacement is working out what the current system actually does, and somebody who has done that two or three times before will move far faster than a permanent hire learning it once on your programme. That work has a real end date, so it suits contract. What should not be contracted is the knowledge that outlives the project: the reasoning behind the rules, what was left out and why. Keep somebody permanent close enough to absorb that while it still exists, because documentation records decisions and almost never records the reasons.
Does domain experience matter more than analysis experience?
In financial services, regulated change and specialist platforms, usually yes. Knowing what a premium, an affordability rule or a reconciliation has to do removes months of asking, and it is not something you pick up quickly. Elsewhere it tips the other way, and strong analysts move between sectors all the time. The practical test is how far your business sits from what the analyst already knows. If nobody on the team can explain the domain clearly, the hire needs to bring it. If two or three people can, hire for judgement and let the domain follow.
How much technical depth should we expect from a business analyst?
Enough to check things without asking. SQL at a level that lets them go and look at the data rather than repeat a description of it. Enough data modelling to notice when two departments use one word for two different things. And enough understanding of how your systems are built to specify something that can realistically be delivered. It does not mean writing production code. In South Africa that level of technical literacy is still a minority skill, which is exactly why the analysts who have it are priced above the rest of the market.
FOR PROFESSIONALS EXPLORING
I've got more then 5+ years experience? Why am I not getting senior roles?
Usually because the roles you have held gave you accuracy rather than authority. Five plus years of capturing requirements well, inside a process somebody else designed, builds a good CV and very little of what senior interviews are actually probing for, which is what you did when the requested thing was the wrong thing. If that is where you are, the way out is exposure rather than another certification. Get into the ambiguous work nobody can describe, run the sessions instead of sitting in them, and build enough technical literacy to check things yourself.
Is a certification worth it in this market?
It is worth having, yes. Formal grounding is a common expectation here and a certification is a reasonable signal early on, particularly if you are coming into the discipline from somewhere else. What it tells a hiring business is that you have been taught a method, not that you have used it to change an outcome. Past the first few years, domain depth, a platform specialism and evidence of decisions you influenced will move your market value much further than another qualification.
How do I move from general analysis into financial services or a specialist platform?
Usually through a programme rather than a job title. You typically get into specialist domains sideways: a regulatory change project, an implementation where you pick up the platform, an integration piece that puts you next to the core.
Contract work is a genuinely good route here, because programme work is where the specialist context sits and the market does not read contract movement in this discipline as instability. Tell us where you are trying to get to and we will be straight with you about which roles move you that way and which only look like they do.