Public tenders are biased toward incumbents

Public institutions are legally required to issue a public tender to source their supplies and services in the EU. Public institutions often lack the knowledge in-house to properly assess their supplies and services on quality metrics. It becomes very tempting to describe the incumbent solution as the requirements for tender. The incumbent supplier wins the tender in such cases, unsurprisingly.

Why would you even bother to compete in such tenders?

Prefer to download this Insight instead?

Why organisations still compete in biased tenders

Tenders have several perks that traditional sales efforts cannot provide as easily:

Public institutions are tax-funded and therefore provide a steady revenue stream to their suppliers. Traditional commercial risks such as credit risk, solvency and default risk are less of an issue.

Public tenders are easily found on designated and publicly-known tender portals. It does not require a whole sales team to identify them, effectively reducing the cost to participate. It is an inbound sales opportunity.

Many organisations pride themselves in advertising that they are the supplier of a particular public institution. It highlights a particular professional standard, credibility and validity of that organisation’s products and / or services in the market. Since public tenders are usually valid for several years if not longer, it also ensures a steady market presence going forward.

These perks are the reasons that organisations participate in a structurally flawed system.

There are downsides to consider as well:

Public institutions tend to look at the solution of the incumbent as the baseline for the public tender. In some cases, that baseline is interpreted in an extreme fashion that the tender requirements literally describe the incumbent solution. This risks anything but the incumbent solution – or a poor copy thereof – to be automatically disqualified.

Many sales professionals are able to highlight enthousiastically what makes their solution unique. But public tenders tend to work with standardized formats. These formats act as straightjackets to sales professionals as it leaves little to no room to highlight the uniqueness or novelty of their solution. Indirectly, this too favours the incumbent.

Incumbent-based tender requirements frequently contain must-haves that are based on legacy technology. IT doubts feasibility of such must-have requirements as they seem counterintuitive to delivering a competitive solution. Will you choose to deliver a solution on that legacy technology unchallenged, or will you risk losing the tender by deviating from such must-haves by using modern technologies instead?

None of these downsides are technical in nature. They are all symptoms of a disconnect between how requirements are written and how it actually works in practice.

This is what we call the Field Reality Gap.

Before we validated tender requirements

We were brought in to get clarity on the IT requirements of a public tender for routing software. This routing software is used to schedule waste collection pickup in a major city in the Netherlands. Our client’s management wanted to participate in the tender with their routing software. Yet, their Developers had doubts as they lacked practical context of their own solution. Sales had confirmed that the IT requirements were a literal copy of the functionalities of the incumbent solution.

After debating tender requirements with stakeholders we found that:

Tender requirements were incumbent-based. Some functionalities described were unique to the incumbent solution, leaving no doubt that the buyer had not assessed their actual needs versus reality.

Developers had in-depth technical knowledge on how their solution worked, but had no knowledge of the incumbent solution. What really held back their collective potential was their lack of contextual knowledge. None of the Developers knew how their solution worked in practical applications.

The buyer had assigned the Team Managers to pick the winner for the tender. After all, the Team Managers were the ones responsible for creating the waste collection pickup schedules using the tendered routing software. But the actual users of the routing software itself were on the waste collection trucks. Nobody had involved them in the tender process.

We concluded that the decision-makers were not the actual end-users of the tendered solution.

After we validated tender requirements

Requirement validation did not start with the technology. It started with the environment in which it had to operate. Thus we got onto a waste collection truck with a crew to learn the actual requirements for the routing software.

This is what the Field Reality Gap looks like in practice:

The gap between paper and reality: the Field Reality Gap

This practical exercise provided us with valuable insights that were not documented in the tender requirements. We translated these insights from the on-paper tender to in-practice reality. This input enabled he Developers to deliver a fit-for-purpose solution that was quickly validated by end-users with the help of the Account Managers.

Within three months, the solution was validated by the people who actually use it. The tender outcome followed.

Where incumbents lose their advantage

Looking back, we have the following take-away’s:


Once awarded, these “must-have” requirements are revisited. Under real-world scrutiny, many of them collapse.

Do you know your end user or are you hiding behind a tender portal?