Software tender: what to include in your enquiry

A software tender should not only tell suppliers that you are looking for a solution, but also what exactly belongs in your enquiry or tender. This article shows you which information really matters so that there are fewer follow-up questions, proposals become easier to compare, effort estimates are more realistic and your project gets off to a clean start.

It is aimed at managing directors, IT leaders, specialist departments and project owners in companies, public organisations and agencies. It is suitable both for formal tenders and for more pragmatic service provider enquiries. If you would like to place your project in a rough context at the same time, the cost calculator for an initial range, the project check based on your description or a no-obligation initial consultation can help.

Why a good software tender plays a key role in project success

A software tender is not only used to select a supplier. Above all, it clarifies what objective you are pursuing, what internal expectations exist and under which conditions the project is to be delivered. That plays a key role in whether a project starts in an orderly way later on or suffers from misunderstandings as early as the proposal stage.

Unclear enquiries often lead to proposals that can hardly be compared in any meaningful way. One supplier prices a simple web application, the next assumes complex interfaces, and a third already includes tests, documentation and future extensibility. If the starting point remains vague, you quickly end up comparing different assumptions rather than genuine alternatives.

What matters here is this: your enquiry does not have to be a technical detailed specification. It should be clear from a business point of view and complete enough to make an initial, reliable assessment possible. It helps to distinguish between:

• Objective: What is meant to improve?
• Solution idea: How might that be achieved?
• Detailed requirement: Which specific function is needed?

For new projects, the focus is on objectives, users and core processes. For replacements, legacy data, existing weaknesses and transitions are important. For enhancements, existing systems, services covering development and operation and dependencies matter above all. If the specialist department, IT and decision-makers align on the enquiry together before it is sent out, this usually saves many follow-up questions, reduces later technical debt and creates a better basis for further planning.

These points belong in every enquiry

For suppliers to assess your software tender properly, your enquiry should clearly set out a few core points. The aim is not to define everything in full detail already. What matters is that the objective, use case and framework conditions are understandable.

Start with the project objective and background. Describe which problem is to be solved, which process is currently slowing things down and whether an existing solution is to be replaced, extended or supplemented. In replacement projects in particular, brief notes on current weaknesses and the improvements you want are helpful. You can find practical examples in reference projects and client testimonials.

User groups and usage context are just as important. Write who will work with the software, in which environment it will be used and which devices it needs to run on. Devices include, for example, desktop, tablet or smartphone. Whether someone works in the office, on the move or across several locations often makes a difference to the concept and implementation.

Define the scope of functions by priority. Make a clear distinction between what is absolutely necessary, what would be desirable and what can follow later. If some points are still unclear, you can mark them as open. In uncertain early phases, a software prototype before the MVP can also make sense.

Also describe important workflows. These include typical use cases, approvals, checks, search, evaluations or notifications. Such process descriptions are often more helpful than long lists of individual functions.

Name the existing systems and interfaces, such as ERP, CRM, Microsoft 365 or other specialist systems. Interfaces are connections between systems for exchanging data. Also add which data and documents already exist, need to be migrated or will be created anew.

Then there is user management and access: roles, permissions, locations and internal and external users. Entra ID is a Microsoft service for sign-in and access management. You should also record your requirements for operation and environment, in other words cloud, internal infrastructure or a hybrid model. Microsoft Azure is a cloud platform for hosting, security and scalability.

It is also helpful to include notes on technical documentation and planned software testing in the project, even if these are only described in broad terms at the start.

How to formulate requirements clearly and comparably

Formulate requirements as far as possible from a practical point of view. A simple structure helps: Who wants to do what – and what result is expected? This turns a vague idea into a comprehensible requirement that suppliers can assess from a business perspective.

Vague terms such as “modern”, “intuitive” or “flexible” are problematic in enquiries if they are not explained. It is better to make your expectation concrete, for example through typical work steps, desired response times in day-to-day use or clear examples of what users should be able to do without unnecessary detours.

It is also important to separate must-have and nice-to-have requirements. Only then does it remain clear what absolutely has to be part of the project launch and what may only make sense later. Otherwise, it is easy to end up with proposals that miss each other because they are based on different priorities.

Also helpful: explicitly mark open points as open. That is better than concealing gaps or leaving unspoken assumptions to the supplier. Your own assumptions should also be visible, for example regarding:

• number of users
• expected volume of data
• required roles and permissions
• internal and external access

A requirements specification describes the requirements from the client's point of view. The concrete implementation can then be refined together afterwards. If your project still involves many uncertainties, a prototype can make sense before the actual project begins. As a rule, clear language is usually more valuable than technical jargon, especially when decision-makers and specialist departments are also reading.

How suppliers read and assess your tender

Suppliers do not read a tender only in terms of what is to be built. Above all, they examine whether the target picture, scope, risks and dependencies are recognisable. The more clearly these points are described, the better they can assess which solution may be suitable and where further clarification is needed.

Follow-up questions usually arise where central points are only touched on briefly, for example in relation to processes, roles or interfaces. If, for instance, the tender says that data is to be “exchanged with other systems”, but it remains unclear which systems are involved, to what extent and how often, what appears to be a small requirement quickly becomes an open-ended complex issue.

That is why good proposals often contain not only services, but also:

• assumptions
• exclusions
• open points
• identifiable risks

This helps both sides work from the same understanding of the scope.

Another assessment criterion is the sustainability of the development. What matters is not only the initial scope of functions, but also how well the software can be maintained, tested and further developed. Clean Code Development is an approach aimed at code that is easy to understand, maintainable and adaptable over the long term.

Projects that sound similar can differ greatly in effort: a CRM with a few roles has to be assessed differently from a municipal web platform with specialist data and approvals, or an enhancement with integration into Azure DevOps. Azure DevOps is a platform for planning, version control, automated testing and delivery.

Typical gaps in tenders and how to avoid them

Many enquiries fail not because there is too little text, but because the focus is missing. If it is not clear whether the main priority is speed, better process quality, clean integration, reporting or replacing an existing solution, suppliers will set different priorities.

Legacy systems are also often underestimated. Existing data, exceptions, manual workarounds and evolved processes should not just be mentioned briefly, but described in a way that makes their impact on the project clear.

Operational questions also often remain open:

• Who will operate the solution later on?
• Who will maintain the content?
• Who will manage users and permissions?

Another common issue is committing to technology too early. Start by describing the business objectives first. You should only use technical terms where they are genuinely relevant to the framework conditions.

Documentation, testing and future changeability are also often forgotten. Technical documentation is the material that makes the structure, decisions and operation understandable. Software testing is planned checking that makes faults visible at an early stage. Technical debt is the result of short-term decisions that make later changes more difficult.