Onboarding as a Business Analyst: Stakeholders, Processes, and the First Decision You Unblock

A business analyst is onboarded when three things are true: you can name who owns each open decision in your scope, you can describe the as-is process without opening a document, and you have moved one real decision from stuck to made. Map stakeholders by their influence over decisions, shadow the people who handle exceptions, learn the business vocabulary before the system vocabulary, and make your first deliverable a decision rather than a document.

The first time I joined a cross-border payments change programme as a business analyst, I spent my first week reading a forty-page target operating model. It was well written. It described a clean flow where corporate clients send structured payment files, the bank validates them, and payments leave for correspondents as perfectly formed ISO 20022 messages. On the Thursday, a team lead in payment operations walked me over to her desk and showed me the repair queue: several hundred payments a day that had stopped because a client had sent a postal address in four free-text lines and the outbound message needed a town and a country in their own fields. Her team was fixing them by hand, one at a time, reading addresses and retyping them.

None of that was in the forty pages. All of it was in my scope.

This is part six of The First 90 Days, the series on succeeding in a new team or a new company as a technical analyst. Parts one to five cover what every analyst does: the 90-day plan, reading the documentation, using AI to onboard, asking the right questions, and giving feedback. Parts six to ten apply those five levers to one role each. This one is for the business analyst, and the running example is that programme: a bank’s cross-border payments change, months before the November 2026 CBPR+ deadline when fully free-text addresses are no longer accepted.

What does “onboarded” mean for a business analyst?

Every role in this series has its own finish line. For a developer analyst it is reproducing a defect locally; for a QA analyst it is knowing what the suite actually covers. For a business analyst it is three statements you can make honestly:

1. I know who decides. For every open decision in my scope, I can name the person who owns it, and they agree that they own it.
2. I know how the work really flows. I can describe the as-is process from trigger to outcome, including the exceptions and the manual workarounds, without opening a slide.
3. I have moved something. At least one decision that was stuck when I arrived has been made, with a date and an owner, because I framed it.

Notice what is missing: documents. A new business analyst is often judged, unfairly, by how fast they produce artifacts. A process map in week two looks like progress. It is usually a copy of the target operating model with new boxes. The artifacts come, but they are evidence of the three statements, not a substitute for them.

Who are the stakeholders, and how do you map them in week one?

The org chart tells you who reports to whom. It does not tell you who decides whether operations will accept a manual fix for six more months, which is the question that actually shapes your requirements.

Build the map from decisions, not from people. On the address programme, my first list looked like this:

Open decision or requirement area	Who decides	Who must be consulted	Who is affected
Accept hybrid addresses from clients, or require fully structured	Head of payments product	Compliance (sanctions screening), operations	Corporate clients, client onboarding
Who repairs addresses that fail validation, and by when	Operations team lead	Head of payments product	Operations, clients waiting for payment
Client communication on the file format change	Corporate client relationship lead	Product, legal	Every corporate client sending pain.001 files
Whether screening rules change when addresses become structured	Financial crime compliance lead	Screening system owner	Operations (false positive volume)
Release date for outbound validation	Programme manager	Architecture, testing	Everyone

Then plot the deciders on a power and interest grid, where power means influence over decisions in your scope rather than seniority. The steering committee was high power but low interest: they wanted the deadline met and did not care how. The operations team lead was the opposite of what her title suggested. She had no budget authority, but nothing went live without her saying the repair process was workable. She went in the top right corner, and I met her twice a week.

Validate the map in your first one-to-ones. End every meeting with the same question: who else should I be talking to about this? The names that come up three times and are not on your map are the ones you missed. On that programme, three people independently mentioned the client onboarding manager, who owned the static data that held client addresses in the first place. She was not on any steering group. She turned out to own half the problem.

Asking the right questions covers the one-to-one script in detail. For the business analyst, the important addition is to ask every stakeholder the same two questions so you can compare answers: what does success look like for you on this programme, and what are you most worried we will get wrong. When the head of product says “meet the deadline” and the operations lead says “do not triple my repair queue,” you have found the tension your requirements must resolve.

How do you learn the as-is process when the documentation describes the to-be?

Documentation on a change programme describes where the programme is going. Your job in the first month is to learn where the business actually is, and the fastest route is the exceptions.

Shadow the repair queue. Ask to sit with the people who handle failed or stopped items for half a day. Watch, do not interview. On the address programme, two hours at the operations desk taught me:

• Which clients were responsible for most of the failures (a handful of large corporates sending addresses in a format their own enterprise resource planning system produced).
• That operators were already making a policy decision on every item: when an address said “LONDON EC2” in line three, they were inferring that the town was London and the country was the United Kingdom. Nobody had written that rule down. It was being applied hundreds of times a day.
• That a spreadsheet of “known good addresses” existed on a shared drive, maintained by one person, and was the real master data.

