IT projects involving the implementation of new information systems and technologies are among the most expensive and at the same time the riskiest investments companies undertake. Despite this, lawyers are often brought in only when the relationship with the supplier starts to fray, deadlines begin to slip, and no one can quite remember what was agreed at the kick-off meeting a year ago. In the following article, we explain why it makes sense to view a lawyer as an integral part of the project team from the very beginning, and what difference his involvement in the project makes.
An IT project as a relationship that can go wrong
Imagine your company decides to implement a new ERP information system. The tender process runs its course, a supplier is selected, the contract is signed. The project begins. Eighteen months later, you find yourself in the middle of a dispute over whether the conditions for system handover have been met, who is responsible for the delayed integration, and what the contract clause stating that “the system will be delivered in accordance with the technical specifications” actually means. The lawyer is eventually called in, but at this stage his role is already highly complicated. This situation is far from unusual. In practice, it repeats itself across industries and company sizes; only the names of the systems and the suppliers change.
Why lawyers are brought into IT projects too late
There is still a lingering perception that a lawyer in an IT project only “slows things down,” “overcomplicates matters,” or “obsesses over details that no one is going to read anyway.” That perception is rooted in a time when projects mostly involved simple software deliveries and standardized contractual terms. Today’s reality is significantly more complex.
A modern IT project typically includes, for example:
- custom software delivery or the comprehensive implementation of an off-the-shelf solution;
- migration and processing of company data in an external provider’s environment;
- integration with existing systems and third-party suppliers;
- handling personal data of employees or customers, or other sensitive information;
- compliance with specific regulatory requirements in areas such as data protection, cybersecurity, or financial supervision.
Each of these elements raises legal questions that are best addressed long before a dispute ever arises. Who owns the newly created code and know‑how? Who is liable if there is a data breach or a service outage? What happens if the supplier is no longer able to support the system or if you decide to switch to a competitor? And what will the exit from the current supplier and the transition to a new one look like in practical terms?
What a lawyer actually does in an IT project
Helping formulate the project specification, not just the contract
One of the most common sources of problems in IT projects is a mismatch between how the business, the internal IT team, and the supplier understand what has actually been ordered. A lawyer who gets involved already at the stage of preparing the tender documentation and the tender process can identify areas where requirements are too vague, where measurable success criteria are missing, or where the expectations of the parties fundamentally diverge. Clarifying these points before the contract is signed is many times cheaper than trying to resolve them during the project or after it has failed.
Translating regulatory requirements into contractual language
Companies operating in regulated environments (whether in banking, healthcare, energy, or the public sector) must ensure that their IT systems comply with specific statutory obligations. A lawyer understands these requirements and can translate them into contractual terms and operational documentation in a way that is workable for both the supplier and the internal team. It is not enough to write into the contract that “the supplier will comply with GDPR.” You need to know exactly how data processing will be set up, who acts as the controller and who as the processor, what happens in the event of a security incident, and how these rules will be implemented in technical terms.
Companies operating in regulated environments, such as finance, healthcare, energy, or public administration, must ensure that their systems meet specific statutory and supervisory requirements. A lawyer understands these rules and can translate them into the project specification, contractual terms, and operational documentation in a way the supplier can realistically deliver on. Simply stating that “the supplier will ensure compliance with applicable laws” is not enough. What you need is a clear description of how data processing will be structured, who is responsible for what in the event of a security incident, what information the supplier must provide to your internal team and to the regulator, and how these requirements affect the technical design of the solution itself.
Spotting problems before they turn into a crisis
From our perspective, the greatest added value a lawyer brings is often not a single “key” clause, but his ongoing involvement and understanding of the project as a whole and of the objectives it is meant to achieve. When a lawyer is part of the project team, he can spot early warning signs that something is going off track – repeated delays, unclear deliverables, conflicting interpretations of the contract, and similar issues. At that point, he can recommend formally recording reservations about the quality of a delivery, flag an impending delay, or suggest adjusting the contract through an amendment. Often, this comes down to a carefully worded e‑mail or meeting minutes. A year later, that very document may determine the outcome of a court dispute.
Two projects, two very different outcomes
To illustrate this, and without naming any names, imagine two comparable companies that, around the same time, implemented a similar project: the implementation of a new CRM information system.
The first company brought in a lawyer only when, after a year, the supplier announced that the project would take another six months and cost 30 percent more. It then emerged that the contract contained no firm milestones or delay penalties, changes were not contractually regulated at all, and the internal team had been signing off interim “approvals” of deliverables without realizing their legal implications. The result was a prolonged dispute that took longer to resolve than the project itself.
The second company involved a lawyer already at the stage of preparing the project specification. As a result, the contract included clear milestones, payments tied to their completion, and a transparent change‑management process. Complications did arise during the project (integration took longer than planned), but thanks to a functioning escalation mechanism and clear rules for handling deviations, the situation was resolved through a contract amendment rather than a lawsuit.
Both projects encountered problems. The difference was whether tools existed to manage them.
In conclusion: We’re happy to help
We have been advising on IT projects for many years – from drafting project specifications and contractual structures, through ongoing support during implementation, to dispute resolution where prevention was no longer enough. Our practical experience shows how to structure contracts so that they serve as a management tool, not just a document forgotten in a “drawer”. If you are planning a new project, preparing to select a supplier, or want to review an existing contractual relationship, we would be happy to meet with you and discuss how we can help.
