Skip to content
Call, 0511 – 47 55 58 11

The IT project agreement

Whether an IT project succeeds is rarely decided in the code and often in the contract. The three points where projects fail are the description of services, cooperation and the change procedure.

Project agreements rarely fail on a wrong clause and frequently on missing ones. Whatever is not settled gets negotiated under time pressure, and then the party with less to lose negotiates better.

What belongs in the contract

Acceptance divides the project in two

In a works contract, acceptance is the point at which almost everything changes. Until then the supplier has to show that performance conforms. After it the customer has to plead and prove the defect. At the same time payment falls due, risk passes, and the limitation period for defect claims starts to run.

Three points therefore belong in the contract. First the criteria against which acceptability is measured, settled before the test and not while its results are being argued over. Second the treatment of remaining defects, because acceptance rarely fails on the whole and often on details. Third partial acceptance, where delivery comes in stages.

Acceptance can also occur without anyone declaring it. If the supplier sets a reasonable deadline and within that period the work is neither accepted nor refused stating at least one defect, it is deemed accepted. Productive use may also amount to tacit acceptance. Anyone accepting without reservation despite known defects loses their rights to that extent, and the same applies to an agreed contractual penalty.

How we support you

We draft project agreements on both sides, review drafts before signature and accompany running projects where conflicts are emerging. The earlier we join, the more options remain.

A project in preparation?

The cheapest time for the contract is before the start.

Get in touch

Frequently asked questions

How does a contract fit agile working?

Well, where it reflects the approach instead of asserting a fixed scope nobody intends to keep to. What works is a framework with firm rules on roles, cadence and decision paths, plus a procedure turning requirements into binding deliverables. A fixed price on an undefined scope, by contrast, is a conflict in slow motion under any methodology.

Why do cooperation duties matter so much?

Because they are the decisive question in any dispute about delay. Who owes which input, contacts, test data or approvals and by when belongs in the contract. Without it, the risk usually falls on the party that could have documented it better.

Can acceptance occur without our declaring it?

Yes, in two ways. If the supplier sets a reasonable deadline for acceptance and within that period the work is neither accepted nor refused stating at least one defect, it is deemed accepted. In addition, productive use may amount to tacit acceptance. In both cases the consequences are the same as for a declared acceptance, which is why deadlines have to be answered even while the dispute continues.

Does a contractual penalty for delay make sense?

It saves you from proving actual loss, and that is where its value lies. In standard terms it is subject to content review, so it needs a clear trigger and a cap. One point decides in practice: anyone who accepts performance without reserving the penalty loses it. The reservation therefore belongs in the acceptance record.

What do we settle in case it does not work out?

Milestones with an option to stop, the treatment of work already performed, rights in interim results and source code, handover of documentation and who bears the migration. These provisions cost little in negotiation and decide everything when it matters.

Related