There are things you only learn in a large company. Projects with dozens of stakeholders, stakes worth several million euros, processes that have been documented for years.
And there are things you don't forget either: steering meetings that run for two hours to say what an email could have settled in five minutes, decisions that get bogged down in cascading approvals, ambitious projects that end up drowning in their own processes.
Being a Business Analyst in a large company means living both of these realities at the same time. And understanding how they coexist lets you get the best out of this environment without needlessly suffering its constraints.
What a large company really offers
A structured framework, as long as you can find your way around it
In a large organization, the BA role is often well defined. There are established methodologies, document templates, approval processes and reference frameworks.
If you're just starting out, that's a real asset. You don't have to reinvent everything. You can learn how to structure an analysis, document a need and work with teams that already have their own ways of working.
But this framework also has a hidden side.
Over time, some processes become ends in themselves. You fill in documents because they've always been filled in. You hold committees because the project management office requires it. You produce deliverables whose real usefulness isn't always obvious.
The structure that was meant to make the work easier ends up slowing it down.
The point isn't to get rid of every process. Some are essential to secure decisions, coordinate teams or meet regulatory constraints. The problem appears when nobody questions their usefulness anymore.
So an important skill for a BA in a large company is telling apart the processes that bring real value from those that mostly survive out of habit. And learning to navigate between the two without spending all your energy on it.
Projects of a complexity that's hard to find elsewhere
This is one of the big advantages of a large company.
Large-scale digital transformations, migrations of critical systems and multi-country rollouts expose the BA to particularly complex problems.
You learn to work with dozens of stakeholders who don't necessarily share the same priorities. You analyze processes that cut across several business functions and several systems. You have to produce analyses solid enough to be understood and defended in front of managers who have little time and a lot of demands.
This experience builds a real ability to structure complexity.
But there's a flip side.
Large projects can also get stuck in layers of steering, governance committees and approval chains. Sometimes it feels like there are more people tasked with overseeing the work than people available to move it forward.
I've seen how much this pile-up can slow projects down. A project that could have moved ahead in six months can stretch to eighteen when decisions pile up and every step has to clear several levels of approval.
It's not always a skills problem. The project's real complexity can explain part of the delay, but the organization itself can also become a drag.
For the BA, the frustration is twofold: watching serious analysis work lose its impact month after month, and having to wait a long time before seeing the concrete results of your efforts.
The specific challenges of being a BA in a large company
The partial view
In a large company, you may work on a small part of a much bigger project.
You analyze the billing module without always understanding how it fits with the rest of the system. You work with the HR team without necessarily knowing what the finance or operations teams are doing in parallel.
Everyone moves forward within their own scope, with their own goals, constraints and priorities.
The problem is that needs don't stop at the boundaries of the org chart. A decision made in one team can affect several others, sometimes without anyone having anticipated it.
This partial view can become frustrating, especially when you sense that your analysis would benefit from being placed in a wider context.
The answer is not to wait for all the information to come to you.
You have to ask questions beyond your own scope, try to understand the dependencies and identify the teams that might be affected by a decision. It takes time, but it's often what lets you catch inconsistencies before they turn into problems.
The BA can't always get a complete view of the system. But they can actively work to better understand the big picture.
Structural slowness
Bureaucracy in a large company isn't a given, but it's part of the reality you may run into.
Long decisions, multiple approvals, managers who are hard to get in a room, approval processes that involve people who are rarely available. For a BA used to moving fast, this way of working can be unsettling.
You may have identified a need, clarified expectations and prepared a coherent solution. And yet the project stays on hold because a decision has to be approved somewhere else, a trade-off hasn't been settled, or a committee only meets a few weeks later.
Eventually you realize that the quality of the analysis isn't always enough to move a project forward.
You also have to learn to anticipate decision lead times. Prepare trade-offs ahead of time, identify the real decision-makers, spot dependencies and keep moving in parallel on the topics that don't need approval yet.
That won't remove all the slowness. But it sometimes spares you from passively waiting for a decision to drop.
The hardest part is accepting that some constraints don't depend on you. You can do your job properly, prepare the right information and make discussions easier. That doesn't mean you control the whole system your project lives in.
Internal politics, the elephant in the room
BA training talks a lot about methods, skills and best practices. It talks less about the influence games you can run into in the field.
Yet they can have a huge impact on projects.
A tool can be favored because it matches a director's preferences, even though other solutions deserve a look. A proposal can be rejected because it challenges a team's scope. A decision presented as technical can also reflect power struggles or conflicting interests.
These are situations I've come across in my own experience in a large company.
Sometimes it feels like you're watching House of Cards, but set in an open-plan office.
Alliances form and dissolve from one project to the next. Some meetings feel more like negotiations than simple operational discussions. And it happens that seemingly technical decisions are really political victories in disguise.
It's absurd, sometimes funny in hindsight, and occasionally fascinating. At least when you're not directly in the line of fire.
Of course, not every decision is political and not every disagreement hides personal interests. But ignoring this dimension can keep you from understanding why a project is stuck when, on paper, everything looks coherent.
So navigating this environment takes more than good analytical skills. You have to understand the interests of the different stakeholders, know who to talk to and spot the blockers before they become visible to everyone.
This is also where the BA's position can become an advantage.
Because they talk with business teams, technical teams, management and users, they can move between several parts of the organization. That position doesn't give access to all the information, but it sometimes lets them pick up weak signals that each team, taken on its own, doesn't see.
Over time, regular conversations build a network of relationships that helps you better understand what's really going on.
You learn to listen to what's said, but also to notice the hesitations, the tensions and the questions that keep coming back. You can sometimes anticipate a blocker or realize that a decision is already largely settled before it's officially announced.
That's not spying. It's a better understanding of the organization and its human dynamics.
And in some projects, that understanding makes all the difference.
What a large company teaches you for what comes next
Even if you leave this environment one day, for a startup, to work for yourself or for another organization, the years spent in a large company can leave you with valuable assets.
You learn to structure a complex analysis and present it to demanding audiences. You know how to document rigorously, manage several stakeholders with conflicting expectations and deal with constraints that aren't always visible at first glance.
You also understand that projects aren't built on methods and specs alone. They depend on the people, decisions, dependencies and uncertainties around them.
But one of the most useful lessons is about understanding processes as a whole.
It's no longer just about analyzing a need or writing a spec. You have to understand how an activity works, how tasks follow one another, where the dependencies, bottlenecks and gray areas are.
In some large organizations, the complexity and the level of documentation provide an especially rich ground for developing this analytical ability.
These skills are transferable to other environments.
They can be especially valuable in a smaller structure, where processes are sometimes less formalized and where you need to find the right balance between putting things in order and avoiding needless heaviness.
Because knowing how to structure a process is one thing. Knowing how far to structure it is another.
And that may be one of the most important lessons to take away from the large company: a framework can make the work easier, but it can also end up suffocating it if nobody takes the time to question it.
What's next
In the next article, we're changing scenery: heading to the startup.
Fewer levels of hierarchy in some structures, sometimes faster decisions, but also less framework, constantly shifting priorities and responsibilities that can blur together.
The BA's day-to-day looks different there, though the fundamental questions of the job don't go away.
Do you work as a BA in a large company? Subscribe to the newsletter to regularly get analyses, practical tools and field stories on how the profession is evolving.