How to organize your next software procurement

This is the second article in a series about buying and implementing software. Other articles include:

Congratulations! Your business has spent the time to gather your internal requirements, conduct a needs analysis, and put together KPIs to understand what software you should be looking for. Now comes the exciting part, selecting the right software.

To get to this point, read our past article on the top three things to consider before buying new software. Learn why having a standard procurement process ensures alignment between the business, business units, and individual staff. Reconciling the needs from throughout the enterprise in a structured software procurement process is a key part of the software buying journey that should not be skipped.

While there are many variations of software procurement, it comes in two primary flavors: sole source and request for participation from a vendor. Adopting either of these two processes will ensure your company gets the software that best fits your needs for a price that is justifiable.

Sole Source

As the name suggests, sole source procurement is defined “as any contract entered into without a competitive process, based on a justification that only one known source exists or that only one supplier can fulfill the requirements.” Sole-source procurement is also known as single-source procurement. This procurement strategy has the advantage of being the shortest process. It is a proper approach when there is a clear market leader in the space, and there are no company-specific requirements for the product that require customization. As a result, it's not practical to consider solicitations from the market at large.

As an example, if a company is interested in purchasing word processing software, a sole source approach would be logical, as Microsoft Word is the clear winner. However, if the word processing software needs to run on a desktop Linux-based system, then a sole-source approach would not work as Word can only run on PCs and Macs.

Sole source approaches have several disadvantages that can include higher final costs and less customizability of the end product. By only working with a single vendor, a business has less bargaining power on the quoted price. As only one price is being sought, it is also more difficult to understand what the ‘market rate’ for a service should be. Software purchased through a sole source procurement is often less customizable, meaning if business needs change, the product may not have the flexibility to meet the new business requirements. While a sole source procurement may be the quickest approach for off-the-shelf software for a well-defined problem, its disadvantages are significant and should only be used in limited circumstances.

The Request For... Process

Very few businesses have the time to spend months internally researching all the software products that can fulfill an identified need. If this sounds like you, use ‘the request for’ participation for the vendor approach. While they can be used in order, most companies will only use one or two at a time: Request for Information (RFI), Request for Proposal (RFP), or Request for Quote (RFQ). The advantages of the 'request for*' process are opposite of the sole source approach - prices are fairer, and there is a much higher likelihood of the software meeting or exceeding the requirements laid out in the original needs assessment.

Picture Golden Goose, an insurance agency with a $50M a year in revenue book of business that’s growing at 20% annually because of the new AI-powered sales software they are using. To sustainably grow, they need a new Agency Management System (AMS) to handle the volume of new business. They documented their business needs, which include an integrated rater, policy, and claims management, and a full marketing suite. They put together an RFI, posted it on their website, and also sent it directly to AMS vendors they are interested in learning more from. After hearing from five vendors, they put together an RFP to request specific information from the vendors on how the system will work within the context of Golden Goose. Out of the five vendors who responded to the RFI and the RFP, they selected two finalists and sent them an RFQ to find out the exact cost. From the finalist, Golden Goose chooses a winner who meets all of their criteria and requirements in the original needs assessment.

While this fictional example shows how all three can be used in a sequence to progressively gather more and more information, a detailed RFI would have likely gathered the same information that was later provided to Golden Goose in the subsequent RFP and RFQ. To apply this process to your business, use the approach or approaches that best fit the situation.

The request for approach has several limitations, the primary one being how slow it can be. The second limitation is that it requires some active participation by vendors. If your business is too small or the needs are too niche, it is possible that vendors will not respond to your request because the final sale will be small. Even with these drawbacks, this approach should be the software procurement default as the positives outweigh the limitations, and will lead to a more favorable end-result.

Each business, and its needs, are unique. Use the procurement method that best suits the timeframe and complexity of the problem you are trying to solve. If a sole source approach is not returning adequate results, go to the request for process. Expect any procurement process to take at least three months to complete - from purchase to implementation to use training. Unless speed is absolutely necessary, don’t place artificial pressure to get the procurement process finished, as that can lead to suboptimal results.

The most important part of a successful procurement is that everyone agrees about what they expect and what the next steps are. Communication is key, as is documenting assumptions. Most businesses have a horror story or two about procurement that went off the deep end: “it was supposed to cost $1M but ended up costing 10x that”, “the final product was so bad we couldn't use it”, or last, “after trying to get the software to work for five years, we scrapped it and bought something else.” To avoid this and the myriad of other unfavorable endings, adopt a formal procurement process. Your colleagues and your gray hairs will thank you.

This is the second article in a series about buying and implementing software. Other articles include: