Why does a missing business analyst cost more than having one?
In one sentence: because rework is always more expensive than getting it right the first time.
But that is too simple. Let me show you with numbers - and real project examples - exactly what this means.
A typical situation
The project starts. There is a deadline, a development team and plenty of enthusiasm. The business need is "more or less" clear - the details will be sorted out along the way. Bringing in a business analyst is discussed, but it seems expensive and "there's no time to recruit right now".
Three months later, development is 60% done. That is when the business gives its first serious feedback: "this isn't quite what we meant by the requirement." Some features have to be redesigned. The deadline slips. The budget shrinks. Morale drops.
This isn't the exception. It is the rule.
For years, the Standish Group CHAOS Report has consistently shown that the vast majority of IT projects fail to meet their original goals on time, on budget or in functionality. The most common cause is the same in every edition: incomplete or misunderstood business requirements.
The numbers - what does a missing BA cost?
Let's be specific. According to the Bluebird 2025 IT Salary Guide - the most credible salary survey on the Hungarian market, based on real transaction data - a senior business analyst in Hungary earns between HUF 1,500,000 and 1,700,000 gross per month. Engaged as a contractor or on a time-and-materials basis, the cost is typically of a similar order, but on more flexible terms.
On a six-month project, the total cost of a senior BA is therefore roughly HUF 9-11 million.
Now the other side. What does a missing BA mean on the same six-month project?
Estimated cost (6 months, senior team of 4):
- Scope creep - continuous, unplanned growth of requirements, on average 20-30% extra development capacity: HUF 8-16 million
- Rework - finished features rewritten because of a misunderstood specification, 15-40% based on industry experience: HUF 6-22 million
- Project delays - the final cost climbs to 130-200% of the original budget if scope isn't managed in a structured way: knock-on effects
- Bringing in a senior BA - senior-level market benchmark of HUF 1,500,000-1,700,000 per month: HUF 9-11 million
Source: Bluebird IT Salary Guide 2025 - senior Java developer salary HUF 1,700,000-2,300,000 per month; senior BA salary HUF 1,500,000-1,700,000 per month.
A missing BA can cost HUF 14-38 million on a mid-sized project. A BA on the team: HUF 9-11 million. The maths is clear - yet BAs are often still left out.
So why aren't they brought in?
I regularly see three reasons.
First: the cost of a BA is visible; the cost of not having one is invisible. When the decision is made during project planning that no BA is needed, nobody calculates what that will cost. Scope creep appears gradually, almost unnoticed. Development cycles get booked as "slow developers" or "changing business needs" - not as a missing BA.
Second: the BA is seen as a document producer. If the BA's role in an organisation is simply to write the specification and hand it to the developers, its value really is questionable. But that isn't the BA's role - that is a BA doing the job badly. A real BA owns the business requirement throughout the project lifecycle, rather than delivering a one-off document.
Third: "the developers will just ask the business". On most projects this doesn't work, because developers don't know what to ask. They know how to implement - but they don't necessarily know which questions are missing from the specification. Bringing those questions to the surface in advance is exactly the business analyst's job.
Three concrete cases from my own experience
An insurance Salesforce project - when internal BA capacity was missing
During a Salesforce CRM rollout at a large insurer, the internal BA team was tied up with other projects. The decision: start the project without a BA - "the business will tell us what's needed". Four months later, mid-development, it emerged that there were discrepancies between the data model of the insurance processes and Salesforce's standard objects, which developers and the business had both handled on the basis of assumptions - different assumptions.
The project slipped by three months and the development budget grew by 40%. Then FrontX's BA was brought in - productive within two weeks thanks to their knowledge of insurance processes - and the rest of the project closed without a single scope change.
Workflow automation at a leasing company - when the specification was "done"
At an operating lease company, the specification for a workflow automation project was completed and approved by everyone. Development began. The first test cycle revealed that the specification didn't cover the handling of exceptional contract types - which accounted for 30% of the volume.
Redesign and rework took two months and 35% of the budget. The price of missing requirements discovery: three times the cost of bringing in a BA for three months.
A back-office registry system - when there is nobody to rely on
At an innovative start-up, there was no internal business knowledge on the software development side. The developers tried to interpret the client's needs directly - without domain knowledge. The result: two full development sprints' worth of work was wasted because the internal calculation logic had been misinterpreted. The fix cost more in time and money than bringing in a business analyst at the start of the project would have.
When ISN'T a business analyst needed?
To be fair: not every project needs a dedicated BA. There are cases where bringing one in really isn't necessary or would be disproportionately expensive.
If development is short (one or two sprints) and well defined, the development team knows the domain, and the business need is clear and stable, the project can start without a BA. For small internal developments where the "client" and the "user" are the same person, a separate business analyst role isn't needed either.
The real question is: is there someone who owns the business requirement? If so - whether the role is filled by an internal developer, a product owner or a project manager - the project starts on a safer footing. If not, this is the point where bringing in a BA isn't a luxury but risk management.
The decision framework
Four questions - if the answer to any is yes, you should definitely bring in a business analyst:
- Are several business areas involved? If so, aligning requirements and managing stakeholders falls apart without coordination.
- Are there compliance or regulatory requirements? On financial services projects - at insurers, banks and leasing companies - the specification will be incomplete without knowledge of the regulatory context.
- Does the system integrate with existing legacy systems? Without a BA, integration points are usually only mapped and specified during development - at the worst possible moment.
- Will the project run longer than three months? If so, the requirements are certain to change along the way. The question is whether someone manages that change - or it just happens.
What this means at FrontX in practice
FrontX business analysts don't hand over the document and move on. They are there for the questions that come up during implementation, at the first demos, and when testers find the first inconsistency in the specification.
On financial services projects we only bring in BAs with industry experience - insurance, banking and leasing processes don't need to be taught. That means short onboarding, fast productivity and more precise requirements discovery, because the BA understands the context from the very first meeting. See our business analysis services.
If you have an IT project where the BA role is unfilled, it is worth asking: who owns the business requirement? If the answer is "nobody" or "everybody", that usually means the same thing.
If you would like to assess whether your project needs BA support, we are happy to talk: frontx.hu/en/company/contact
If you are a BA and want to work somewhere your role really matters, see our careers page: frontx.hu/en/careers
Frequently asked questions
Why does a missing BA cost more than having one on an IT project?
The cost of a senior BA is a fraction of what the resulting scope creep, rework cycles and project delays cost. According to the Bluebird 2025 IT Salary Guide, a senior BA earns HUF 1,500,000-1,700,000 per month - whereas the losses from a missing BA can reach HUF 14-38 million on a mid-sized project.
When is a business analyst needed on an IT project?
Definitely when several business areas are involved, when there are compliance or regulatory requirements, when the system integrates with legacy systems, or when the project runs longer than three months. On financial services projects - at insurers, banks and leasing companies - these conditions are almost always met.
What is scope creep and how can it be prevented?
Scope creep is the continuous, unplanned expansion of an IT project's scope during development. Its most common cause is that nobody owns the business requirement. It can be prevented by bringing in a dedicated business analyst who owns the requirement throughout the project lifecycle and handles new requests through structured change management.
How much does a business analyst cost in Hungary?
According to the Bluebird 2025 IT Salary Guide, a junior BA earns HUF 750,000-1,000,000, a mid-level BA HUF 1,000,000-1,500,000 and a senior BA HUF 1,500,000-1,700,000 gross per month. Engaged on a time-and-materials basis or as a contractor, market rates are similar. This figure can be compared directly with the cost of rework, scope creep and delays caused by a missing BA - which is typically several times higher.
What is the difference between a business analyst and a product owner on IT projects?
The business analyst owns the discovery and documentation of business requirements - answering "how exactly should it work?". The product owner owns development priorities - deciding "what do we build now?". In a healthy agile project the two roles complement each other. When one person tries to do both, one of them usually suffers - and in our experience it is most often the in-depth discovery of business requirements that gets dropped.
About the author
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services.
LinkedIn: linkedin.com/in/laszlobehan | FrontX insights: frontx.hu/en/insights
