Technology procurement – what you need to know

By Kathryn Rogers, above, Partner, Cripps

In today’s world, it is hard to imagine a business that doesn’t use technology. However – it can be complicated to know what you need and the process of technology procurement can also be a headache. So for any SME looking to start a software development project and unsure how to run the procurement process – where do you start, and what do you need to be aware of?

A recent court case showed how failure to create a structure for a proposed software development project can be the difference between a successful procurement exercise and one that ends in expensive and time-consuming litigation – so it’s important to get right! A number of important lessons can be learned from this case.

At the start of any procurement exercise, it’s important to take time to properly consider the most suitable structure for your proposed software development project, and setting this out in a clear and detailed legal framework prior to commencement. The recent high court case of Topalsson GmbH (Topalsson) v Rolls-Royce Motor Cars Ltd (RRMC) is a useful illustration of what can go wrong with this aspect of contracts for software and IT procurement.

In this case, RRMC entered into a contract with Topalsson in 2019 for the supply of software which allowed online customers to configure and customise cars by providing users with a digital “twin” – a true-to-life representation of the final product. RRMC wanted Topalsson’s software to coincide with the launch of a new car model in early 2020. But there were delays with the project, and by April 2020, RRMC terminated the contract, with Topalsson issuing proceedings later that year.

The case aired a number of areas of disagreement between the parties, which might be familiar to others who have gone through a similar process, including whether:

  • certain critical contractual terms were sufficiently defined to be binding;
  • commitments contained in ‘technical’ documents such as implementation plans and timelines were legally enforceable; and
  • the most appropriate delivery method had been the utilised (had the choice to go with waterfall over agile in the contract caused or contributed to the delays?).

This last question was a key point of contention between the parties throughout the project.

So what’s Waterfall and Agile and why do they matter in these sorts of arrangements?

Waterfall and agile are two of the most popular methods for organising software project delivery.

  • Waterfall is more lineal and sequential, and therefore ‘traditional’; the overall project is divided into phases, and each phase must be completed in turn before moving onto the next. Waterfall approaches are usually considered better suited to projects which have clear timescales and confirmed deliverables.
  • Agile development, on the other hand, is thought of as more appropriate for the development of new products, where the exact scope of the project is not fully established (and not necessarily understood). The agile method is more flexible, and allows for the different phases of the project to be worked on simultaneously whilst also adapting to changes, developments or feedback which occur during the project’s lifecycle.
  • Hybrid approaches are possible where both methods are combined, and in this, case there were elements of agile development alongside waterfall structuring.

In this case,  full upfront discussion of the relative merits of the different approaches and getting agreement from both sides for the best choice for this project may have led to a better outcome on both sides.

Key take-aways

This case illustrates three important points:

  • how choice of development methodology can materially influence the success of the project, showing how important it is to get this right;
  • consistency and clarity in drafting all the documents relating to the contract, even the “technical” ones such as timelines, technical specifications and statements of work is crucial. These documents are often dealt with by the tech rather than legal teams, but legal oversight is still key so that the contract hangs together as a whole; and
  • tight and legally binding definitions for key concepts such as delivery and acceptance are critical

Embarking on any type of software project can be time-consuming and complex, but working with an expert at the outset to ensure you find the right legal framework for your project is vital. Additionally, clearly setting out the terms of your agreement will give you the best chance of getting an enforceable agreement with successful delivery of a product that meets your procurement needs and objectives.