Why Can Negotiations on Large Projects Take the Longest Over a Single Word?

That was the process behind negotiating one IT project contract. Discussions covered both key commercial commitments and individual phrases and terms. The parties reached a balanced agreement, whose practical value is reflected in their continued cooperation: they are performing the contract and working together.

This experience highlights a challenge common to IT projects. The client seeks an agreed outcome, budget and delivery schedule, while the contractor must commit to a solution whose technical or functional details may only become clear as the project progresses. In software development, system implementation, integration and modernisation projects, requirements are often refined in stages. When entering into the contract, it is therefore important to agree how much of this uncertainty each party assumes and how decisions will be made as it becomes clearer.

A clause requiring the contractor, for a fixed price, to perform “all work necessary to meet the client’s needs” may seem clear enough—until it has to be applied to specific tasks. Does it cover only the needs described in the contract documents? What about needs discussed during negotiations but not recorded? And how should the parties treat a need identified by the client during analysis or testing and considered an obvious part of the solution being commissioned?

Adding the word “agreed” to such a clause can significantly change the scope of the commitment, but only if the parties can establish where and how specific needs were agreed. Negotiations over a single phrase often raise a broader question: what outcome is the contractor committing to deliver, and what criteria will determine whether that commitment has been met? The answer affects payment for additional work, changes to the schedule and responsibility for the project’s progress.

The possibility of establishing the parties’ true agreement if a dispute arises is no substitute for defining it clearly in advance. The project team needs a shared point of reference from the outset, when making day-to-day decisions about specific tasks.

A fixed price gives the client budget certainty, but its practical value depends on the agreed scope. Stating a price alone does not resolve a disagreement if one party ties it to specifically described functionality, while the other interprets it as covering all work that may be needed to achieve a broader business objective.

For example, a commitment to build the data exchange functionality described in a specification may involve a very different scope of work and risk from a commitment to ensure the smooth flow of information between all of the client’s systems.

The price should therefore be based on sufficiently defined functional and non-functional requirements, agreed integrations, work boundaries and key implementation assumptions. Data quality, system availability, performance, security and third-party involvement may all be significant. It is not necessary to resolve every technical detail when the contract is signed, but the parties should clarify which details will be refined as part of the existing commitment and which decisions could change its scope.

The legal consequences also depend on the nature of the contract. IT contracts may combine elements of contracts for work, services, licensing and other arrangements, so their legal classification must be based on the specific obligations they contain. Where the rules on contracts for work apply, Article 6.653(5) of the Civil Code generally does not allow a specific price for the work to be increased solely because the volume of work or necessary costs could not be accurately anticipated when the contract was concluded. Higher-than-planned performance costs and a change in the scope of work requested by the client are circumstances that must be assessed separately.

A well-drafted IT contract does not create the illusion that a project will never change. It sets out which risks are already included in the price and which will require the parties to make a new commercial decision.

A fixed price can be an effective contractual arrangement. But it protects the budget only when both parties have the same understanding of what the price covers.