How to Prepare Tender Documentation for an Information System

Why Tender Documentation Is the Foundation of a Successful Project#

Tender documentation for an information system defines what the contracting authority will receive, who will deliver it, and by which criteria the quality of delivery will be judged. When the documentation is unclear or incomplete, this affects the entire project: bidders interpret the scope differently, comparing offers becomes difficult, and disputes arise after signing about what was actually agreed. Well-prepared documentation prevents these problems from the start.

Preparing documentation requires cooperation between several roles: the contracting authority understands business processes and legal obligations, while the contractor understands technical possibilities and constraints. When these two sides are not aligned before the tender is published, requirements keep changing during delivery, which extends the timeline and increases the risk of failure. It therefore makes sense to involve technical advice in the preparation of documentation before the tender is published.

This article summarizes which content areas tender documentation for an information system must cover: from defining scope, technical requirements and data to security, selection criteria, post-launch support and closing documentation. The goal is not to prescribe a single document template, but to point out the content that is most often missing in practice and therefore causes problems during delivery.

Defining Scope and Functional Requirements#

The first and most important part of the documentation is a precise description of scope: which processes will be digitized, which user roles the system needs, and which functionalities are mandatory versus merely desirable. Without this distinction, bidders estimate the scope of work based on different assumptions, which makes the resulting offers impossible to compare fairly.

Functional requirements should be written around user roles and business scenarios, not merely as a list of technical features. This approach helps the contractor understand why a given functionality is needed and supports better planning of architecture and user experience. It also allows the contracting authority to verify during delivery whether the system actually addresses real user needs, not just formal requirements from the document.

When defining scope, it helps to distinguish between building a new system and taking over or upgrading an existing one. In the case of a takeover, the documentation should provide for a review of existing source code, architecture, infrastructure and data, since this review affects how realistically the further scope of work can be estimated. The contracting authority should clearly state in the tender whether it concerns a new build or a continuation of an existing system.

• Description of business processes the system supports
• List of user roles and their permissions
• Separation of mandatory and desirable functionalities
• Whether the project is a new system or a takeover of an existing one
• Expected way of working (full project or individual work package)

Technical Requirements, Integrations and Architecture#

An information system rarely operates in isolation. Tender documentation should state which existing systems the new system must connect to, for example ERP, CRM, DMS or ECM systems, and what kind of APIs these systems already offer. When this information is missing, the contractor cannot estimate how much work the integration will require, which increases the risk of delays during delivery.

In addition to integrations, infrastructure requirements should be defined: whether the system will run in the cloud, on local infrastructure, or in a combination of both, and what availability requirements apply. For the public sector and regulated industries these requirements are often stricter, so they should be defined as early as possible, since they influence the system architecture and which parts of the work can be carried out separately.

When the system includes a mobile component, the documentation should state which platforms the application is intended for and whether it must work offline. When the system includes AI functionality such as document processing, semantic search or process automation, it is necessary to define where the data resides, what accuracy is expected, and which actions the system may perform on its own, without user confirmation.

• Existing systems that the new system must integrate with
• Type and availability of APIs on existing systems
• Infrastructure requirements (cloud, local infrastructure, or a combination)
• Availability and responsiveness requirements for the system
• Platforms for the mobile component, if required
• Scope and purpose of AI functionality, if included

Data and Migration#

When a project involves taking over or upgrading an existing system, the documentation must also define the state and volume of data to be migrated to the new system. The quality of existing data directly affects the scope of migration work, since disorganized, duplicated or incomplete data requires additional cleanup before transfer. The contracting authority should state where the data currently resides and in what form it is accessible, since this helps the contractor assess how demanding the migration will be.

Ownership of data and source code is also an important issue. The contracting authority should clearly state in the documentation that the source code and data are its property, not the contractor's, and that documentation, access credentials and passwords are part of the handover at project closure. This prevents situations where the contracting authority becomes dependent on a single contractor for every future change to the system.

For development work, the documentation should also determine how development, test and production environments are separated. Real personal data must not be used in the test environment, which is particularly important for systems that process sensitive or personal user data. This requirement should be part of the documentation, as it affects how the contractor designs testing and prepares test data.

Security and Compliance Requirements#

Information systems in the public sector and regulated industries must meet specific security and compliance requirements. Tender documentation should define which requirements apply to the specific system, for example regarding personal data protection, audit trails, access control and change logging. When these requirements are not defined in advance, they have to be added during delivery, which extends the project and increases coordination costs.

The contracting authority can also use the documentation to check whether the contractor has access to appropriate staff and knowledge for security architecture, penetration testing and identity management. Epix works with a specialist partner network for this, within which profiles with certifications in security, cloud services and infrastructure management are available, along with standards that are part of the delivery structure. These competencies are not attributed to Epix Group d.o.o. directly, but to the network as a whole.

In the public sector, documentation typically requires not only technical requirements but also user documentation, staff training and post-launch support. One example is the solution for the Municipality of Sevnica, where in addition to the software solution and interactive content for a public space, documentation, on-site installation and post-launch support also had to be prepared. Such requirements should be explicitly stated in the documentation, not merely assumed.

• Requirements for personal data protection
• Requirements for audit trails and change logging
• Access control and identity management
• Infrastructure requirements for regulated industries
• Documentation and user training after launch