Walk one real transaction end to end. Pick one payment that went through the repair queue and follow it: the pain.001 the client sent, the validation that stopped it, the repair, the outbound pacs.008 that left for the correspondent, the status that came back. If pain versus pacs is unfamiliar, that walk is the moment to learn it, because the business problem lives at exactly the point where a customer-to-bank message becomes a bank-to-bank message.

Draw it as you learn it. A sequence diagram with five lanes (client, channel, payment hub, operations, correspondent) beats a swimlane slide because it forces you to say who sends what to whom and in what order. Sequence diagrams for business analysts shows the notation. Draw it badly on day eight, then show it to the operations lead and ask “where is this wrong?” People who would never review a requirements document will happily correct a drawing of their own work.

Why learn the business vocabulary before the system vocabulary?

Because the decisions are made in business words.

In my second week I kept a two-column glossary: what operations and product people said, and what the system or the standard called it.

Business term	What it means here	System or ISO 20022 term
Client file	The batch of payments a corporate sends us	pain.001 (customer credit transfer initiation)
Repair queue	Payments stopped for manual correction	Exception status in the payment hub, queue REPAIR_ADDR
Structured address	Town, country, postcode in their own fields	PstlAdr with TwnNm, Ctry, PstCd elements
Hybrid address	Town and country structured, the rest in lines	PstlAdr with TwnNm and Ctry plus up to two AdrLine
The deadline	The date unstructured addresses stop being accepted	CBPR+ November 2026
Release	The money leaving the bank	pacs.008 sent to the correspondent

The left column is what you need in steering meetings, decision papers, and conversations with operations. The right column is what you need with developers and testers. A business analyst who only speaks the right column sounds technical and gets ignored by the business; one who only speaks the left writes requirements nobody can build. The glossary is the bridge, and building it yourself is how you learn both sides.

It also catches disagreements early. When I asked three people what “structured address” meant, product said “town and country in fields,” operations said “every line in a field,” and the client relationship lead said “whatever the new file template has.” Three definitions of the core term, two months from a client communication. Structured addresses in ISO 20022 gives you the standard’s definition; the glossary tells you which one your organization is actually using.

How should a business analyst use AI during onboarding?

Use it to compress reading and to rehearse, never to supply facts about your organization. Inside your organization’s approved tool only, and with no client names, addresses, or account details in any prompt.

Three uses paid off on the address programme:

Turning the document pile into a reading plan. Paste the titles and first paragraphs of the twenty documents you were sent (not their contents, if they are confidential and your tool is not approved for them) and ask which five to read first for a business analyst whose scope is client-facing change. The model is good at triage.

Building the first draft of the glossary. Paste your meeting notes from a week of one-to-ones and ask:

From these notes, extract every business term, acronym, or phrase that
was used as if I should already know it.

For each one, give:
- the term exactly as used
- who used it (role, not name)
- what it appears to mean from context
- CONFLICT if two people appear to use it differently, quoting both

Do not define terms from general knowledge. If the notes do not make
the meaning clear, write UNCLEAR FROM NOTES.

The CONFLICT flag is the valuable part. It found the three definitions of “structured address” before I did.

Rehearsing the stakeholder conversation. Before my first meeting with the compliance lead, I asked the model to play a financial crime compliance lead worried about sanctions screening and to raise the five objections they would most likely have to a hybrid address policy. Three of the five came up in the real meeting. I had answers ready for all three.

Part three covers the full AI onboarding pack. If your employer has not approved an assistant yet, The AI-Powered Analyst is about working inside that constraint without putting anything at risk.

What questions should a new business analyst ask?

The general method is in part four. The business analyst’s version leans toward decisions, ownership, and history:

• “What has already been decided, and where is it written down?” Programmes accumulate decisions in meeting minutes nobody reads. Finding them saves you from reopening settled arguments, which is the fastest way to lose credibility in month one.
• “What is still open, and who is waiting on it?” This is how you find the stuck decision you will unblock.
• “What did the last programme like this get wrong?” Every bank has done a format migration before. People remember what hurt.
• “Who will be unhappy if this goes live as currently designed?” The answer is rarely in a risk log.
• “If we did nothing, what would happen on the deadline date?” On the address programme the honest answer was: payments with free-text addresses would be rejected by correspondents, and the repair queue would become a rejection queue with clients on the phone. That sentence went into my decision paper verbatim.

Ask the factual ones of documents and logs first, and save people for judgment and history. “Which clients send unstructured addresses?” is a query, not a question for the operations lead.

How do you give feedback as a new business analyst without making enemies?

You see things in your first month that the team stopped seeing years ago. That fresh view expires, so use it, but carefully. Part five covers the method. The business analyst angle is that your feedback is usually about process and ownership, which means it touches people’s work directly.

