{"id":3870,"date":"2026-09-08T08:26:47","date_gmt":"2026-09-08T08:26:47","guid":{"rendered":"https:\/\/sawaryn.com\/?p=3870"},"modified":"2026-10-23T11:34:26","modified_gmt":"2026-10-23T11:34:26","slug":"negotiating-it-implementation-contracts","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/negotiating-it-implementation-contracts\/","title":{"rendered":"IT Contracts That Keep Projects on Track: Negotiate Without Chaos or Disputes"},"content":{"rendered":"

Your ERP vendor has sent over a draft agreement. Forty-eight pages. The project manager says to sign because the project is running late. The CFO asks about penalties. The CTO says nobody reads it anyway. You know that in six months this agreement will determine who is responsible for a delayed go-live.<\/p>\n

Sound familiar? If so, this article is for you.<\/p>\n

An IT contract<\/strong> is not a formality to file away. It is a project-management tool that organizes cooperation, allocates risk and gives both parties predictability. A poorly negotiated implementation agreement<\/strong> creates direct costs, such as contractual penalties, renegotiations and disputes; operational costs, such as delays, downtime and duplicated maintenance costs; and strategic costs, such as vendor lock-in, loss of code rights and blocked product development.<\/p>\n

Studies indicate that about 25% of IT projects in Poland fail, and the figure reaches 20% for ERP implementations. With contract values measured in millions of z\u0142oty, losses can be substantial.<\/p>\n

This article explains how to negotiate an IT contract<\/strong> that organizes work with a vendor instead of generating disputes. It covers five areas to settle before signing, how the AI Act changes agreements for AI tools and practical steps for both customers and vendors.<\/p>\n

Key terms before we begin<\/h2>\n

Before getting into the details, it helps to clarify a few terms used throughout the article.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
Contract for a specific work<\/strong> (Article 627 of the Polish Civil Code)<\/td>\nAn obligation to deliver a defined result, such as a working system. The customer has statutory warranty rights for defects. Claims become time-barred 2 years after delivery of the work.<\/td>\n<\/tr>\n
Service agreement<\/strong> (Article 750 of the Polish Civil Code)<\/td>\nAn obligation to perform services with due care, not to deliver a specific result. There is no statutory warranty for defects. The limitation period is 3 years.<\/td>\n<\/tr>\n
Change request<\/strong><\/td>\nA formal process for submitting and approving changes to project scope while work is underway.<\/td>\n<\/tr>\n
SLA (service-level agreement)<\/strong><\/a><\/td>\nA document setting measurable service-quality parameters, such as availability, response time and repair time.<\/td>\n<\/tr>\n
Vendor lock-in<\/strong><\/td>\nDependence on one technology provider, where switching is costly or technically difficult because data migration and termination rules are unclear.<\/td>\n<\/tr>\n
Provider\/deployer<\/strong> (under the AI Act)<\/td>\nA provider creates and places an AI system on the market. A deployer uses an AI system under its authority.<\/td>\n<\/tr>\n
Exit plan<\/strong><\/td>\nA plan for ending cooperation with a vendor, including data migration, documentation handover, source-code access and service continuity.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Why an IT contract is not just a legal document, but a project-management tool<\/h2>\n

Negotiating IT agreements requires legal, business and technology skills. If only a lawyer is at the negotiating table, the agreement may be formally correct but fail to reflect the project\u2019s realities. If only a project manager is there, the arrangements may be operational but unenforceable.<\/p>\n

The problem with arrangements made \u201cover email and calls\u201d<\/h3>\n

A typical scenario looks like this: business, IT, procurement and the vendor agree on working arrangements in meetings and correspondence. Each party speaks a different language. The agreements are scattered across emails, Slack messages and meeting notes. Then the project enters a difficult phase and nobody knows exactly what was agreed or who is responsible for what.<\/p>\n

The contract should bring these perspectives together in one predictable model of cooperation.<\/strong> The point is not to make an 80-page document. It is to answer the questions that will arise in 3, 6 or 12 months, when the project is delayed, the scope changes and the relationship is no longer as comfortable as it was at the beginning.<\/p>\n

Why the legal classification of an agreement matters<\/h3>\n

Polish law has no statutory definition of an \u201cIT implementation agreement.\u201d Courts classify these contracts as unnamed agreements combining elements of a contract for specific work, a service agreement and a license. This is not an academic detail. Classification affects:<\/p>\n\n\n\n\n\n\n\n\n
Element<\/th>\nContract for specific work<\/th>\nService agreement<\/th>\n<\/tr>\n<\/thead>\n
Nature of the obligation<\/td>\nA result, such as a working system<\/td>\nDue care, such as support or maintenance<\/td>\n<\/tr>\n
Ending the agreement<\/td>\nWithdrawal, with retroactive effect<\/td>\nTermination, with effect going forward<\/td>\n<\/tr>\n
Liability for defects<\/td>\nStatutory warranty (Article 638 of the Polish Civil Code)<\/td>\nGeneral liability (Article 471 of the Polish Civil Code)<\/td>\n<\/tr>\n
Limitation period for claims<\/td>\n2 years from delivery of the work<\/td>\n3 years<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The Gda\u0144sk Court of Appeal (case I ACa 1054\/14) classified an agreement to implement a computer system as a contract for specific work because its purpose was to achieve a defined result: a functioning system meeting the customer\u2019s requirements. In case XIII GC 1603\/17, the court divided the contract into implementation work and service work.<\/p>\n

What this means for your business:<\/strong> If your agreement does not specify which elements are \u201cwork\u201d (configuration, integration and acceptance) and which are \u201cservices\u201d (maintenance, support and SLA), a court may decide how to classify them in a dispute. That classification affects warranty rights, limitation periods and whether you can withdraw with retroactive effect.<\/p>\n

Five areas to regulate in an IT contract<\/h2>\n

1. Scope of work and change management<\/h3>\n

The most common cause of implementation disputes is an imprecise functional scope. The vendor understands it differently from the customer, the project manager differently from the CTO, and the CFO differently from everyone else.<\/p>\n

The agreement should include:<\/strong><\/p>\n

    \n
  1. A detailed scope, not merely \u201cERP implementation,\u201d but specific modules, functions, integrations and exclusions.<\/li>\n
  2. A schedule with milestones linked to payments and acceptance procedures.<\/li>\n
  3. A change-request process specifying who submits, estimates and approves a change, and its effect on schedule and budget.<\/li>\n
  4. A definition of \u201cdone\u201d describing when a stage is complete and what acceptance criteria each deliverable must meet.<\/li>\n
  5. A roles-and-responsibilities matrix identifying who makes each decision for the customer and vendor.<\/li>\n<\/ol>\n

    No clear change-request procedure is a time bomb. Scope always changes. If the contract does not say how to handle changes, the vendor may impose delay penalties for changes caused by the customer, while the customer may argue that they were within scope.<\/p>\n

    2. Acceptance and testing procedure<\/h3>\n

    Acceptance is when the customer confirms that the vendor has delivered what it agreed to deliver. It may also determine when VAT becomes payable and when a limitation period begins.<\/p>\n

    The agreement should include:<\/strong><\/p>\n

      \n
    1. Measurable, verifiable acceptance criteria agreed before work starts.<\/li>\n
    2. A testing procedure: who tests, in which environment, using which scenarios, and what error threshold is acceptable.<\/li>\n
    3. An acceptance protocol specifying the form, time for comments and consequences of no response, including deemed acceptance.<\/li>\n
    4. A distinction between critical, major and minor defects and how each affects acceptance.<\/li>\n
    5. A conditional-acceptance procedure for a functioning system with non-blocking defects.<\/li>\n<\/ol>\n

      3. Intellectual property rights and code access<\/h3>\n

      Polish copyright law<\/a> narrowly defines statutory grounds for using computer programs in B2B relationships. Apart from limited exceptions, the agreement is the only basis for lawful software use.<\/p>\n

      Regulate:<\/strong><\/p>\n

        \n
      1. Whether economic copyright is transferred or a license is granted, and for which fields of exploitation.<\/li>\n
      2. Source-code access: whether you receive the code, it is held in escrow, or the vendor retains it.<\/li>\n
      3. Rights to project documentation, specifications and materials created during the project.<\/li>\n
      4. Modification rights, including whether you may hire another vendor to develop the software without the original contractor\u2019s consent.<\/li>\n
      5. The legal status of open-source components and third-party libraries used in the project.<\/li>\n<\/ol>\n

        For projects involving AI:<\/strong> AI-generated outputs, such as images, text or code, may not qualify for copyright protection if there is no human author. For work created with AI assistance, assess whether the human contribution is creative and the result individual. The agreement should address the status of these outputs.<\/p>\n