How to brief a software project

Why the brief matters

Most project failures are decided before the first line of code: a vendor hears a feature list, prices it, builds it, and only then discovers what the organization actually needed. A short, honest brief lets a vendor ask the right questions on the first call and quote something that fits.

Start with the problem, not the solution

Describe the situation in the words your staff use. What takes too long, gets lost, gets re-typed, cannot be found or cannot be trusted? Where does paper still rule? What question does management ask that nobody can answer quickly?

• One paragraph on how the work is done today
• The two or three things that hurt most, with an example of each
• What it costs you now: hours, delays, errors, complaints, missed revenue
• Who feels the pain: staff, the public, partners, management

Who will use it

List every group that will touch the system, including the ones that are easy to forget: field staff with a weak connection, a finance officer who only needs reports, an auditor who needs to read but not change, a partner that needs data by API.

• Each user group, roughly how many people, and where they work
• Their devices and connectivity: office computers, personal phones, no reliable network
• Languages the interface must support
• Who approves what, and who may only view

What it must do, should do, could do

Separate the essentials from the wishes. A first version that does the essentials well is worth more than a long list half-done. Phrase requirements as outcomes, not screens.

• Must: without this the system is not useful
• Should: important, but the first version can live without it
• Could: valuable later; park it for phase two
• For each item, say how you will know it works

Existing systems and data

Say what is already in place and what the new system must connect to or replace. Data migration is the part everyone underestimates.

• Systems in use today, who owns them, and whether they will stay
• Where the current data lives: registers, spreadsheets, an old database
• Roughly how much data must move, and how clean it is
• Integrations required: payments, SMS, identity, reporting to a ministry or donor

Constraints

Constraints are not obstacles; they are what makes a proposal realistic. State them early.

• Timeline, and what drives it: a programme start, a fiscal year, a regulation
• Budget range, even approximate; it decides what is feasible in phase one
• Procurement rules: tender format, evaluation criteria, required documents
• Hosting and data rules: in-country data, a specific review process, source-code escrow
• Who decides, and who must be consulted

What you do not need to include

You do not need a technical specification, a database design, a list of technologies or screen mock-ups. If you have them, attach them as reference, but a vendor who insists on them before understanding the problem is solving the wrong thing.

What happens after you send it

With us, a brief leads to a discovery conversation, then a written proposal with scope, architecture, milestones, acceptance criteria and price. You can read how that works on the how-we-work page and what it costs on the pricing page before you send anything.