On the address programme, the uncomfortable observation was the unwritten rule: operators were inferring town and country from free text hundreds of times a day, and nobody had approved that inference. If an operator got it wrong, a payment would go out with a wrong country, which matters for sanctions screening.

I did not raise it in a steering meeting. I raised it with the operations lead first, privately, framed as a question about my own understanding: “I noticed the team infers the country when line three has a city name. Is that a documented rule, or something the team developed? I want to make sure I capture it properly in the requirements.” She told me it was undocumented and she had been worried about it for a year. We raised it together the following week, as her concern, with my requirement attached. That is the pattern: observation, framed as a question, taken first to the person whose work it describes, raised publicly with them rather than about them.

Why should your first deliverable be a decision rather than a document?

Because a decision is the thing a business analyst exists to produce, and it proves all three onboarding statements at once.

The open question on my programme was whether to accept hybrid addresses from clients or require fully structured ones. It had been open for eleven weeks. Product wanted fully structured because it was cleaner. Operations wanted hybrid because many clients could not change their systems in time. Compliance had not been asked. The client communication could not be written until it was decided, and the communication had a lead time of three months.

The one-page decision paper had five sections:

DECISION NEEDED
Accept hybrid postal addresses (town and country structured, up to
two free address lines) in client pain.001 files from the November
2026 cut-over, or require fully structured addresses.

OWNER AND DATE
Head of payments product. Needed by 14 November so the client
notice can go out with three months' lead time.

OPTION A: REQUIRE FULLY STRUCTURED
- Cleanest data for screening and for correspondents.
- An estimated share of corporate clients cannot change their
  ERP output in time (named in appendix, from the repair queue).
- Their files are rejected at cut-over; operations cannot repair
  at that volume.

OPTION B: ACCEPT HYBRID, MANDATE STRUCTURED BY A LATER DATE
- Meets the CBPR+ requirement (hybrid is permitted).
- Clients get a migration window; repair volume stays manageable.
- Compliance must confirm screening works on hybrid addresses.

CONSEQUENCE OF NO DECISION BY 14 NOVEMBER
The client notice slips, clients get less than three months, and
the repair queue becomes a rejection queue on cut-over day.

The decision was made in the next product meeting: Option B, with compliance sign-off as a condition. It took me two weeks, most of them spent getting the facts in the appendix from the repair queue data, and it did more for my standing on the programme than any artifact I produced that quarter.

The decision paper then became the root of the requirements. From business requirement to functional spec shows how a decision like that becomes rules a developer can build: accepted address shapes, validation per field, what happens to a file that fails. If you want the full method for that step, From Vague BR to Functional Requirements walks it with banking examples.

If no stuck decision exists in your scope, the fallback first deliverable is a one-page as-is process with the glossary attached, reviewed and corrected by the people who run the process. It is less impressive, but it is still evidence rather than a copy of the target state.

What does a 90-day plan look like for a business analyst?

Weeks	Focus	Output you can show
1 to 2	Meet every decider in scope; shadow the exception desk; start the glossary	Draft stakeholder map, glossary with 20+ terms, list of open decisions
3 to 4	Walk one real transaction end to end; draw the as-is sequence; validate it with operations	As-is diagram corrected by the people who run it
5 to 6	Pick the stuck decision; gather the facts from data, not opinion	Decision paper draft, reviewed by the owner before it goes anywhere
7 to 8	Get the decision made; turn it into the first requirements	Decision recorded with owner and date; first requirements traced to it
9 to 10	Take over a requirement area fully; run your first workshop	Workshop with decisions and owned actions published the same day
11 to 13	Write the onboarding notes you wish you had; 90-day review	Glossary and stakeholder map handed to the next joiner; review with your manager

Part eleven covers the review itself and what to leave behind.

The takeaway

Business analyst onboarding is not about producing documents quickly. It is about learning who decides, how the work really flows, and which question has been stuck the longest, then using all three to move one real decision. Shadow the exceptions before you read the target state. Keep a glossary that maps business words to system words, and use it to find the places where three people mean three different things. Raise what your fresh eyes see privately, with the person whose work it describes. And make your first deliverable a decision with an owner and a date.

The banking context for all of this, how payments, correspondents, and regulated change actually work, is in Break Into Banking. If you want the role itself laid out, including the skills that matter in the first year, What Is a Business Analyst? covers it. For keeping your glossary, stakeholder map, and decision log somewhere the team will actually read, see Confluence for Business Analysts, and for prompts that turn workshop notes and transcripts into those artifacts, The Tech BA Prompt Toolkit. The free downloads are a good place to start if you want templates before committing to a guide.

To practise onboarding onto a system you have never seen, the Labs drop you into Northline Pay, a fictional payments platform with real-shaped artifacts. The rest of the series is mapped on The First 90 Days.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Onboarding, Stakeholder Management, ISO 20022, Payments