Four key steps to purchasing cloud software

Following the COVID-19 pandemic, digital transformation efforts have accelerated across the majority of industries with businesses being forced to make alterations to their usual working routines in next to no time. What’s more, remote working made it apparent that legacy systems were no longer up to the task for businesses to operate in an effective manner.

Businesses soon realised that the cloud resolved many of these issues by offering improved flexibility, manageability, and a rapid ROI. As businesses moved to the cloud, processes were reconfigured and operations and service models were redefined. However, many enterprises weren’t fully aware of the significant differences between acquiring a new cloud solution and purchasing traditional on-premise software.

The major contrast between the two is that while the former is delivered as a service and purchased as a term contract, usually over a period of three years or more, traditional on-premise software often involves the one-time outright purchase of software. Purchasing a service is unequivocally different to buying a product, so it necessitates a distinct approach to the procurement process. Irrespective of the size of the software being procured, there are four key steps that organisations must follow when it comes to purchasing cloud software.

1. Before you begin, get the foundations right

Prior to starting the procurement process, organisations need to ask themselves some simple yet important questions. Do you have a clear business strategy in place that the system will be supporting? What are you aiming to achieve by moving away from the existing solution? Only once you have answered these questions, and have a clear goal to aim for, can the process of purchasing cloud software commence.

It is vital to build an evaluation team that is capable of addressing the complexity and scale of the task in hand. Executive engagement is fundamental, a robust project governance model is essential and it is vital to have a mechanism to capture invaluable knowledge and insights from subject matter experts and users from throughout the organisation.

Once this team has been created, it must examine the current solution and its limitations, in terms of cost and effectiveness as well as ensuring business strategies are aligned, highlighting the critical tasks that it must accomplish both now and in the future.

2. Collect the right information

In order for a company to find the best solution to deliver their requirements, it must provide prospective suppliers with an easy-to-follow, clear description of their needs. This allows potential vendors to create a solution proposal that is attractive, compelling, accurate, and relevant. The information supplied should include basic details such as the enterprise’s business goals, its current systems landscape, size, geographic coverage and a future vision of the desired state. There is a need to describe the current systems and processes and in particular any specific customer or industry idiosyncrasies that are essential for project success. It is important to also look ahead to the future and ensure that any significant prospective business changes can be easily adopted.

When it comes to defining requirements, many businesses utilise a ‘MOSCOW’ list approach which comprises: Must-haves, Should-haves, Could-haves, Would-like-to-haves.

It is important to ensure that both the functional and non-functional technical needs are defined, as is giving consideration to future needs to align with potential market opportunities, competitive demands, and growth goals. Remember, you are acquiring a service not a product, so the characteristics of the service being delivered also need to be considered.

Once all of these have been defined, the various requirements can be prioritised and given weightings as the basis for defining a common set of evaluation criteria. These can then be used to ensure a robust and fair assessment of the various vendor proposals and ensure an impartial comparison between the options available.

3. Approaching the market

Once business and IT needs have been established, the next step is to approach the market to educate the team and gain an understanding of the available options. Businesses need to be aware of what is on offer in the industry, what other companies are doing and the different offerings available from various vendors. External advisors and industry analysts like G2, SPI and TSIA can provide an overview of the comparative pros and cons of available solutions, and how they fit with regards to the specific requirements of a business.

It is worth doing online research, attending trade fairs and having initial software demonstrations to get a feel for the latest technologies, preparing for the evaluation ahead.

Recommendations from contemporaries and evaluating competitors’ solutions can be helpful, while it is also worth learning about the market credentials of a potential new vendor to ensure they are knowledgeable about the industry. Before signing a long-term contract, it is important to think about the vendor’s commitment to the industry that the business operates in, the look of its future product roadmap and the organisational culture. Again it is worthwhile remembering that you are not simply making a one off purchase, but acquiring a service and starting a relationship that will last for the duration of the contract and potentially beyond.

4. Evaluation and negotiation

In years gone by, choosing legacy software typically involved a tortuous request for proposal (RFP) process involving a multitude of questions in an enormous spreadsheet, followed by numerous highly structured and formal demonstrations, often to a set script. However, this traditional and didactic approach to product selection is no longer relevant for the effective procurement of cloud solutions. It invariably fails to take into consideration the requirements of a service contract and the values of a strong working relationship.

As a result, businesses are increasingly using more inventive and suitably appropriate approaches to assessment and evaluation. For example, this may involve having vendors suggest creative responses to a number of different business situations rather than provide a step by step walkthrough of a pre-prepared script.

Furthermore, it is also worth considering that throughout such an evaluation process, there is the potential for tensions and differences to surface between the different parties within the analysis team. This is why it is vital that robust evaluation criteria are defined and agreed at the outset. This ensures that decisions can be made with regard to well defined business objectives and priorities, mitigating the risk that individuals may be unduly swayed by pretty screens and shiny objects that do not actually deliver real business value!

When it comes to making the final decision, the initial cost to acquire and implement the software will most certainly be a consideration. However, because this is a service that is being bought, the overall cost of ownership for the solution over the period of the contract, including ongoing maintenance costs and the likely return on investment that the solution will actually deliver, are of much greater significance. In addition, factors such as the future product roadmap, performance demands and service level agreements must also be considered as significant criteria when making the final decision. And it is worth ensuring early visibility of vendor contract terms and their Cloud Services Agreement, because this can often be the source of problems during negotiation.

The overriding consideration though, is that organisations must ensure that irrespective of the cloud software they decide to acquire, business leaders are able to enter into a partnership which is built on strong and stable foundations with their partners and the solution vendor. Businesses should be aware that digital transformation is an ever-evolving process. An organisation should constantly be looking to increase the value it gets from cloud solutions long after the initial implementation of the software has taken place.