A software procurement brief does one thing: it communicates a problem clearly enough that the right supplier can tell you whether they can solve it, and at what cost. When briefs fail, they fail at that first step. They describe outputs instead of the underlying problem, omit the context that shapes a credible response, and produce a stack of proposals that are technically compliant but impossible to compare.
This guide is for procurement officers and project leads in public sector organisations who are commissioning software — whether back-office tooling, case management, compliance systems, or bespoke integrations. The same principles apply to pre-market engagement, Prior Information Notices (PINs), and full ITT documentation.
Start with the problem, not the solution
The most common brief failure is writing a feature list rather than describing a problem. A feature list tells suppliers what you think you need. A problem statement tells them what you are trying to achieve and gives them room to tell you whether your solution is the right one.
The difference in practice:
- Feature-led (less useful): "The system must include a case management module with configurable workflow states, a document repository with version control, role-based access controls, and a reporting dashboard."
- Problem-led (more useful): "Case officers currently manage approximately 200 active cases each using a combination of email, a shared drive, and a legacy system that does not integrate with our HR platform. Cases frequently stall because document sign-off is tracked manually. We want case officers to spend less time on administration and more time on casework."
The second version communicates the actual problem. It also gives a capable supplier the information they need to challenge your assumptions — which is precisely what you want before a contract is signed.
The seven things every software brief must include
1. The operational context
Who uses the system, how often, and in what conditions. A system used by 12 officers in one building has different requirements from one used by 300 field workers across multiple sites. This context shapes every architectural and design decision a supplier will make.
2. The current state
What do people use today, and where does it break down? The existing tools, workarounds, and failure points are the actual brief. Suppliers who understand where the current process fails can design toward fixing those specific failures.
3. The data environment
What data does the system need to work with, and where does it live? Integration requirements — with existing systems, APIs, or data sources — need to be stated explicitly. Discovering mid-delivery that the new system needs to talk to a legacy platform nobody documented is the most common cause of scope overrun.
4. Measurable success criteria
What does a successful outcome look like, in concrete terms? "Improved efficiency" is not a success criterion. "Reduce average case processing time from 14 days to 5 days within six months of go-live" is. Success criteria anchor the evaluation of proposals and provide the basis for post-delivery accountability.
5. The budget range
Include it. The argument against stating a budget — that it protects you from inflated pricing — does not hold in practice. What it actually produces is responses calibrated to completely different budget assumptions, which makes like-for-like comparison impossible. A realistic budget range allows suppliers to scope appropriately and allows you to judge whether their proposed approach is credible for the stated cost. It also signals to capable SME suppliers that this is a serious, well-considered project worth bidding.
6. The timeline
Not just the go-live date. The key milestones: when must a working prototype be available, when does user acceptance testing begin, what are the hard dependencies? A supplier who knows a council budget cycle ends in March will scope delivery differently from one who assumes a flexible timeline.
7. The post-launch expectation
Software does not stop needing attention at go-live. State what ongoing support, maintenance, and iteration looks like. Is this a handover to an internal team? A managed service? A rolling contract? Suppliers who do not know the post-launch model cannot price it, which means either it is excluded from the proposal or it is buried in assumptions that will surface as costs later.
The length test. If your brief requires more than 10 pages to describe the problem, the problem has not yet been clearly defined. A well-scoped project should be expressible in 4 to 8 pages. Briefs that run to 40 pages of feature specifications attract large consultancies with bid teams and filter out capable SME suppliers who cannot absorb the cost of responding in full.
What to leave out
Several things that commonly appear in procurement briefs make them harder to respond to, not easier.
Prescriptive technology requirements. Specifying the programming language, database technology, or cloud provider is rarely appropriate unless your organisation has a specific technical constraint that makes interoperability genuinely necessary. Technology mandates narrow the supplier pool without a corresponding benefit, and they transfer responsibility for architectural decisions from the supplier — who should own them — to the procurement officer, who usually should not.
Generic compliance boilerplate. Most briefs include several pages of standard terms, legal references, and compliance language that is either self-evident or handled through the contract. This adds length without adding information. Suppliers learn to skim it. The result is that genuinely important compliance requirements — specific data residency requirements, sector-specific regulatory constraints, security classifications — get lost in the noise.
Comprehensive feature lists as requirements. A list of 60 required features signals that requirements have not been prioritised. In practice, not all features carry equal importance. If a brief does not distinguish between must-have requirements and desirable ones, suppliers have no basis for proposing a phased approach or a minimum viable first delivery — which are often what the project actually needs.
Pre-market engagement is not optional
The Procurement Act 2023 explicitly supports preliminary market consultation. Used well, it produces better briefs by exposing assumptions before they become contractual commitments.
A structured pre-market engagement process — a Prior Information Notice followed by supplier briefing sessions open to a broad range of organisations, including SMEs — typically surfaces three things: capabilities that exist in the market that the procurement team did not know about, constraints that the brief had underestimated, and a realistic picture of what the stated budget will and will not deliver.
Procurement officers who engage the market before publishing a brief consistently write better briefs. The market tells you what is achievable. You write the brief around what is achievable.
Evaluating responses
A well-written brief makes evaluation straightforward because responses can be compared against the same criteria. The most useful evaluation framework for a software procurement weights four things:
- Understanding of the problem — does the supplier's response demonstrate that they have genuinely understood the operational challenge, or does it read like a repurposed proposal? This is the single most reliable signal of whether a supplier will deliver something useful.
- Credibility of the delivery approach — is the proposed methodology realistic for the timeline and budget stated? Are the risks acknowledged? A proposal that contains no risks is not a credible proposal.
- Post-launch accountability — what happens after go-live? Specifically: who is the ongoing point of contact, what is the response commitment for issues, and how are changes to requirements handled after delivery?
- Security and compliance credentials — at minimum, Cyber Essentials certification, GDPR evidence, and confirmation of the data processing relationship. These are non-negotiable baselines, not differentiators.
Price is a factor but should not be the primary differentiator in software procurement. A proposal that delivers the stated outcomes at a higher cost is almost always preferable to a cheaper proposal that does not. The Public Contracts Regulations and their successor framework under the Procurement Act 2023 both support quality-weighted evaluation models.
One final point
The best procurement briefs are written by people who have spoken to the people who will use the system. Not the project sponsor. Not the IT director. The case officers, the compliance managers, the finance team doing the month-end run. Their description of where the current process breaks down is the actual brief. Everything else is documentation.