Home > Blogs > Contractual Discretion During Software Development

Contractual Discretion During Software Development

Both the developer and customer are under pressure to ensure they get the ideal outcome they want from the software development. This can be achieved but only where the contract is drafted correctly and the parties agree on what risks they can take on from the outset.

Some lawyers view the law of contract as a living and breathing entity cultivated over centuries of caselaw precedents, ever-evolving according to various factors such as political agendas, socio-economic changes, and even global pandemics. Technological developments* are one of those factors, and advancements in the same, specifically vis-à-vis the cloud and the internet at the turn of the 21st century until now, has spurned a new way of thinking for contract lawyers. The same lawyers that must bend black-letter-law to accommodate the new world of binary code. Though technological changes influence how contract law operates, the same can be said in the opposite, and there is an incipient trend of contract law principles bending how technology is implemented and deployed.

*Artificial intelligence is one of those technological developments but, in our view, has not changed the process of a contract lawyer advising on an IT contract. This is because, in our experience, AI development tends to naturally fall under the established methodologies already used by developers in any event. The only way AI may change the contracting process is the addition of additional duties such as in relation to AI safety. However, even this may not be required, since there currently exists no legislative framework for AI regulation in the UK.

Indeed, where one dynamic concept interacts with another dynamic concept, there is bound to be so many complexities that arise. This article will focus on one of those complexities. That is, namely, contractual discretion. The bane of this matter can succinctly be surmised into the following problem question: “how much can software developers and other suppliers of software use their contractual discretion against a customer for their own interests”. In other words, how much can they flex their contractual muscles to avoid breach of contract for not meeting the expectations of the customer in relation to the solution to be deployed. We should hopefully provide practical insights based on the experience of our lawyers on the same. This article should therefore be a good read for software developers, cloud computing experts, and technology lawyers alike.

A brief side note – and perhaps quite a humorous one for tech nerds and enthusiasts – there are some instances where lawyers are tasked with advising on ‘dinosaur’ tech which perhaps contradicts all the preceding bravado about technological development affecting the contractual process. A key example our lawyers have come across is IBM’s AS400 system, which was one of the world’s first database systems for office work, that is still used by some organisations (especially in the public sector) today. Do a contract lawyer’s tricks really have to adapt for a software system that has not changed for decades?  

The tension that contractual discretion creates  

There are generally two competing interests between the developer and the customer that we have seen in relation to the supply of software development services. The developer’s interests are to avoid signing up to a contract that holds it accountable for supplying a solution not exactly meeting a specification or a precise purpose. The customer, meanwhile, has an inherent interest in tying down the developer to providing a solution that is perfectly fit for their organisational and operational needs. Essentially, the developer will want the most room to manoeuvre in terms of ensuring the contract does not explicitly define what the end result of the development will be. If the contract is flexible on this, then the developer can arguably wiggle out of claims that the software is not fit for purpose. Conversely, the customer will want the contract to strictly define how the software will operate when development finishes. The basic logic, therefore, is that the more contractual discretion the developer has, the less likely it is to be on the hook for delivering a solution that is sub-par (that is, at least, to the judgement of the customer).

This inherent tension is then exacerbated by the fact that software development at its heart is a creative process and sometimes an end result can be different than originally envisioned and whether that end result is good for the customer or not cannot entirely be confirmed at the time the parties draft the contract. The counter to this issue has been the creation of different development methodologies, most notably the agile methodology. This iterative methodology, together with an appropriate contractual structure, allows changing requirements to be built into the project (and thus make the developer contractually liable for the same) as development progresses. This is usually achieved via running multiple ‘mini’ projects concurrently, with testing and acceptance occurring multiple times and parts of the solution already ‘live’ (or in beta stage for end-users) before completion.

The customer, under the pretence of the agile methodology, may also insist on the developer enjoying some degree of flexibility in the development process to allow improvements not originally envisioned at the outset to be incorporated as development progresses. Though this might be ostensibly viewed as increasing the developer’s contractual discretion, it may paradoxically narrow the developer’s ‘wiggle room’. This depends entirely on the way the contract is drafted for the elements that allow changing requirements to be codified under the contract as development progresses.

Essentially, therefore, the problem being faced is a tug of war between which party enjoys the most contractual discretion and consequently which party bares the most risk of the development.

What can be done to alleviate the tension

It is our view that software development contracts simply cannot survive being based on a standardised template and that nearly every matter involves some degree of bespoke tailoring. Unless there is a pressing need*, we do not tend to pigeonhole development contracts to fit precisely either the ‘agile’ or ‘waterfall’ methodology, even if the specification annexed to the contract is rigid.

*The pressing need might be whereby both the customer and the developer are absolutely sure that following a pre-determined implementation plan with pre-defined milestones and testing and acceptance criteria is suitable for both their needs. In such situations, the contractual discretion is heavily tipped in favour toward the customer, meaning the developer is at higher risk for breach of contract for not meeting the customer’s requirements. The developer may be happy to take on this risk, depending on the context.

Rather, we see it [software development contracts] as a hybrid arrangement, picking and choosing the best parts of both methodologies so that the developer and customer reach a compromise as to the respective amounts of contractual discretion each will enjoy throughout the development process. In this way, the development process does not devolve into gamesmanship but instead a proper business deal where the disparity between the parties’ bargaining power is narrowed by agreement. Thus, the tug of war is balanced and both parties enter the deal with some similar benefit. This is especially important for longer term projects that have a support element to them.

How can this be achieved practically? One way is to incorporate mechanisms into the contract that build in flexibility yet still retain contractual discretion where it is justified. Essentially, the developer might agree to the customer saying “we are happy to be flexible here, but on X, we want it this way and we are putting it in writing in the contract”. In this way, the developer accepts what elements it may relinquish some of its contractual discretion over and what elements it needs that wiggle room to avoid the customer threatening breach of contract for an under-delivered component (perhaps the components which have an inherent level of subjectivity vis-a-vis their utility). The contract retains the flexibility of the agile process and the certainty of the waterfall process so that both parties can have their cake and eat it.

Of course, this is all predicated on the assumption that both parties can figure out what deliverables and requirements must be set in stone in the contract from the outset and what might be left to be decided as development progresses. This may not always be the case and so other contractual methods should be looked at, such as continuous improvement clauses, change control clauses, dispute resolution clauses, and express duties of good faith. But these are topics for another day.

About the author

Nabiel Junjua (CEO & Solicitor) is a solicitor with extensive experience in contract law, including on drafting and negotiating software development and other IT contracts in the private and public sector. He has an in-depth knowledge and appreciation of the digital world and is able to skillfully utilise contract law principles to ensure his clients acheive the best outcome in their software development goals. Read more about Nabiel here.