Home > Praxis > Your project > Concept Planning > Tendering procedure for digital projects

Tendering procedure for digital projects

Procurement and tendering processes in the IT sector are often very diverse and complex, and can are therefore be difficult for non-experts to manage.

Invitations to tender may cover a range of areas from purchasing software licences and purchasing/leasing hardware to IT consultancy services. Implementation and migration services for integrating new systems into the existing IT landscape will also often be required, and the users of these new systems will need support and training. Depending on the product or service procured, maintenance, servicing and support will often also be provided throughout the contract term.

There is no blueprint for digital project tenders, so procurement in the IT sector will often consist of a combination of requested services.

The step-by-step tendering guide below shows you what you need to consider at each stage of the tender process for digital projects.

Stage 1: Set the objective

Digital projects in the context of DC aim to deliver change and development effectiveness. Even if the invitation to tender sets out clearly defined services and quantities at the outset, it is still essential to digital technologies.

Stage 2: Ascertain what similar options cost and who can help research the market

Before you draft your tender, you should look at whether and how others have carried out similar work. As such, in the preliminary stage of a tendering process, it is essential to research the market, which will also help you to ascertain what kind of budget will be required. As project leaders often lack the knowledge required for researching markets themselves, it is advisable to appoint a competent consultant who can guide you through the whole tendering and service provision process.

Stage 3: Define the scope and content

Next, precisely identify all the main services that the contractor must provide, and make sure to prevent any unintentional growth in scope (‘scope creep’). You should not defer decisions regarding pricing until the implementation phase. The performance specification should be sufficiently detailed and specific in order to minimise the risk of conflict with the contractor over performance obligations in the bidding phase.

If scope creep is likely because, for example, you have decided to adopt an open-ended agile methodology (see section 3.4), you should also consciously plan for this. Be aware of your limits. What should be the maximum cost for the development of a digital solution and how long should it take? How many people involved in the process can you or a contractor manage? Set upper limits as parameters of the contract.


Open source is a term used to describe software built with source code that is open and freely available.

Open-source software tends to be used by people or organisations who can not afford the high upfront costs involved in procuring proprietary software. This is also a possibility for open-ended digital projects, where solutions are incrementally implemented – e.g. when a local authority develops its own data management system and rolls it out department by department. The low costs involved in procuring and maintaining open-source software can, at first glance, make it a very attractive proposition. However, training users to operate open-source systems can be time-consuming and, when it comes to licensing rights, a number of questions are likely to remain unresolved.



In your invitation to tender, do you stipulate that you want to be charged

  • a fee that is directly related to time and material or
  • a fixed price for each project.

Fixed prices are often used for projects requiring resources that can be easily calculated, are usually small-scale, and can be provided over a set period of time. Hybrid forms are also common.


If you have a recurring standardised procurement (e.g. licences of standard software) that cannot be quantitatively determined going forward, it is worth considering using a framework contract. A framework contract allows the commissioning party to request individual services (e.g. 25 licences) without having to retender each time.


If you want to put out to tender management solutions that are critical for the organisation (e.g. enterprise resource planning systems – see www.t1p.de/ rx6k), you need to pay special attention to the maintenance model requested. Stipulate in the tendering documentation that the contractor must ensure their product has a long lifecycle. This will deter them from using outdated software and lower similar risks. Keep in mind that the organisation’s success will depend on the maintenance and operation of the digital solution being procured. As such, integrate as many risk mitigating factors as possible in the specification.


While a functional specification describes goals and sets out a framework for bidders (e.g. that the system must meet certain performance criteria without specifying how these are to be achieved), a technical-constructive specification makes very concrete specifications regarding individual performance features (e.g. a detailed description of the technical performance features of the hard ware and software to be procured). Note that a term of reference can combine elements of both approaches.

In a functional specification, the details of the later realisation of the project can be adjourned to the implementation phase. This means that in the initial project phase, the contractor defines the project goals to be achieved in the implementation phase.


The way in which tasks are distributed between the commissioning party and contractor can vary greatly in digital projects. However, it is useful to divide your project into three phases: planning, implementation and operation. In each phase, different cooperation models between the commissioning party and contractor can be adopted. These models are described below and should be specified in your invitation to tender:

In the contract manufacturer model, responsibility for preparing the specification in the planning phase falls to the commissioning party. The contractor is responsible only for implementation (e.g. of an existing concept), whereas activities relating to the operation are performed solely by the commissioning party. With this model, the costs and time requirements will be higher for the commissioning party during the planning phase, and the commissioning party must ensure it has the resources (professional expertise, personnel, time) required to put together the specification.

Careful preparation will ensure that the estimated costs of the implementation phase to be assumed by the commissioning party will be much more accurate and reliable.

In the cooperation model, the commissioning party and the contractor jointly draw up the professional and technical specifications, which determine what is to be carried out by the contractor in the implementation phase. When using this model, it often makes sense to assign the specification and implementation processes to two different companies. Cooperation between the commissioning party and contractor can resume in the operation phase. Regardless which cooperation model the commissioning party decides to use, it is essential to clearly define who is responsible for what in the specification and contract.

Regarding quality assurance, commissioning parties are advised to seek the advice of specialised consultants, unless sufficient resources are already available in the company. This kind of external input ensures that the commissioning party’s interests are better protected throughout the project.

The selection of IT consultants should mainly be based on whether they have sufficient experience in similar projects. Commissioning parties should seek contractually assured commitments from IT consultants that they have no conflict of interest with other potential contractors and will provide independent and unbiased advice to the commissioning parties.

