Many IT tender begin in a very traditional way: requirements are gathered, coordinated, and then documented in a requirements specification or service catalog. Bidders prepare their proposals based on this foundation.

During the hearing, the vendors present how they plan to organize the implementation. In my experience, many vendors present an agile implementation concept: with sprints, a backlog, and the usual Scrum rituals. In regular reviews or so-called “show-and-tell” sessions, they present what was implemented in the previous sprint.

At first glance, this sounds like a sensible combination. The client receives a binding price and a defined scope of work. The vendor can still organize the implementation in an agile manner and deliver results on a regular basis.

In practice, however, this gives rise to two paradoxes.

The first concerns the relationship between new requests and the agreed-upon fixed price. The second goes even further: If the scope of work changes significantly during implementation, the question eventually arises as to whether the project being implemented is actually the one for which the competitive bidding took place.

Paradox 1: The more the client learns, the more pressure is put on the fixed price

During a show-and-tell session, features, processes, and user interfaces become clearly visible. This almost inevitably leads to new insights:

“We could make this form simpler.”
“We need some additional information here.”
“If we automate this step, it would save a lot of time.”
“Actually, we need one more interface.”

That’s exactly what these meetings are for. The client is supposed to provide feedback, and the solution is supposed to improve as a result.

However, a misunderstanding often arises.

The client says, “We could still add that. After all, we’re working in an agile way.”

The supplier adds the request to the backlog. The development team may implement it as early as the next sprint. Only later does it become clear that the requirement was not included in the agreed scope of work. A supplementary request follows. This comes as a surprise to the client: from their perspective, they simply provided feedback in an agile project. For the supplier, however, this constitutes an additional service that was not factored into the fixed price.

Both sides have interpreted “agile” differently.

The client expects flexibility. The supplier expects a limited scope of work despite the agile approach.

A backlog is allowed to change. However, it is not a wish list with a price guarantee.

If a new requirement is to be implemented without additional costs, another, roughly equivalent service would have to be omitted, for example. If, on the other hand, all previous requirements are to remain in place, the new request leads to more effort, more time, or additional costs.

Agility does not negate these relationships.

Paradox 2: The client is allowed to learn—but the competition must not change retroactively

Even if the client and the supplier agree on the additional work, a second question remains.

What happens if the scope of services changes so significantly during development that other companies would have participated in the original procurement process?

Perhaps a bidder did not submit a proposal because the original specifications did not align with its core competencies. Perhaps another bidder could have offered a better concept or a lower price for the scope of services that emerged later.

In that case, the change no longer affects only the existing contract. It affects the original competitive bidding process.

The Austrian Federal Public Procurement Act specifically addresses this scenario: A contract amendment is considered substantial, in particular, if the amended terms would have sparked interest from other companies in the procurement process or made it possible to select a different bid.

The further the backlog deviates from the tender specifications, the more questionable it becomes whether the contract for which the competitive bidding took place will actually be carried out.

An agreement between the contracting authority and the supplier alone is then insufficient. If the change constitutes a material amendment to the contract, a new procurement procedure is generally required, unless a statutory exception applies. This is the second limitation of so-called agility: The client is allowed to learn during the project. However, the client may not place unlimited orders with the already-selected supplier for the results of this learning process.

What does this mean in practice?

New requests arising from a “show-and-tell” session should not automatically be interpreted as a work order. Before implementation, two checks are required:

Contractually: Is the requirement already included, is it being exchanged for another service, or does it entail additional work?

Under procurement law: Does the change fall within the scope of the contracted work, or might the modified contract have been of interest to other bidders as well?

For each new requirement, there are thus four possibilities:

It is already covered by the agreed-upon scope of work.
It replaces a roughly equivalent requirement in the backlog.
It is commissioned as an additional service and is permissible under public procurement law.
It must be put out to bid separately or deferred.

This decision-making logic should not be developed only during the project. It must already be included in the tender documents and the contract.

A general statement such as “The backlog may be adjusted during the project” is not sufficient on its own. The tender documents should already clearly, precisely, and unambiguously specify which changes are possible, to what extent, and under what conditions. The overall nature of the contract must not be altered as a result.

Conclusion

Show-and-tell sessions aren’t the problem. They bring to light what wasn’t yet known when the requirements specification was drafted. That is precisely where their value lies.

However, the insights gained need clear boundaries:

Contractually: Is the requirement already included, will it be exchanged for another service, or will it create additional work?

From a procurement law perspective: Does the change remain within the scope of the tendered contract, or would the modified contract potentially have been attractive to other bidders?

What has been your experience? How are new requirements arising from sprint reviews or show-and-tell sessions handled in your fixed-price projects?

Requirements Specifications, Fixed Price, Fixed Deadline—and Please, Agile: Two Paradoxes in IT RFP Processes

Paradox 1: The more the client learns, the more pressure is put on the fixed price

Paradox 2: The client is allowed to learn—but the competition must not change retroactively

What does this mean in practice?

Conclusion

Further Reading