Successfully managing IT projects – keeping an eye on project dependencies
IT projects are complex – project dependencies and processes must always be considered in the framework of the overall context.
Almost every company implements IT projects – sometimes smaller ones, sometimes larger ones – with a certain degree of regularity. As soon as these projects go beyond purchasing standard software available on the market, these regularly entail a level of complexity that companies would be wise not to underestimate. For both the principal and the contractor, this complexity primarily results from the multitude of dependencies. These dependencies must be taken into account both in the context of the immediate implementation of the project itself (i.e. on the way from project start to project completion) and beyond (i.e. in the run-up to project start and when using the project result after project completion). The dependencies can be technical and commercial as well as legal in their nature.
Technical dependencies
Experience shows that purely technical dependencies are easily recognised by many companies and correctly assessed by the specialist departments. These relate, in particular, to the question of which options are even technically feasible with regard to achieving the objective pursued by the IT project. In this respect, dependencies with regard to software and hardware already used by the company must be taken into account. Questions include, for example, "Which software can actually run on the company servers or the employees' PCs?", "Is the new software compatible with the existing software landscape?" or "Can the software cope with the workload that is to be expected?" The aim here is to identify and specify interfaces. Companies should also pay close attention to the compatibility between different data formats.
Organisational dependencies
Dependencies also arise from the actual course of the project: for technical reasons, IT projects are subdivided into a large number of work steps or project phases. These are processed step by step or in parallel in various workstreams and often distributed across many people. It is crucial for the parties to gain a comprehensive understanding of the planned project process during the contractual negotiations. This also includes anticipating where deviations or delays are to be expected:
IT projects are usually carried out in several phases. An IT project often consists, at a minimum, of a planning phase, a development phase, a test phase and an implementation phase. Sometimes use of the project result in the sense of an operational or productive phase is still regarded as part of the project. As a general rule, none of these phases can begin until the previous one has been completed. An objective and comprehensive evaluation of the project is the prerequisite for setting realistic project timelines. Such an evaluation also identifies risks that can lead to delays in individual project phases and therefore of the overall project.
Interplay of services and cooperation obligations
Very few projects are completed once the contractor has provided a service and the principal has, in return, paid the remuneration. It is often necessary for the principal or third parties commissioned by the principal to provide extensive assistance in order for the project to be successfully implemented at all. For example, the principal must grant the contractor certain access rights to the existing system into which the project result is to be integrated. Or existing data must be converted into a different format so that the data from the existing system can continue to be used in the new solution that will result from the project. Extensive testing is also often required to approve interim results so that the contractor can proceed with further work on this basis.
This interplay between services by both sides means that projects are often also resource-intensive for the principal. This requires not only looking at the service provider's capabilities, but also taking an introspective look at the principals own organization: To what extent will the IT system landscape change as a result of implementing the project? Is the new system technically compatible with all required interfaces? Will certain systems have to run in parallel for a transitional period? Are the IT department and, if necessary, other specialist departments sufficiently well positioned in terms of personnel and expertise to continue to handle day-to-day operations and still participate in the project to the extent required?
A technically and commercially viable agreement can only be reached on the basis of realistic planning and a comprehensive understanding of the required project services and their dependencies. This agreement must, of course, stand on a solid contractual basis. This contractual basis serves to record the common understanding in a legally binding manner and to clearly document the expectations and obligations of both sides.
The IT project and legal framework conditions
However, dependencies do not only play a role on a commercial or technical level. They are also relevant from a legal perspective. IT projects, in particular, often involve a colourful bouquet of legal aspects that have a considerable impact on the project. On closer inspection, many topics that at first glance appear to be purely technical in nature also need to be considered from a legal perspective. Only if companies take sufficient account of the interplay between the various legal framework conditions can the project be reliably led to success:
Traditionally, many IT projects initially throw up employment law issues: for example, it is often not only the procurement department and the IT department that have a say in whether new software should be introduced out of technical necessity. Rather, implementation of the project may also be dependent on the consent of the works council.
Principals do not always have sufficient staff to implement larger IT projects over a longer period of time. It is therefore established practice to call in external experts for such projects. Whether and subject to which conditions deployment of external staff for such a project is possible in the individual case depends on the specific circumstances. This requires a competent assessment of the legal situation in order to avoid issues such as unauthorised temporary employment or de facto employment.
If an IT project is implemented within a group and services are provided between individual group companies (e.g. if the US parent company provides the servers on which the IT specialists of an Irish subsidiary implement the new software for use by the German subsidiary), economic and tax law expertise is required. The topic of transfer pricing is particularly relevant here.
Many technical decisions also have legal consequences: if personal data is processed in an IT-system (e.g. in connection with payroll accounting or hosting the company's HR data), the decision between an on-premise solution and a cloud system is not just a technical matter. As soon as the controller uses a third party to process data, whether by outsourcing personal data to the cloud or by having the entire process carried out by an external service provider, data protection regulations must be observed, first and foremost the General Data Protection Regulation (GDPR). The feasibility of such a project then depends, among other things, on where the future data processing is to take place, what technical and organisational measures the service provider has implemented to protect personal data or what type of data specifically is being processed.
If the system to be implemented with the project offers so called "information society services", European platform regulation requirements may become relevant: at the beginning of 2024, significant changes to platform regulation came into force at both European and Member State level. These can have a considerable influence on the design of websites, online shops or other products and services offered online. The design of a corresponding project and the choice of service provider or specific product will also depend on whether (and if so, how) it can be ensured that the principal complies with the regulatory requirements.
Particularly in the case of projects with international dimensions, issues such as export control law and sanction law must also be taken into account as well as the requirements of the German Supply Chain Due Diligence Act (LkSG). Can a supplier deliver its software to the targeted third countries from an export control perspective? Can a customer purchase software or services from the region in which the provider is registered or provides its services? When commissioning the supplier, can the customer ensure compliance with its human rights and environmental due diligence obligations within the meaning of the LkSG? Companies that violate the relevant provisions are subject to various serious sanctions. In addition to severe fines, the company could be excluded from being awarded public contracts and its executives may even face criminal liability.
Self-imposed dependencies – contractual obligations
In addition to the aforementioned statutory law aspects, contractual aspects must also be taken into account. Normally, a company has contractual dependencies on various third parties, all of which can have an impact on the planned project.
In relation to the company's suppliers and service providers, first and foremost exclusivity agreements that completely prohibit the purchase of a system from another supplier or at least entail commercially relevant consequences (e.g. penalties or higher prices) need to be considered. Mirroring this, exclusivity agreements restricting the provider are, of course, also conceivable. They may prevent the provider from providing the required project service to the principal of the IT project (for example because it has undertaken to provide this service only to one specific other customer).
However, there are often also contractual dependencies in relation to the customers of the company that wants to implement the IT project. If, for example, the company has agreed with a customer to use a certain software for the provision of services to them, this software cannot simply be replaced. Either an amendment of the respective customer agreement will be required or it will be necessary to continue operating the old software in parallel to the new system for this customer (for the remaining term of the respective customer agreement).
If a system is not only to be supplemented, but also partially or completely replaced by another, it is necessary to analyse in good time what support is required from the incumbent provider and to what extent the incumbent provider is contractually required to provide this support.
Addressing dependencies – creating clarity and solving problems
The diverse dependencies pose challenges for providers and customers alike. Although these are rarely actual deal-breakers, expert advice on these matters is required in order to ensure that risks are recognised, assessed and, if necessary, mitigated. The prerequisite for overcoming these challenges is thorough planning of the IT project. IT projects do not exist in isolation in a vacuum; their success depends on a series of internal and external factors. In view of this, it is crucial to keep an eye on these factors, to identify the relevant dependencies and to regulate them comprehensively and transparently in the respective agreements.
You can find out more about this in our blog series on IT projects (in German). You can subscribe to this blog series via the RSS feed to be informed about new posts.
