The Ops Team Knows More Than the BRD: Why Discovery Starts at the Desk, Not the Document

The business requirements document tells you what someone decided to write down. The operations team tells you what actually happens.

We've started enough projects to know the pattern. The client sends a BRD — sometimes 40 pages, sometimes 200. It describes the system they want. Flows, rules, validations, user roles. It's thorough, well-structured, and approved by three layers of management.

And it's wrong. Not maliciously wrong. Not even negligently wrong. It's wrong the way a map drawn from memory is wrong — the major roads are there, but the shortcuts, the dead ends, and the one-way streets that everyone uses backwards are missing.

The BRD describes the process as it was designed. The ops team lives the process as it is.

What the BRD misses

The workarounds

Every operations team has workarounds. Processes that officially don't exist, but without which the system would grind to a halt.

We sat with an operations team once — three people processing hundreds of payments per day. The BRD described a clean flow: payment instruction comes in, gets validated, gets queued, gets sent to the bank. Simple.

What actually happened: the team lead checked the balances across six bank accounts every morning, decided which account to pay from based on cut-off times and available funds, manually moved money between accounts to avoid hitting transaction limits, and then processed the payments. None of this was in the BRD. None of it was in the existing system. It lived entirely in one person's head and one person's notebook.

If we'd built strictly from the BRD, the system would have processed payments from the wrong accounts, hit limits nobody documented, and failed at 3 PM every day when one bank's cut-off closed.

The exceptions that aren't exceptional

BRDs describe the happy path. When they describe exceptions, it's the big ones — payment failures, fraud flags, system outages. What they don't describe is the daily mundane exceptions that the operations team handles without thinking about it.

Transactions that need to be categorized differently because they're discretionary spend. Payments that get split across accounts because one bank has a daily limit. Amounts that need a different exchange rate because they're internal transfers, not commercial transactions. Merchants who get paid differently because of a verbal agreement nobody put in writing.

These aren't edge cases. They're the daily reality of operating a payment business. And they're invisible until you sit next to the person doing the work.

The informal communication channels

The BRD will describe a notification system: "when funds arrive, the operator is notified." In reality, someone upstream sends a message — sometimes an email, sometimes a text, sometimes a phone call — saying "I sent €5M to account X, it should land in an hour." The operator then watches for it, manually confirms it arrived, and proceeds.

The notification system in the BRD assumes the system knows when funds arrive. In practice, the system often doesn't — the operator knows because a human told them. Building a system that ignores this communication channel doesn't automate the process. It just removes a step that was actually critical.

How we do discovery

Sit with the team

Not a meeting room interview with a list of questions. Sit next to the person who does the work, on a normal working day, and watch. Ask them to think out loud. "What are you doing now? Why? What do you check before you do that? What happens if that number is wrong?"

You'll learn more in four hours of observation than in four weeks of BRD review.

Ask "what happens when..." not "how does..."

"How does the reconciliation process work?" gets you the official answer — the BRD answer. "What happens when the numbers don't match at the end of the day?" gets you the real one.

"What happens when a payment is returned?" "What happens when a bank statement doesn't arrive on time?" "What happens when two transactions have the same reference?" "What happens when you're not here?"

These questions surface the exception handling, the fallback processes, and the institutional knowledge that nobody thought to document.

Talk to the person, not the role

BRD interviews are structured: "As the Reconciliation Officer, what are your responsibilities?" This produces corporate answers — responsibilities, KPIs, process flows.

Better: "Walk me through yesterday. What was the first thing you did when you sat down? What took longer than it should have? What annoyed you?"

Yesterday is specific. Yesterday has details. Yesterday has the problems and workarounds and judgment calls that job descriptions don't mention.

Don't expose what you don't know

This is important and often overlooked. The operations team has been doing this work for years. They know their process intimately. If you walk in asking basic questions that reveal you haven't done your homework, they'll give you surface-level answers and mentally classify you as another consultant who doesn't understand the business.

Read the BRD first. Study the existing system if there is one. Understand the domain terminology. Then ask questions that show you've done the reading but want to understand the reality behind it.

"The BRD says reconciliation happens daily. I'd love to understand what that actually looks like in practice" is a better opening than "can you explain reconciliation to me?"

What you get

The output of proper operational discovery isn't a document. It's understanding. You come out of it knowing:

• What people actually do, not what the process says they should do
• Where the real complexity lives (it's never where the BRD says it is)
• Which parts of the process are manual because the system can't handle them, vs. which parts are manual because they genuinely require human judgment
• Who the key people are and what knowledge they carry
• What "done" looks like to the people who'll use the system every day

This understanding shapes the architecture, the data model, the workflow design, and the rollout plan. It's the difference between building a system that works in a demo and building one that works on a Monday morning when the bank statements are late and the recon person is on leave.

The BRD still matters

This isn't an argument against business requirements documents. The BRD matters — it represents stakeholder alignment, it defines scope, it provides a contractual baseline. You need it.

But it's a starting point, not the truth. The truth is at the desk, in the spreadsheet with 47 tabs, in the notebook with the handwritten rules, in the head of the person who's been keeping the lights on for five years.

Go find it.

Zenlime builds payment systems by starting with the people who operate them. Start a conversation.