Published on September 1, 2026<\/p>\n<\/div>
The more precisely a contract defines the future, the more secure we feel.<\/p>\n
This idea sounds reasonable. However, I consider it a dangerous misconception when it comes to long-term IT contracts.<\/p>\n
Because an IT contract can be legally precise, economically excellently negotiated, and technically thought through down to the last detail \u2013 and yet still no longer fit what the company needs after just a few years.<\/p>\n
The problem is not a lack of care. The problem is change.<\/b><\/p>\n
Many IT service contracts run for three, five years or longer. During this time, technologies, business models, and requirements change. Therefore, I believe it is wrong to structure a long-term IT contract as if these developments could be foreseen at the time of signing.<\/p>\n<\/div>
The better question is:<\/p>\n
How do we conclude a precise contract about a future we don't yet know?<\/b><\/p>\n<\/div> For me, that is precisely where the real art of a good IT contract lies.<\/p>\n Of course, services, responsibilities, quality, safety, liability, and prices must be clearly defined. Flexibility should never be another word for ambiguity.<\/p>\n But a good contract must also clearly define how change works.<\/p>\n What happens when quantities change? When services are no longer needed? When a new technology replaces an existing service? When the costs of providing a service fundamentally change?<\/p>\n A contract that doesn't provide a reasonable answer to this may look perfect at the moment it's signed \u2013 and later become an obstacle.<\/p>\n<\/div><\/div><\/div> That is precisely why one of the guiding principles of our Efficient IT Sourcing is:<\/p>\n Good response to change prior to planning and measurement.<\/b><\/p>\n This does not mean planning less or measuring less. It means incorporating change into the contract's design from the very beginning.<\/p>\n<\/div> The same applies to performance measurement.<\/p>\n Many IT contracts contain numerous Service Level Agreements (SLAs), which are measurable specifications for the quality of IT services: availability, response times, ticket durations, or system performance.<\/p>\n The provider can meet all these requirements \u2013 and yet the expected benefit for the company fails to materialize.<\/p>\n A green SLA initially only indicates that the agreed-upon technical performance has been delivered. It says nothing about whether the business objectives will also be achieved.<\/p>\n<\/div> Business KPIs before technical measurement.<\/b><\/p>\n<\/div> Of course, I want to know if a system is available. But even more important to me is whether the business process it supports works.<\/p>\n Formally, I want to know if tickets are closed quickly. Ultimately, however, what matters is whether employees can work productively.<\/p>\n The performance of an IT service provider should therefore not only be measured by what it delivers technically, but also by the value that this service generates for the company.<\/b><\/p>\n<\/div><\/div><\/div> In IT negotiations, a lot of energy is spent comparing and optimizing individual prices. This is important \u2013 but it doesn't go far enough.<\/p>\n Because a contract that seems cheap at first glance can become expensive if every adjustment triggers a change request, services that are no longer needed cannot be reduced, technological efficiency gains do not reach the customer economically, or switching providers is hardly possible anymore.<\/p>\n Therefore, a good price benchmark is not enough for me when it comes to long-term IT contracts.<\/p>\n I am interested in the total costs \u2013 and the economic flexibility over the entire contract period.<\/p>\n<\/div> This is also part of our Efficient IT Sourcing approach: We have seen firsthand that these principles are not just theoretical, for example at \u201cpbb Deutsche Pfandbriefbank\u201d.<\/p>\n There, we managed the operational and strategic aspects of an IT outsourcing project with a contract volume of more than 120 million euros, applying the concept of efficient IT contracts.<\/p>\n In negotiations with large IT service providers \u2013 including those specializing in mainframes, servers, network administration, and end-user data processing \u2013 a key contractual feature was to measure performance based on the value generated for the company. The cost reduction achieved in this project amounted to approximately \u20ac10 million.<\/p>\n For me, this contains a key idea: So what does the perfect IT contract look like?<\/p>\n From my perspective, it doesn't exist. We neither need nor can we know today which technologies and requirements will be relevant in five years. Therefore, three things are crucial for me in long-term IT contracts:<\/p>\n This is more challenging than simply stipulating as many eventualities as possible on as many pages of a contract as possible. Therefore, before the next major IT negotiation, I would like to add an additional question to the agenda: If the answer to that is: "Then we have to renegotiate," that would be insufficient for me \u2013 that would be a warning sign. A good IT contract therefore doesn't regulate everything. It enables change.<\/b><\/p>\n<\/div> \ud83d\udc49<\/b> <\/b>More on this topic: \u2192 Efficient IT sourcing at Emarticon<\/a>What must be fixed \u2013 and what must remain changeable?<\/h3><\/div><\/div><\/div>
![](\"https:\/\/emarticon.de\/wp-content\/uploads\/10-Impuls-Foto.png\")
<\/span>A good SLA can still lead to a bad result<\/h3><\/div>
\n<\/b><\/div>\nWhat matters is not just the prices, but the cost of the change.<\/h3><\/div>
\nTotal costs before price benchmarking.<\/b><\/p>\n<\/div>How this has proven itself in practice<\/h3><\/div>
\nAn intelligent IT contract doesn't simply purchase as much service as possible at the lowest possible unit prices. It ensures that the economically appropriate level of service remains controllable.<\/b><\/p>\n<\/div><\/div><\/div>A good contract doesn't need a crystal ball.<\/h3><\/div>
\nBut we need to decide today how we will deal with it if they change.<\/p>\n\n
\nBut it reflects reality.<\/p>\n
\nWhat happens to this contract if our assumptions from today are no longer correct in one, two, or three years?<\/b><\/p>\n
\nA modern IT contract doesn't need a crystal ball. It needs clear rules for change.<\/p>\n<\/div>
\nRead how Emarticon helps companies negotiate IT contracts and anticipate future change needs as early as the contract signing stage:<\/p>\n
\n\u2192 Strategic contract management at Emarticon<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div>