A business receives three software quotes for the same idea. One covers only the screens, another includes data migration, the third adds a maintenance service. The figures sit side by side, but three different pieces of work are being compared. In that situation the problem is not necessarily pricing; the definition of need each quote rests on may simply differ.
A software project brief is the first shared working document you hand a development team. It explains why the work is being done, who will use it and within which boundaries it will be completed. Being complete does not mean specifying the colour of every button. It is enough to make visible the uncertainties that affect the quote and the delivery decision.
The scenario and targets in this guide are examples; they are not a WebWizz customer case or an achieved performance result. When writing your own brief, you can fill in the headings below with information taken from your current process.
Start by describing the job you want solved
“We want a management panel” does not say which problem is being removed. Describe the process instead, with its start and end points: where does the request come from, who handles it, which information gets re-entered, how do you know the job is finished?
In a field service business, for example, customer requests may arrive by email and phone. The aim is to collect every request in one shared list, assign it to a responsible person and track the promises made to the customer. That definition turns the project from a generic panel into a measurable workflow.
Separate the success measure from the baseline
You can measure the time between a request arriving and being assigned to an owner. If you do not know today's value, do not invent an estimate inside the brief; write “to be measured for one week before the pilot”. When setting targets, also explain the calculation rules: working hours, cancelled requests, automatically created records.
Name the owner of the measurement. The operations lead can confirm that the duration is meaningful for the business while the technical team describes where the events will be recorded. That way, at the end of delivery, both sides are looking at the same indicator.
Write users together with their tasks and permissions
The labels administrator, employee and customer are not enough on their own. For each role, state which records they can see, which fields they can change and which actions they can approve. In a multi-branch business, will an “employee” see only their own branch or the whole organisation?
You can build user stories on this logic: “As a service supervisor I want to see overdue requests, so that I can reassign them.” The GOV.UK guidance likewise describes the person, the need and the goal together in a user story. GOV.UK: writing user stories.
Do not confuse permissions with a list of screens. Hiding a button does not show that the action behind it is securely prevented. Add to the acceptance conditions that critical access decisions are checked on the server and that unauthorised requests are tested. OWASP: authorization guidance.
Manage scope with three separate lists
Let the first list hold the work that is mandatory for going live. The second should contain improvements that can wait for later releases. The third should state plainly what falls outside this quote.
In the example service panel, request logging, owner assignment, status tracking and basic reporting might make the first release. Automatic route planning could be left to a later one. Replacing the accounting software could be kept out of scope. These are not recommended universal packages; they are examples of separating priorities.
Every mandatory feature should have a stated reason. If no reason can be written, the feature's indispensability can be reconsidered. Also state whether work that is out of scope will continue to be handled by the existing system; do not leave a job without an owner.
Make the “done” decision concrete with acceptance criteria
“Notifications will work” is open to interpretation. A sharper criterion could read: “When a request is assigned to another employee, the new owner sees a notification inside the application; the assignment history contains the previous owner, the new owner and the time of the change.”
If email is also required, describe that separately. The sending service accepting the request and the message reaching the recipient's inbox are not the same event. Error visibility, the retry limit and the records a manager can consult can all be separate items in the brief.
Put the exception next to the normal flow
What happens if a user submits the form twice? If the customer a record belongs to is deleted, how is the history preserved? Does the data on screen disappear when the connection drops? The cases where a user cannot complete their task determine the real work in the quote.
Tie acceptance criteria to sample data. If two teams reach the same result with the same test data, uncertainty in the delivery assessment falls. Who will run the tests, and in which environment, should be written down too.
Make integrations and data migration separate line items
Instead of “CRM connection”, write the product name, its version, the access method, the fields to be transferred and the direction. Which system creates the customer record? When an address is updated, when does the old information in the other system change? If the connection drops, who follows up on the transaction?
If API documentation does not exist yet, mark that as an assumption. Ask the development team to explain which conditions an estimate given before reading the documentation depends on.
If old spreadsheets are to be migrated, share a small anonymised sample. Without seeing column meanings, duplicate records, required fields and date formats, it is easy to mistake data migration for a file upload button. Name the person who will clean the data and the person who will sign off on the migration result separately.
Write down operating conditions and delivery responsibility
User numbers, expected concurrent load, file sizes and the devices in use can all affect the design. Instead of “make it fast”, describe a representative screen, a data volume, a test environment and an acceptable duration. Those values are a measurement target, not a performance guarantee given without measuring.
State who is responsible for domain, hosting, maintenance, monitoring and backups. Clarify whether source code, design files, administrator access and operating documentation are within the delivery scope. Who will open third-party accounts and who will manage renewals should also be answered here.
How does the quote change when the brief is updated?
Keep a short decision record for each significant change: the request, the reason, the scope impact, the schedule impact and who approved it. Make the brief's version date visible. When comparing quotes, confirm that every supplier assessed the same version.
Pre-quote implementation checklist
- Write the business problem in one paragraph, alongside the current flow.
- Define the target indicator, its data source and its owner.
- Explain user roles with example permissions.
- Separate first release, later release and out of scope.
- Add testable acceptance criteria to critical features.
- Attach integration documentation and sample data.
- Record unclear subjects as assumptions and open questions.
- Name those responsible for launch, training, maintenance and handover.
- Check that every quote is based on the same brief version.
If you would like to assess your project scope with WebWizz, you can share this document through our contact page. The first conversation can focus on clarifying the open questions in the brief and a workable first release.
Frequently asked questions
Do I need technical knowledge to write a brief?
No. Describing the day-to-day work, the user and the expected outcome is a sufficient start. Technical decisions can be opened up by the team; you do not have to write integration or infrastructure details you are unsure of as though they were settled.
Should I share the budget up front?
A budget range and schedule constraint can help define a workable scope. State that you want to see assumptions, exclusions and ongoing costs separately in the quote. Do not compare on the total figure alone.
Is a brief the same as a detailed technical specification?
A brief gives a shared definition of the need and the boundaries. A technical specification can contain more detailed architecture, interface and operating decisions. What the document is a basis for matters more than what it is called.
What if a new requirement appears after work starts?
Add the new requirement to the decision record and assess its relationship to the current scope. Do not add it to the first release automatically before the team has explained the impact. Where appropriate, it can swap places with a lower-priority item.