Selection Criteria and Way of Working#

Besides technical requirements, tender documentation also sets the criteria by which the contracting authority will assess offers. Criteria should reflect what actually matters to the contracting authority: experience with similar projects, the ability to assemble an appropriate project team, the approach to quality assurance and the clarity of the proposed way of working. When criteria are too general, a contractor may be selected that does not understand the actual complexity of the project.

The contracting authority should also require bidders to describe their way of working: whether the project will be taken over in full or in individual work packages, and how, for larger projects, a project manager, team responsibilities and reporting method will be defined. This information helps the contracting authority assess how cooperation will proceed during delivery and who will be responsible for individual decisions.

When it comes to taking over an existing or unfinished system, it makes sense to require in the documentation that the bidder review the source code, architecture, infrastructure and data before submitting an offer. Such a review allows the contracting authority a more realistic comparison of offers, since bidders base their estimates on the actual state of the system rather than only on the description in the documentation.

• Experience with similar projects and industries
• Proposed way of working (full project or work packages)
• Definition of project management and reporting for larger projects
• Approach to reviewing an existing system, in case of a takeover
• Approach to quality and testing

SLA and Post-Launch Support#

Tender documentation should also define what support is expected after the system goes live. Without this, the contracting authority often ends up, after project completion, without a clear agreement on who fixes errors, how quickly and under what rules. Post-launch support should include monitoring of operation, error correction, technical and security updates and, where needed, further development of the system.

It makes sense for the documentation to provide for classifying errors into severity levels, for example an outage, a malfunction of a single function, a minor error with no impact on operations, and a request for change or upgrade. Each level has its own priority of handling, agreed between the contracting authority and the contractor in the support contract, rather than as a general universal response time.

Because response times vary depending on the criticality of the system and the agreement between the parties, tender documentation should not prescribe them as a uniform rule for all cases. Instead, the documentation should require the bidder to propose a classification of errors into levels and a way of agreeing on priority of handling, which allows the contracting authority to assess how seriously the bidder approaches post-launch support.

• Outage - the system or a key part does not work, highest priority
• Malfunction - the system works, a specific function does not
• Minor error - no impact on operations, included in the next release
• Request - change or upgrade, scope and timing agreed separately

Testing, Acceptance and QA#

Tender documentation should also define how testing will proceed before the system is accepted. The contracting authority should require the bidder to prepare test scenarios, carry out manual and automated testing, and test within the development process before a change is deployed to the production environment. Without clearly defined testing, the contracting authority risks accepting a system that has not actually been properly verified.

For more demanding projects, it makes sense for the documentation to provide for independent QA, separate from the development team, testing the system from a user's perspective rather than only a developer's. This is especially important for systems handling payments, personal data or critical business processes, where an error after launch can be harder to fix.

Acceptance testing should be defined in the documentation with criteria agreed in advance, by which the contracting authority judges whether the system is ready for production. Such criteria make acceptance more than a formality, allowing the contracting authority to genuinely verify whether the system meets the requirements set out in the tender documentation at the start of the project.

Documentation and Handover#

At project completion, the contracting authority must receive all documentation that allows it to manage the system independently or continue cooperation with another contractor. Tender documentation should therefore define in advance which documentation is part of the handover: technical system documentation, user manuals, access credentials and passwords, and information about the infrastructure on which the system runs.

When a system involves public space or interactive content for users, as was the case with the solution for the Municipality of Sevnica, it makes sense to include in the documentation training for staff who will operate the system after launch, as well as instructions for day-to-day work with the equipment and content. Training and documentation together reduce the contracting authority's dependence on the contractor for everyday operation and allow it to handle certain tasks independently.

Documentation should be prepared so that another contractor can use it if the contracting authority later decides to change support providers. This means source code, architecture, infrastructure configuration and the data model are not described only in general terms, but in enough detail to allow a takeover of the system without a lengthy re-familiarization process. Such an approach gives the contracting authority real freedom in choosing a contractor for further work.

Preparing a Tender Together with a Contractor#

Preparing tender documentation for an information system is easier when the contracting authority involves technical advice before publishing the tender. Epix and its specialist partner network can help break down requirements into individual work packages, so that each package can be estimated and delivered separately, which helps the contracting authority prepare documentation that bidders understand consistently.

This approach also makes sense because the project teams that can be assembled within the delivery network cover the full scope of work: from analysis and architecture through development, mobile work and AI functionality to cloud infrastructure, security, QA, deployment, documentation and post-launch support. The contracting authority can therefore plan in the documentation for a single contractor to cover multiple areas, instead of coordinating several separate contracts.

When the contracting authority cannot estimate cost in advance, it makes sense to include in the documentation a requirement for a short analysis that breaks the scope down into packages before a final offer is prepared. Such an analysis helps the contracting authority understand what the scope of work depends on - functionality, integrations, the state of data, security requirements and the level of post-launch support - before committing to a final contract.

Tender documentation for an information system is therefore not just an administrative document, but a tool with which the contracting authority reduces the risk of ambiguity, disputes and extended timelines during delivery. When scope, technical requirements, data, security, selection criteria, post-launch support and handover documentation are defined in advance, comparing offers becomes easier and delivery becomes more predictable for both sides.