Customers in long-term technology projects can find that while they have been working towards their chosen solution, a more advanced, cheaper, or simply more desirable technology has become available. The benefits of switching solutions may be very significant, but exiting an existing agreement can be costly and complex, both legally and commercially.

The situation frequently occurs in software development projects. Bespoke software development projects are frequently overtaken by the release of software packages or cloud solutions which can offer substantially all or most of the requirements that were being covered in the software development process. At that point, the customer faces a dilemma as to whether to carry on with the software development project or to switch to an alternative solution. There are distinct pressures to move to software packages or cloud solutions, including the fact that support, maintenance and the upgrade of a software package or a cloud solution is shared between the user base, with reduced costs, rather than being the responsibility of a single user.

Since delays in technology projects are frequent and technological advancement shows no signs of slowing down, in this series of articles we look at what customers and suppliers can do to mitigate the risks posed by technological advancement. Our series covers:

  1. This article: steps that can be taken at the contracting stage;
  2. Steps that can be taken during the project, and when it becomes apparent that a change of technology and/or supplier will be sought; and
  3. Contract re-set and dispute resolution.
The contracting stage

Due Diligence: Customers should – obviously – undertake due diligence on what is available in the market, including the solution they are buying, its suitability and alternatives that are (or may become) available. It is also important to establish the likely timescales for implementation, particularly if it appears that alternatives are likely to shortly come to market. That said, in some circumstances – such as where it is critically urgent to obtain a new or interim solution, or if a highly bespoke solution is being commissioned – it may be difficult to do very much horizon gazing; and depending on the industry and speed of change, the parties will need to recognise that any significant delay could render the solution increasingly unattractive or redundant. In addition, even the most efficient due diligence may not flag up solutions that are some months or years off, especially if the project is anticipated to be a short one.

The situation is particularly relevant in the public sector. It is relatively common for public sector users to regard their requirements as being unique or special to the public sector and so a software development process is necessary when, in reality, there are existing software solutions that can satisfy most requirements. There is also a tendency for the public sector to “over-engineer” the requirements instead of the software provider developing an initial “bare bones” or minimal viable solution that can be further developed over time. The public procurement rules also exacerbate this problem by putting pressure on the public sector to identify everything that they might possibly want in a solution at the start of the project.

Preventing Delays: The risk of a delay prolonging the project to a point where the original solution no longer makes sense, or is not cost effective to implement because it will rapidly be superseded, is a real one. Of course, the best approach is to try to prevent delays from happening and introducing effective contractual mechanisms to prevent delays can significantly improve the chances of successfully doing so. Keeping the customer’s requirements simple and limited in scope is key for rapid and predictable delivery. Other mechanisms include financial incentives for rapid delivery, robust governance structures to manage the implementation of the project (including mandatory change control obligations), and close control of delivery and acceptance criteria tied to supplier payments.

Milestone payments linked to key project deliverables, rather than time-based payments, incentivise and focus the supplier to deliver on time and to meet the acceptance criteria. That being said, project delivery, particularly for IT solutions, requires flexibility as well as firm management. For software development projects the customer needs to recognise that 100% achievement is unlikely in the initial development process. Assessing what is essential and what can be left for later deliveries should be a key part of the skill set of customer-side project managers. Holding the supplier’s “feet to the fire” is rarely a recipe for success in IT project delivery. One particularly successful customer side IT Director is reputed to have claimed that he never had a project that did not deliver to time and cost – but he did accept that the time and cost he referred to were not those set out in the original contract.
Where the parties find themselves in dispute this can also cause significant delays and appropriate dispute resolution mechanisms can help to mitigate this risk. We address this separately in a later article in this series.

Agile vs Waterfall: The structure of the project can also potentially help to minimise the risk of it being overtaken by new technologies. “Agile” development methodology allows for delivery of elements of the solution in “sprints”, giving the project teams a degree of flexibility as to what is built and when that does not generally exist using the traditional “waterfall” approach. Such flexibility may allow the introduction – or at least the consideration – of newer technologies as part of the overall project solution.

The management of Agile projects under supplier-customer contracts is a particular challenge. Agile probably works best outside contract structures where there is clear management control and in circumstances where there is flexibility to make decisions and changes during the lifetime of a project. There is an inherent inconsistency between the flexibility and dynamism of the Agile development methodology and the certainties and inflexibilities of a contracting process. The use of Agile in a supplier-customer relationship also requires significant and high-level stakeholder input from the customer to make real-time decisions on the development of the project throughout its lifecycle. This is a significant commitment, as compared to a traditional “waterfall” contract development approach where the customer can have relatively little involvement during the project lifecycle, other than to test deliverables against acceptance criteria as they are delivered under the contract.

Notwithstanding that Agile is not a panacea for all projects development problems, Agile can be successful and can be preferable to the more traditional approaches. At the very least, the possibility of using Agile should always be considered as part of the contract negotiation process.

Long Builds: If the project timetable is inherently long rather than delayed, it is sensible to include stocktakes during the development lifecycle so that the parties can review progress – ideally in a neutral environment, rather than in the context of a dispute – to see if the contracted-for development approach continues to be the best approach for the parties. As this is often closely bound together with disputes that have arisen between the parties, we look at this separately in the third article in this series.

Support and Maintenance: Supplier “lock-in” is a key concern for customers, particularly where the development has been a bespoke software development process. Once solutions are handed over to support and maintenance teams there is an inevitable financial incentive on the supplier to do as little as possible in return for the on-going support fees. Contract mechanisms can be included to counteract this dynamic, but their impact tends to be limited. Continuous improvement obligations and benchmarking provisions, potentially tied to price alteration provisions, may help the customer to ensure that the solution remains up-to-date and value for money is retained for the contracted system. It may also allow the customer to request the implementation of improvements in technology after the system has gone live.

Funding “pools” identified in the contract for the making of enhancements can provide a measure of protection for the customer that the solution will not lag behind market developments, but more strict requirements for the supplier to identify a specific number of solution developments and upgrades per year rarely work in practice.

It is also worth bearing in mind that is not always the customer which wishes to move on to newer technology. Suppliers may find that in the context of a project which ties them to a lengthy subsequent support and maintenance period, they are bound in to providing support and maintenance for an older product (particularly software) that they no longer wish to patch or upgrade on a regular basis. It may be in both parties’ interests to agree contractually how this will be addressed. This is not a straightforward issue to resolve, albeit some certainty may be achieved by agreeing committed maintenance periods so that the customer knows after what period it can expect an upgrade to occur.

For software development projects serious consideration should be given to making the developed code open source. One of the key consequences of open source software developments is that developments, upgrades and improvements can then be made by anyone, rather than solely the original software developer. This can provide real resilience to a support and development environment.

Sub-Contracting: The supplier should ensure that any sub-contract it enters into is properly “back-to-back” with the main contract. If it is not and the customer terminates the main agreement to move on to newer technology, there is a risk that the supplier might be left with financial exposure to both its customer and its sub-contractor. In particular, the supplier should ensure that it is entitled to terminate its sub-contracts (or that they automatically terminate) in the event that the customer walks away. It is also helpful from the supplier’s perspective to ensure that dispute resolution provisions in each of the main contract and sub-contract closely match, and if possible that they allow disputes to be resolved between all parties in a single forum. The supplier can otherwise find itself dealing with two separate disputes, with an attendant time and costs burden.