When awarding contracts for installation, customisation, maintenance, operation and training services, consider which services need to be provided by the commissioning party itself. These will need to be carefully defined in the specification because they are directly relevant in the cost calculations. Furthermore, it may be advisable when jointly developing the project to provide anonymised information on the qualifications held by the commissioning party’s employees. In this way, bidders can form their own impression of the resources that will be available to the project.

However, with complex and long-term projects, the commissioning party may be unable to reliably predict the availability of its human resources throughout the project period.

The commissioning party may be unable to perform the intended services, which can result in the contractor incurring unexpected additional expenses that it will subsequently seek to reclaim. It is therefore important that, as the commissioning party, you describe the services you intend to deliver yourself as precisely as possible.

Contractors may also wish to offer further support services as optional extras in their bid, which you can choose to avail yourself of if necessary. When assessing bids, it is useful to treat proposals for support services and the thinking behind them as a positive criterion that, where appropriate, can help you refine your specification.


Questionnaires that list all the functions required of the contractor and that bidders will find easy to understand and quick to complete have proven very effective.

Besides detailing the services you intend to contribute, the invitation to ten der should contain precise information on the contextual environment of the work being tendered– e.g. the specification of the existing IT infrastructure that you wish to develop or the → data protection requirements.

Stage 4: Use a checklist for a final revision once you have drafted the tender

Stage 5: Drawing up selection criteria

Draw up a list of the criteria for determining which tender represents the best value. These criteria must relate strictly to the tender and not to the companies which submitted bids.

In terms of logic and structure, the list of criteria follows the specifications. For each section of the specification, the commissioning party will decide what constitutes a high-quality bid and how this aspect will be weighted vis-à-vis other aspects of the specification. Examples of selection criteria:

  • Ability to expand and adapt the system
  • System environment and platform
  • Data protection and security (see section 3.3)
  • Compatibility with existing/predetermined systems
  • Interfaces
  • Migration of legacy data
  • Maintainability of the systems
  • Onboarding, training
  • Customer service and response times
  • Presentation/testing (fulfilling the task set)
  • Aesthetics
  • Commercial conditions (contractual terms, risk structure)

The above-mentioned criteria are examples only and must be adapted to the specific case. If necessary, sub-criteria should be developed to support the development and use of the criteria. The sub-criteria should be weighted and the rationale for this weighting made transparent to bidders.

The selection criteria must be defined as either exclusion (potential criteria for being rejected) or assessment (‘nice to have’) criteria. Tenders that fail to fulfil an exclusion criterion are rejected outright, whereas those failing to fulfil an assessment criterion are awarded 0 points for that specific item only.

In the latter case, the tender remains in the competition and may be able to offset the lack of points for one criterion with high points for another. When defining the list of criteria, commissioning parties tend to focus on setting exclusion criteria, because they deem all aspects of the specification to be mandatory requirements and of special importance for the project. However, having a lot of exclusion criteria substantially inhibits the qualitative evaluation of tenders, because reviewing bids using exclusion criteria only ensures compliance with minimum technical requirements. On the one hand, innovative solutions to technical problems are not honoured by this kind of evaluation and, on the other, all bidders meeting the minimum requirements will end up achieving the same score, thus homogenising the bids received. In practice, a combination of exclusion and assessment criteria for individual technical requirements has been shown to be the best approach.

Formulate additional test exercises (sample development)

When procuring software and hardware, commissioning parties should avoid evaluation merely on the basis of printed tenders. Sample developments give commissioning parties the opportunity during the tender process to test the products they are seeking to procure.

They are also a good opportunity to include committees in the tender evaluation process (e.g. as the audience for a presentation of the software). In this respect, the sample development constitutes the practical side of evaluating tenders.

There are two kinds of sample development:

  • Sample for verification, which is used to verify information included in the tender.
  • Sample for evaluation, which is used to evaluate the tender as part of the contract award decision and results in a separate score for the sample.

Both types of sample are possible and their usefulness will be determined by the tendering process in question. It is, however, important to inform bidders in advance whether you will be using the sample development for evaluation or only for verification purposes.

If an evaluation sample is used, the commissioning party must also provide bidders with a list of criteria. Where required, this must also detail how aspects of the sample and the individual criteria will be weighted (including the overall scores).

Stage 6: Criteria for selecting the winning bid

It is helpful if the bidder sets out the expected investment and operating costs for a five- or ten-year time frame from a total cost of ownership (TCO) perspective. This makes various project constellations comparable.

Service, licensing and hardware costs should also be broken down. It is impor tant here that parameters based on the selection criteria must be reflected in the contract and, where required, defined as enforceable.

Only then can bidders be expected to make realistic TCO forecasts. Without this kind of contractual consideration, there is also a risk that those providing realistic figures will be at a disadvantage to those providing optimistic ones.

If software licences are required, the provider should offer different procure ment options:

  • Purchase
  • Lease
  • Software as a Service (SaaS) – The SaaS model is based on the principle that the software and IT infrastructure are operated by an external IT service provider and used by the client as a service. An internet-enabled computer and internet connection to an external IT service provider are required to use online services. For more information, please see www.t1p.de/2s30

What qualifications and experience does the bidding team need to have?

  • Examples of useful qualifications
  • Experience of/direct link to the open-source/civic tech movements
  • Experience of adapting existing digital technologies
  • Experience of ensuring the interoperability of different kinds of digital technologies
  • Experience of identifying suitable kinds of digital technologies in diverse contexts
  • Experience of providing effective solutions for complex scenarios/contexts
  • Experience of working with multidisciplinary development teams, different clients and, above all, with the public sector
  • Experience of design thinking or other participatory processes Focus specifically on the methods and checklists presented in this section, as these cover all the important requirements for successfully implementing an digital project.