How to write a BRD your partner can price · Walid Redwan

A BRD is not paperwork. It does exactly two jobs, and both of them are financial.

It makes quotes comparable. Without one, three partners quote three different projects and the cheapest is simply the one who understood least. You are not comparing prices; you are comparing guesses.
It gives “delivered” a definition. Every argument at the end of a project is the same argument: whether the thing you meant was ever the thing they agreed to build. A written requirement, agreed before the money moved, settles it in a minute.

If you write nothing else, write this document.

The one rule

Describe the outcome, not the screen.

You are buying a result. The moment you specify how Odoo should look, you have taken responsibility for the design, and you have quietly forbidden the partner from proposing the standard solution that would have cost you a tenth as much.

Written badly	Written well
“Add a button on the sales order to print a custom approval form.”	“Orders above 500,000 must be approved by the commercial manager before they can be confirmed, and the approval must be visible on the order afterwards.”
“We need an Excel file with columns A to M every Sunday.”	“Branch managers need weekly stock and margin figures per branch, in a form they can filter themselves.”
“Build a screen for the guards’ shifts.”	“Each guard shift worked must produce both a payroll input and a billable line on the client contract, from a single entry.”

The right-hand column can be met by configuration, by a standard report, or by a custom module — and the partner is now free to tell you which, and to be held to the result either way. The left-hand column has already decided, badly, and it will still be wrong.

Anatomy

Ten sections. It does not need to be long — twenty solid pages beats eighty vague ones.

Business context. What the company does, how it makes money, structure, branches, legal entities, headcount. Two pages. Partners price risk, and unknown context is risk.
Why now. The event driving this — growth, an audit finding, a compliance deadline, a system being retired. This tells the partner what cannot slip.
Current state. How each process runs today, including the spreadsheets and the WhatsApp groups. Be honest about the informal parts; they are where projects break.
Target state. What you want to be true afterwards, per process. Still no screens.
Requirements. The numbered list. This is the heart of it — format below.
Volumes and data. Transactions per month, SKUs, customers, users by role, and what has to be migrated with how much history. Volume changes the architecture and the price.
Integrations. Every other system that must exchange data, in which direction, how often, and who owns the other end. Name a contact for each.
Compliance and localization. Tax regime, e-invoicing, statutory reporting, languages, currencies, audit requirements.
Non-functional. Users and concurrency, languages in the interface, uptime expectation, backup and retention, who hosts, access control by role.
Out of scope and assumptions. The section everyone skips. See below.

How to write one requirement

Give every requirement an ID, an actor, an outcome, an acceptance criterion and a priority. The ID is what makes the whole thing testable later; without IDs you cannot trace anything and stage five of this playbook does not work.

Field	Example
ID	`FIN-014`
Actor	Accounts payable clerk
Requirement	A vendor bill must not be paid twice, even when the same invoice arrives by email and on paper.
Acceptance criterion	Entering a vendor bill with a vendor reference already recorded for that vendor is blocked, with a message naming the existing bill.
Priority	Must
Notes	Roughly 400 vendor bills per month, two clerks.

The acceptance criterion is the expensive part to write and the one that pays. It is a sentence someone can test: a person can sit at the screen, do the thing, and say yes or no. “The system should prevent duplicate payments” is not testable. The example above is.

Use MoSCoW for priority — Must, Should, Could, Will not — and be ruthless. If more than about half your requirements are Must, you have not prioritized, and the first schedule problem will do it for you, badly.

The section that saves the project

Out of scope. Write down what this project is explicitly not doing, even when it feels obvious. Payroll for the second entity. The Lebanon branch. Historical transactions before this fiscal year. The website. Barcode scanners in the warehouse.

Every one of those is a conversation that would otherwise happen in month four, at the worst possible moment, with both sides certain they were right. Written down, it becomes a change request with a price — which is a normal commercial event instead of a fight.

Do the same for assumptions: what you are relying on the partner to assume. That your chart of accounts is final. That your item master is clean. That your staff are available for testing two days a week. If any assumption is false, the price was wrong, and both of you should find that out on day one.

What not to put in it

Screen designs and field lists. Covered above. You are buying an outcome.
A named technology for every gap. “This must be a custom module” is the partner’s call to justify, not yours to mandate.
Everything you have ever wanted. A BRD stuffed with Coulds gets priced defensively, and every partner adds contingency for the parts you did not mean.
A deadline with no reason. “Go live in June” invites a yes. “Go live before the October audit, because otherwise we run two systems through the close” gets you an honest answer about whether June is real.

The template

Copy this, fill it in, and send the same file to every partner you approach.

1. BUSINESS CONTEXT
   Company, activity, legal entities, branches, headcount, current systems.

2. WHY NOW
   The event driving the project. What genuinely cannot slip, and why.

3. CURRENT STATE  (one block per process)
   Process name .......
   How it runs today ..
   Who does it .........
   Where it hurts ......
   Systems and spreadsheets involved ......

4. TARGET STATE  (one block per process)
   Process name .......
   What must be true afterwards ......
   How we will know it is better ......

5. REQUIREMENTS
   ID | Actor | Requirement (outcome) | Acceptance criterion | Priority | Notes
   Prefix IDs by area: FIN- SAL- PUR- INV- MFG- HR- REP-
   Priority: Must / Should / Could / Will not

6. VOLUMES AND DATA
   Transactions per month, by type ......
   Master data counts (customers, vendors, items) ......
   Users, by role ......
   Data to migrate, and how much history ......

7. INTEGRATIONS
   System | Direction | Data | Frequency | Owner and contact

8. COMPLIANCE AND LOCALIZATION
   Tax regime, e-invoicing, statutory reports, languages, currencies, audit needs.

9. NON-FUNCTIONAL
   Concurrent users, interface languages, uptime expectation,
   backup and retention, hosting, access control by role.

10. OUT OF SCOPE
    Explicitly not part of this project.

11. ASSUMPTIONS
    What we are relying on. If any of these is false, the price is wrong.

12. DECISIONS AND OWNERS
    Executive sponsor ......
    Decision owner (signs the scope) ......
    Process owner, per area ......

Before you send it

Give it to the two or three people who will actually use the system every day and ask them what is missing. Not the managers — the clerk, the storekeeper, the person who does the reconciliation. They will find the informal step that keeps the business running and that nobody wrote down, and finding it now costs nothing.

Then send the identical document to every partner. The differences in what comes back will tell you more about the partners than any reference call.