Technology procurement

• Ensure that you have clearly identified what your business needs and constraints are
• Identify potential vendors and products which may be suitable for your needs.
• If the software you need will be business critical or won’t be “off-the-shelf” consider engaging a specialist consultant to help you understand what you need and what is out there.

• Carry out company checks, financial checks and look at product reviews.
• Speak to other customers who have used the vendor / product to understand their experiences.
• Consider cyber security risks. This may involve: checking whether the vendor holds any certifications; performing penetration testing; carrying out site visits to assess physical security; and requiring the vendor to complete a security questionnaire.
• If you are buying a bespoke software, ensure you understand the vendors development process.
• Ensure you ask potential vendors for details of their insurance cover.
• If it is a big project you may wish to consider a tender type process.

• Acknowledgement, response and fix – the three core elements to a support contract. You want the supplier to acknowledge your support request quickly, provide a full response so you understand what they are doing to fix the issue and, most importantly, you want them to fix the problem.
• Fix or target resolution – As a customer, you will ideally want a guaranteed fix time for any reported faults.
• SLAs – The contract should clearly define timescales for all of the supplier’s actions.
• First line / Second line / Third line support – Increasingly, businesses have their own in house IT support teams. This means that they may only require support from suppliers for more complex problems. The expressions first line, second line and third line support have been coined to explain the difference between these levels of support.
• Global users – If you have offices outside of the UK, another important factor may be whether the support and maintenance services are available in other languages to ensure that your user base is adequately supported.
• Exclusions – Support and maintenance contracts often contain a long list of exclusions. As a customer it will be important for you to review those exclusions and consider whether they are reasonable.
• New releases, versions and upgrades – In addition to dealing with error resolution, support and maintenance contracts should also address issues connected with changes to the SaaS application or the supported software.
• Duration and renewal – It is important for both the customer and the supplier that there is no uncertainty in relation to the extent of the obligations on each party. The duration of the contract will be important to both parties.
• Termination and escrow – Trigger events for termination should be clearly defined in the contract and it should be considered whether failure to maintain software in accordance with the maintenance contract could potentially trigger the release from escrow of source code to the software.

Whether you are procuring an on-premise product or a SaaS application, software procurement is often expensive, time consuming and involves disruption to your business.

Because of this, it is important that once you’ve procured a piece of software, you’re able to continue using it with as few problems as possible. This makes managing the performance of your suppliers (whether software suppliers, hosting suppliers or support and maintenance suppliers) an important part of the procurement process.

Ongoing performance management often includes review meetings between the supplier and the customer, performance reports issued against defined service levels (SLAs) and key performance indicators (KPIs) and third party input, such as user satisfaction surveys.

• Tender and request for proposal – A tender or ‘request for proposal’ (RFP) is a commonly used document in the procurement process. It is designed to help you provide the same information to suppliers and to evaluate their proposal for providing the software you need on a “like for like” basis.
• Trials – Unless you are an experienced software procurer (or you have engaged the services of a consultant for your procurement project) you are unlikely to be completely certain on your software requirements. If you are seeking off-the-shelf software, some suppliers may make available a trial version of that software.
• Proof of concept – If you are looking to procure bespoke software, you will not have the option of a trial. To mitigate the risk of selecting software which does not meet your requirements, you can engage with potential suppliers on the software’s “proof of concept”. This involves you putting forward an assumption about the problem that the software is designed to solve and the supplier testing that it is able to offer a solution in practice.
• Testing and acceptance – Assuming that you have selected a software solution, your agreement with the supplier will need to provide for the software to be suitably tested before you can accept it. The nature of software testing will depend on the method which is used to develop that software.
• Go-live and dealing with subsequent issues – Once the software has been developed, tested and accepted you will be ready to use it in a live environment. Your agreement must cover the co-operation needed from the supplier at this crucial stage, for example in the implementing the software into your wider systems and if applicable, providing manuals and training staff on the proper use of the software.

Companies procuring business critical software which can’t be easily replaced may rely heavily on their chosen software developer to ensure they are able to continue using that software. If the software developer becomes insolvent or breaches their support and maintenance contract, the customer could be left with an unsupported system that they can’t change or update without significant cost and/or disruption. Having access to the software’s source code, via an escrow arrangement, can enable customers to support themselves in using the software in these circumstances.

An escrow arrangement consists of a three-party contract between a software development company (being the licensor of the software), the customer (being the licensee of the software), and a third party escrow agent. An escrow arrangement enables the licensee to access the software source code in the event that the development company is no longer able (for example, due to insolvency) or willing (and as a result in breach of its support and maintenance contract with the customer) to modify and / or support the software.

Software developers typically regard software source code as the “crown jewels” of their business, so they only provide the software to the customer in object code format and retain the source code themselves. This is usually a satisfactory arrangement for both parties if the software developer continues to provide future modifications, maintenance and error correction under the terms of a software support and maintenance contract.

The purpose of an escrow arrangement is to resolve the conflict between the development company’s desire to keep its source code confidential and the customer’s desire to be able to continuously support and update the software in the future. By having access to the source code, the customer is able to support and modify the software itself without the involvement of the development company (although see the commentary below on the limitations of escrow arrangements).

Bespoke software is an individually made piece of software. The term “bespoke” is however often used to describe customisation of existing products. You should confirm whether your solution is truly bespoke, and to what extent it incorporates existing programs and libraries which may be subject to different licensing requirements.

Customisation can vary hugely, from simply changing branding or appearance, to adding functionality or changing the underlying architecture of the program. The level of customisation will depend on the gap between your requirements and the capabilities of the “off the shelf” product.

Configuration is the process of ensuring that “off the shelf” software can operate with the systems, databases and environments you use. The level of configuration will vary depending on how integrated the software needs to be.

These phrases can often be used in the wrong context, or different descriptions may be used. It’s important to be clear with any supplier what type of work they are providing, and what rights you have to customise or configure software and what the consequences of this may be.

A perpetual licence is the traditional model used to sell software. The customer pays for the software licence up-front and has the right to use the software on a perpetual basis (i.e. indefinitely).

With perpetual licence models, initial installation and configuration is typically paid for separately and support and maintenance is provided under a separate contract either by the software developer or by a third party support provider.

Perpetual licence models usually only cover the original version of the software. If the customer wishes to use a newer version, they pay for a separate licence of that version.