Today, every company uses software to offer services or to digitalize its own workflows and processes. Standard software is frequently used for these purposes. Often, however, companies find themselves wanting to use “tailored” software solutions. Such tailored solutions can also be purchased from suppliers, either in the form of adaptations to standard software or in the form of an individually developed solution.
So, a software project needs to be organized – and that is where the questions begin.
While such projects are, of course, an everyday part of an IT service provider’s activities, many SMEs find themselves confronted with these questions for the first time. This could involve the managing director or project manager on the client side but also the in-house lawyer, who will, at the start of the project, (hopefully) at least have written offers to look at, which should be signed for the creation of the software solution. Further documents, such as detailed descriptions of the individual software solution and comprehensive contractual documents, usually do not exist.
How are software projects executed in practice today?
Today, software development is approached quite differently to how it was a few years ago. In the past, software projects followed an approach known as the classical waterfall model. In that model, software development was broadly divided into at least two phases: first, planning and conception, then the actual programming. Contracts could be drawn up prior to the start of the project in which everything would be set down in writing. In theory, this approach offers a considerable degree of security for the client, since such agreements, as contracts for deliverables (Werkvertrag), largely transferred the responsibility for success to the software developer. In practice, however, the consequence was also that many software projects failed. This is because with the waterfall model one first had to draw up a specification sheet, thus increasing costs and delaying the start of the project. In addition, the classic division of the software project into the planning and realization phases was usually not followed. As a result, programming was started immediately, meaning that open issues remained both in terms of the contractual basis and the content of the software to be developed. If the software did not then meet the client’s expectations, this often sparked disputes regarding payment of the purchase price and the costs for making any changes.
Today, most software developments seem to follow the agile approach. Software development is carried out iteratively and incrementally by self-organized teams. There is a conscious decision to forgo comprehensive planning and documentation (specification sheet, user/development documentation, contractual agreement) in favor of producing operational software as quickly as possible which as closely as possible meets the user requirements. In this way, the agile approach is intended to increase transparency and flexibility for all parties. A further aspect of agile development is that it requires frequent (often daily), intensive and collaborative input from the client. Examples of agile project methods include SCRUM, Extreme Programming (XP) or Kanban.
For in-house lawyers, however, agile software projects present various challenges when it comes to maximising the legal protection of their company’s interests. Sometimes there is also little understanding from IT service providers and even in-house IT project managers – for whom the agile methodology has become second nature –for the concerns and requirements of the lawyers.
What challenges does this pose for lawyers dealing with such projects?
Firstly, the legal department is often up against the usual difficulties with project managers in its own company, who frequently consider the benefits of involving in-house lawyers only at a late stage. A lack of communication between all people involved in the project is a further factor which commonly leads to software projects failing. This can be solved by using an agile method if it is well implemented in the project and consistently applied.
In practice, IT service providers are then often of the opinion that agile approaches and a comprehensive contractual agreement are mutually exclusive. From a legal perspective, however, even agile projects can and should be contractually underpinned. Perhaps the greatest challenge, therefore, is to generate acceptance for the desire for contractual security in the first place and to clarify the manner in which this can be achieved within an agile approach. Many questions arise from this: How can I provide for the necessary flexibility (for example early termination options, modifications to the programming and no minimum order quantities) on the one hand, while on the other establishing and implementing clear content-related and timescale-related provisions? This quickly becomes an economic (price) issue. One should not, however, be deterred by the assertion that there can be no such thing as an agile fixed price. These discussions are also frequently linked to the question as to the type of contract for the agile project agreement. Of primary importance in our opinion is not to find the type of legal contract but to find a type of project that works and takes into account the interests of the client company. So who bears the (legal) risk for the success of the project? Should an inspection and acceptance process be agreed and if so against “what”, i.e. against what performance specifications can and should the acceptance be measured? And: which documents are even included in the specific projects? All these open issues should be clarified by the in-house lawyer responsible.
How can lawyers best meet these challenges?
Firstly, there is the option of continuing to carry out software projects according to the classical waterfall model or to choose a hybrid model following the framework of the waterfall model but with individual implementations on an agile basis. The question as to whether a project should be undertaken according to the waterfall model or the agile approach is, as set out above, not a question to be answered from a purely legal standpoint. It only makes sense to use an agile approach if the contracted party is very well-versed in agile methods and if there is trust and good communication within the team.
If one then opts for the agile approach, there is, as so often in legal practice, no “one size fits all” blueprint. There are, however, a few basic approaches which have proven themselves when dealing with agile software projects.
In our opinion, the most important thing is to establish processes for carrying out these projects which can ensure, if possible even before the project begins, that all involved are “fully on board” and that their sometimes differing interests are taken into account. In our experience, these software projects can only be successful when project managers and developers in the client’s own company and at the contracted service provider, as well as the lawyers involved, are all on the same page and are familiar with the agile approach. To this end, it is necessary to develop and discuss approaches together with all participants at project manager, developer and legal department level. Then, it is worthwhile training all parties involved on the features of agile software projects and on the associated methods and processes decided upon in the company. This standardization of processes enables new agile software projects to start without delay and means that all participants are fully informed, namely: who is responsible for what and when, what information has to be compiled and with whom it has to be shared and discussed.
Companies that are regularly involved in software development on the client side or who want to implement digital solutions more frequently in the future should also develop a largely standardized contract template that can then be used in all projects. Naturally such a contract template does not lead to a situation where specific performance-related provisions for a specific project are established beforehand. These remain a matter for the respective software project and the development in the scope of the agile approach.
All legal agreements, as well as the abstract description of the project steps and the roles to be allocated (along with the corresponding responsibilities) can, however, be set out and standardized beforehand. In the case of an agile approach, therefore, the heart of any contractual arrangement should always be to agree with the service provider on the actual project steps (including any acceptance process, change procedures and escalation processes). This includes a binding and specific description of the agile approach and the individual roles in the software project, along with their responsibilities on the client and contractor side. As there is, unlike in the waterfall model, no planning phase to create a specification sheet, the performance description is also “agile”, meaning it is developed and fleshed out and priorities are defined during the course of the project. In light of this, there should always be a clear separation between performance-related requirements on the software and legal (framework) agreements.
A standardized contractual basis also enables all those involved within the company to adjust to the respective provisions and strengthens the company’s position when negotiating with IT service providers. This also helps avoid protracted contractual negotiations at the start of the project, which in practice frequently lead to there being no contractually agreed basis for agile projects at all. Depending on the arrangement of the client/contractor relationship, there is also the option to conclude an appropriate framework agreement and to specify the precise performance-related details of the respective project in the scope of individual orders or requests.
This is when an agile software project can really be successful for both sides.
Practical tips:
- Request proof that the contractor has experience with the agile approach.
- Build a strong team of people you can trust.
- Analyze the economic framework conditions as early as possible (fixed price, budget, distribution of risk).
- Analyze the technical framework conditions (which methods exactly?, tools)
Get all parties together around the table for the contract negotiations.
