What Does a Business Analyst Actually Do? A Week on a Banking Project

A business analyst makes sure the right thing gets built. That means understanding a business problem properly, agreeing what the solution must do with everyone who has a stake in it, writing that down so developers can build from it, and confirming at the end that what was delivered actually works for the people who use it.

This week is a composite. It isn't one specific week, but every activity in it is the kind of work that fills a BA's calendar on a real automation project in a bank.

The week starts with a discovery workshop with the finance operations team whose reconciliation process is being automated. The goal isn't to design anything yet. It's to understand how the work happens today and where it hurts.

• Walk through the process step by step with the people who do it every day.
• Ask what happens when things go wrong. That's where the real requirements hide.
• Agree, in writing, what problem the project is solving and how success will be measured.

That last point is the first step of the 4C Framework: Clarity. If the room doesn't agree on the problem, nothing downstream will hold.

Tuesday is spent turning workshop notes into an as-is process map in BPMN. Every step, decision point, hand-off and system gets drawn, with the pain points marked: the step that takes two hours, the spreadsheet that gets re-keyed, the approval that sits in someone's inbox.

The map then goes back to the operations team to check. It's almost never right the first time, and that's the point: a wrong map found on Tuesday costs an hour; a wrong assumption found in testing costs weeks.

With the process agreed, the BA writes the requirements. For an automation project that means a bot specification for each process:

• Trigger: what starts the bot, and when.
• Inputs: which files, systems and fields it needs.
• Processing rules: each step the bot performs, in order.
• Exceptions: what the bot does when something doesn't match, and who it escalates to.
• Outputs: what it produces, in what format, and who receives it.

On a non-automation project, this would be a business requirements document and user stories instead. The BRD guide covers how to write one.

Thursday belongs to the delivery team. Developers walk through the specification and ask the questions that only come up when you try to build something: What if the file arrives late? What if two records match? Which system is the source of truth?

Every answer gets written back into the specification, not left in a chat thread. A developer I worked with at Access Bank described how my early user-flow wireframes meant they could "identify and resolve a critical navigation logic gap before any code was written". That's the job: catching problems while they're still cheap.

Friday is user acceptance testing. The BA plans the test cases from the requirements, runs the sessions with Finance, IT and Audit, logs defects, and agrees with stakeholders which ones must be fixed before go-live.

When the tests pass, the BA collects formal sign-off: named people, dated approvals, no verbal agreements. After go-live there's usually a hypercare period, when the BA monitors how the solution performs in real use. On the treasury automation project that period was 30 days, and the result was end-of-day reconciliation cut from eight hours to 45 minutes.

• It's not taking orders. A BA questions requests until the underlying need is clear.
• It's not writing documents for their own sake. Documents exist to create shared understanding and a record of decisions.
• It's not coding. You need to understand how systems work, but you don't build them.

1. Listening and questioning, to find the real problem behind the request.
2. Clear writing, so requirements can't be misread.
3. Process thinking, to see how work flows between people and systems.
4. Stakeholder management, to turn disagreement into documented decisions.
5. Enough technical understanding to talk to developers about data, integrations and testing.

If that sounds like work you'd enjoy, the guide to becoming a business analyst in Nigeria sets out how to get there.