Contracts and partners

  • 10th October 2024

Paul Sypko shares the lessons he has learnt from negotiating information and communication technology contracts for independent schools

 

It’s always fascinating to observe the different approaches people take towards contracts for information and communication technology (ICT) services and software; these perspectives reveal a lot about how they envision the relationship between suppliers and customers. Some believe that a meticulously drafted contract is the cornerstone of a successful ICT partnership. Proponents of this view argue that contracts must be clear, comprehensive, and cover all aspects of the services or software to be provided. They expect contractual paperwork to be thorough, complete, and well-drafted, including elements such as the scope of work, deliverables, timelines, costs, payment terms, service levels, and conditions for renewal or termination. Their motto might be “let’s make sure the contract is watertight and robustly protects our interests.”

On the other hand, there are those who consider contracts to be of limited practical value. They believe that a healthy, collaborative, and mutually supportive relationship between supplier and customer is crucial for the success of any ICT project or service. For them, referring back to the written agreement is already a sign of failure. They argue that productive relationships aren’t forged by attempting to cover every possible eventuality in a detailed legal framework – something they consider impractical. Given the inherent complexity of ICT services, which often require ongoing collaboration, they advocate for flexibility and the ability to handle unforeseen challenges together. Their motto might be, “win-win situations are created through strong relationships built on mutual trust and understanding, not by small-print and legalese.”

Aligning expectations

Common to both these of perspectives is the requirement that there is alignment between the expectations of the ICT supplier/partner and the school (as the customer). This would seem reasonable enough: the very essence of an ICT procurement process is that the customer carries out its own due diligence (‘caveat emptor’ – let the buyer beware), explaining its requirements to prospective partners and then understanding how those requirements would be met. From the supplier’s perspective (and here we use the term supplier to refer to any type of technology services provider, software solution vendor or the like), the key is checking that the customer’s expectations can be met within an agreed commercial framework (budget, timeline, etc). Requirement specifications, written proposals, statements of work, service level agreements, service descriptions, project plans and of course costings spreadsheets and the like all help with making sure that both parties are on the same wavelength. But so do solution demonstrations, references, trial periods and, of course, proper communication (whether in the form of meetings, presentations, telephone discussions, emails, video calls or anything else that helps to build up a shared understanding of the requirements and how they will be met).

Effectively, there are key elements at play: first, making sure that both parties have thought things through sufficiently and have done their homework when it comes to co-developing and agreeing the solution to be provided. Then, secondly, making sure that the agreement is understood sufficiently and is documented clearly to prevent any misunderstandings.

Working together

Note the terms co-developing and agreeing the solution in the previous paragraph. It’s worth us expanding on those a little. ICT is more complex than it used to be. If a school knows exactly what it wants and is looking to purchase some commodity items on the most favourable commercial terms achievable (say, something routine like toner cartridges for printers), then it can be a fairly straightforward transaction. But what about where there are many different ways to achieve a particular end objective – perhaps where software is needed to help streamline data flows or business processes and the way in which that software is set up and rolled out makes all the difference, or where digital solutions may need to be designed for a particular purpose but the quality of the end product will rely on the innovation and creativity of the chosen technology partner?

In these circumstances, a good supplier won’t necessarily just take a customer’s requirements and respond to them as specified (and conversely, a good customer will probably focus on communicating the desired end outcomes and objectives rather than being prescriptive about how they are to be achieved). Increasingly, as organisations think about business systems and embed technology in their everyday working (rather than thinking of ICT as being something separate in its own right), there is recognition that, while the customer may be clear about its own objectives, the supplier is in many ways more knowledgeable about the potential range of solutions and the various ways in which the objectives might be best achieved. In effect, when this type of interaction happens, we move away from a transactional type of vendor-customer relationship to more of a trusted partner one. Selecting the right partner is therefore key – get that right, and everything else that follows will be better – regardless of how robust (or otherwise) the supporting contract might be.

A contract tells a story

One of the areas that can be most fascinating about ICT contracts is what they tell you about how a supplier operates, and how events might play out. Often you can spot clauses and terms that have been added or clarified over time, based on the supplier’s past experiences.

Some contracts are intentionally vague, often committing to little more than providing software (if it’s a software solution being bought) as-is, or a certain amount or type of resource on a ‘time and materials’ basis. This of course has implications for who bears the risk of any over-runs, and makes it all the more important that the customer has taken all relevant steps to make sure they’re confident they’ve made the right choice. That’s fine if that’s what the customer is expecting (indeed, some may prefer the flexibility of that type of approach) – but isn’t OK where customers (for instance) are working to a tight budget and know exactly what they want, but haven’t realised that their original brief or specification isn’t part of the agreement.

Some seek to reframe ambiguity in a positive way – for instance, recognising that flexibility of approach will be important and that it will be important to focus on priorities as they emerge, hence leaning towards an agile methodology so as to deliver outcomes in smaller, iterative steps. This suggests a certain expectation around how the customer and supplier will work together, and it’s important therefore that the customer is ready to engage in that way.  This might have implications, for instance, in terms of resourcing; customers may need to assign their own project manager to work closely with the supplier, rather than expecting the supplier to deliver the solution as per spec and with any customer interaction kept to the minimum level necessary.

Some contracts set out unrealistically brisk turnaround times for acceptance testing, others neglect to set out what happens in the event of the agreement being cancelled (for instance, is the supplier obliged at that point to cooperate as you migrate to your next solution?). Some make cancellation difficult (for example, ownership of intellectual property for custom modifications to a third-party platform might reside with the supplier, limiting the customer’s ability to have another supplier support the solution), others set out a procedure to enable the supplier to ‘put things right’ but don’t try to retain unhappy customers by reference to legal small print and ultimately allow them to give a short period of notice at any time if they’re not happy. All of these clauses give you clues as to how the supplier is likely to approach working with you.

These are just a few examples, of course, but it’s always interesting to compare and contrast the terms proposed by different ICT suppliers/partners. The differences can be quite revealing in what they tell you about how the different companies engage with their customers. Increasingly, it’s often also the case that suppliers are much more reluctant to customise their draft contracts/agreements than they used to be. Often this means scanning them for any potential deal breaker and/or points to note before signing on the dotted line rather than expecting to be able to renegotiate every contentious detail.

So, what to do?

There’s no one-size-fits-all approach to setting up an ICT agreement with a supplier. Contractual models, approaches, templates and frameworks can differ wildly. While it’s important to ensure that a school’s interests are protected, there’s always an element of risk appetite on both sides. Thorough procurement processes, due diligence (such as taking up references), and breaking work into well-defined stages (such as starting with a discovery stage) can help mitigate risks. Ultimately, however, ICT services and projects are complex and can be challenging. A well-drafted contract might help to reduce risk, but choosing the right partner (one whose values and approach aligns with your own) and making sure expectations are aligned might mean that you don’t even need to refer to the contract if the going gets tough.

Paul Sypko is a partner at technology management consultancy Adapta Consulting

Paul Sypko

Keep Updated

Sign up to our weekly newsletter to receive the latest news.