How to write a useful software project brief

Describe the job, then the difficulty.

Start with a plain-language description of the task. Who does it, what triggers it and what should the result be? Then explain which part is slow, unclear or difficult to manage. This is more useful than beginning with a list of screens.

For example: 'Our coordinator receives requests by email, records them in a spreadsheet and asks a manager to approve them. We lose track of which requests are waiting for a decision.' This is an illustrative example, not a client story. It makes the workflow and the problem visible without prescribing a solution.

Include the people and the exceptions.

List the types of users and the actions each needs to take. Someone who submits a request may need different access from someone who approves it. Identify any accessibility requirements and the devices the team actually uses.

Describe what happens when information is missing, a request is duplicated or a decision changes. Those details can materially change the scope. You do not need every answer immediately: mark unknowns as questions rather than making assumptions look settled.

State the boundaries honestly.

Explain which existing tools must remain, who controls access to them and whether there is a real deadline. If a deadline is tied to an event, explain the reason. If a budget range exists, sharing it can help distinguish essential work from optional additions.

Use general descriptions of the data involved. Do not paste passwords, live personal records or confidential documents into an initial enquiry. Sample files can be discussed later with appropriate permissions and arrangements.

• Current tools and the people who administer them
• Expected users and approximate workload, where known
• Important deadlines and why they matter
• Essential functions versus later improvements
• Responsibilities for reviewing and maintaining the result

A brief you can adapt.

Use the following as an internal starting document. Keep the first version short, leave unknowns visible and remove any fields that do not help explain your project. You do not have to send the full document through our website form.

PROJECT / WORKING TITLE

The task we need to improve:
Who does this work today:
The tools we currently use:
Where the process becomes difficult:
What a better result would look like:

Essential for the first version:
Could wait until later:
Important exceptions or approvals:
Existing systems we must connect to:

Data involved (general description only):
Access or accessibility requirements:
Deadline and reason, if any:
Budget range, if known:
Who can review and approve the work:
Questions we still need to answer:

Define how you will know it works.

Choose a few examples that demonstrate the intended outcome. For the fictional request workflow, that could mean a new request can be recorded, a manager can approve or return it and the coordinator can see its current state. Test examples should also cover a missing field or a rejected request.

The brief is a conversation starter, not a contract or a complete acceptance specification. Scope, fees, ownership, data handling and delivery responsibilities need to be agreed separately. For your initial enquiry, send a short summary of the task and the main problem rather than sensitive supporting material.