Buying Software some considerations

Look for a supplier who both understands your technology and systems as well as their own. A good supplier is one with specific expertise in your business and sector, and who can integrate their solution with your current and future technology needs, improve your workflows, and provide enhanced features promptly without requiring complex upgrades?

Across the few vendors who might meet the over criteria, dig a little deeper to understand the vendor's alignment with the specific solution being offered by analyzing their revenue sources. Determine what percentage of the vendors total revenue is derived from the specific products in question. Thereafter break down those revenues into product licenses, professional services, and residual maintenance agreements. Product licenses reflect a current and vibrant solution. Professional services reflects a costly and complex setup and a never ending billing model. Residual maintenance reflects sitting on their laurels and billing customers without concern for incremental innovation. Assess whether the product licenses are a core revenue contributor—indicating the company's strong investment in its success—or merely a supplementary revenue stream that supports other elements within their business. The list of potential vendors should be getting very very select.....

Next try and evaluate the vendor’s real-world bench strenght and ability to execute by focusing on the current team members rather than the company's longevity alone, the “old guard” with deep understanding might not be there anymore. Interview the actual individuals involved in the work to understand their roles and expertise. Assess who is writing the code and how long they have been doing so, are you paying them to learn? Will they deliver on the project gaps? Investigate who is responsible for implementation and the number of sites they have worked on. Determine whether these individuals assigned to your project are recent hires or long-term employees with a vested interest in the company’s success. Again this points to "learning on the job" that you will be paying for, versus quick and low effort implementations bringing your investment to value quickly.

The list of potential vendors should be getting even smaller yet.....

Now try and understand the difference between potential and reality. Assess whether you really can configure and make changes yourself within the solution and product. Evaluate the complexity of the tool set, including the number of components and modules you will need to learn, and how they must interact with each other to actually make the solution work as required. Failure to be able to self manage the solution means you will be paying professional services at every turn.

The list of potential vendors should be even smaller....

Next carefully examine the licensing costs and what is actually included. Understand the definition of a "user" and determine how many modules and sub-modules are necessary to deliver the solution. Verify if you have licensed everything required, or if you might encounter unexpected costs for missing features later. Do you even know what you actually need? Check for volume licenses, user restrictions, and whether some features are tied to other modules or additional licenses. Clarify what was included in the salesperson's affirmation of “yes” to avoid future surprises. Down the road surprises as to what was or wasn’t included could be career limiting. You don’t want to learn that to deliver the final solution you “forgot” to mention or buy something, “that you should have known” was needed. How do you know what you don’t know?

Understand how many layers deep a change request goes. Determine if your implementer can comprehend the change, effectively communicate it to development, and ensure timely turnaround. Assess whether the change requires involvement from a project manager to schedule, a product manager to approve, an architect to design, a coder to create, and finally a systems upgrade to implement the new feature. Good luck with all that!. Be aware of the potential complexity and challenges in managing this process and cost to aquire a new feature or fix. 

Understand the role customers play in the development cycle. Determine whether the vendor always dictates what is best for you or if they are receptive to and understanding of your specific needs, allowing them to enhance the product with new use cases and features. Evaluate whether these enhancements benefit all customers through generic improvements or if the product is at risk of becoming an orphan system, making future upgrades challenging.

Assess the technical debt and the depth of the technology involved. Determine whether the solution consists of disparate modules developed by different teams, each with its own technology requirements, implementation needs, and learning curve, or if it is a unified, cohesive solution. Be aware that many products have evolved from outdated codebases that have been incrementally patched rather than revamped. Technical debt can lead to longer implementation cycles, costly upgrades, and inconsistent functionality across modules. Ensure that the technology, tools, and underlying decisions are regularly updated and reviewed to stay relevant and compliant with current platforms, operating systems, and server versions.

Understand the real total cost of ownership. Determine what is included in your support and whether it is limited to break-fix services. Clarify what is covered under professional services and at what point the vendor will refer issues to professional services, and therefore significantly increase acquisition costs. Identify whether upgrades are included in support or if they fall under professional services

Finally consider how changes in underlying technologies (e.g., Windows Server, TLS version, SQL version, service packs) might necessitate upgrades and who will bear those costs. Evaluate whether you will be forced to maintain outdated elements within your infrastructure due to the impracticality or high cost of upgrades, potentially leading to unpatched servers and OS environments. Understand the support arrangements for these older platforms and the associated risks. Additionally, check if the vendor’s technology stack can operate on the latest platforms if you decide to refresh your technology to stay secure and compliant.

At this point I'd wager that there really will be only one vendor....and you could rest easy knowing that you have done a proper due dilligence on your solution evaluation and aquisition.