What are the steps to evaluate software options?

Start by understanding what your enterprise users need. Discover what they have available today and how this helps or hurts productivity.

While I would never say "don't define your requirements," you should not base them on who you are today as an organization or what you do today. By the time you have details about all the stuff you do today, it will have changed. Don't waste your time outlining in excruciating details all the things you do today. Instead, requirements must be rifled towards the target of who you want to become as an organization and what you'll need somewhere down in the future. Cast a vision of what you want to do in the future. Or, should I say, what capabilities you will want to exploit.

Security and Compliance are worth considering. Ensure the software meets industry-specific security and compliance standards, especially if you are handling sensitive data.

Below are some steps to evaluate and select new software. Assess user needs, current and future requirements. Prioritize selection criteria. Have comprehensive research & create a list of vendors/options. Request information, demo and free trail to be tested by your team. Create a comparative statement based on features, functionality and financials. Have UAT - user acceptance test and implement the solution Take feedback & evaluate responses

Connecting with industry experts, and companies in your space that have gone through this exercise is a must. If you know someone with a similar company setup who's been through the process, then you'll be able to determine your shortlist a lot quicker

Don't spend too long on desktop research - get out and start talking to consultants, competitors, suppliers, clients to learn about the market. Don't be afraid to ask a sales rep for a quick call can speed up this process. "I'm doing research on software in category XYZ, not sure if your firm are what we're looking for, do you have 10min to point me in the right direction". The best reps will tell you within 5 minutes if their firm is not a fit, and then name 3 other firms you should talk to instead.

I'd start reaching out to colleagues if you are in a large organization and interview them about the products first before searching the internet for information, also, there are vendors that can analyze the information and give you the summary, our thumb rule is to make sure you analyze at least 3 products and get the fee structure and analyze before making the decesion

Technical requirements are a must - but even more importantly - business issues, or problem statements they are trying to solve. Ideal wishlist of outcomes really helps define client needs. Lower TCO, growth and scale? Automate processes for further agility? 2024 = Machine based operations.

I totally concur with Adam A. I would add that understanding support SLA's as well availability of tech support from the vendor is extremely important.

Don't pretend that this process can result in a production-ready system. Current purchasing advice is to use "Lean Agile Procurement" to produce (for free) a production-ready MVP (minimum viable product). Why would you do this? To eliminate the cost of the procurement process! Yes, but you also eliminate "quality" and "usability" (and your ability to maintain the system after the warriors walk away).

Demos are beautiful when everything us set-up for you and when the rubber hits the road(running the product in-house) is where you will see most of the issues, I'd get the demo and start running POC's in-house before making the decision

make sure to keep cost in mind, is it one one-time or based on usage and projected cost for over 5 years, this helps make better decesions

Ranking systems based on requirements are helpful, but there are intangibles that should give you a good gut feeling about the team you're working with as well. Examples: See how receptive vendors are to giving you things like executive alignment, higher levels of support, design partnership, etc. See what other types of customers they work with and if those customers are happy. Uncover what their Net Dollar Retention (NDR) % is to see how efficient their customer success and product adoption is. Understand their product roadmap vision and org structure vision to understand where they are investing in the business.

I'd say negotiate terms as a organization or piggy back the terms on behalf of organization instead of dealing with the vendor as team this can help save millions

You should have a ballpark understanding of pricing model and terms early in the software evaluation cycle. However, negotiating terms and conditions should happen in the later stages of a software evaluation after you've determined that a vendor meets your people, process and technology requirements. North star: Everyone should feel good at the end of a negotiation. Map out what's most important to both parties in terms of pricing, terms, and flexibility drivers. After you have a shared understanding of guard rails, test what will move the needle for both sides. Remember that most software businesses have about a 80% profit margin.

actively solicit feedback from the users, looking for unexpected anomalies. Ask daily for the first few weeks, and look for trends because users have a natural assumption that "they must have made a mistake" rather than report a seeming random problem which might appear minor - until it is recognised that the whole user group has been suffering this for the last three months, and the software becomes discredited and more broadly distrusted by managers

There are many other factors that need to be considered by CIO in the procurement process. NFRs: CIO should list their NFRs, and quantifiable goals with each requirement. This must be compared against the product features thoroughly. NFRs like accessibility always takes backstage but the negative impact get noticed sooner. SLAs: Document the SLAs, implications, fine/penalties, and workarounds in detail. Every possible clause should be documented in simple words. Compliance risk: Data privacy, confidentiality, regional regulations scenarios should be validated and documented Upgrade policy: Product upgrades, timelines, backward compatibility, and disruption chances must be collected from vendor and verified against the usage dynamics

Finding the perfect marriage of software to the enterprise is a two-way street. You should not employ waterfall-style thinking to make a decision, then retrofit the enterprise to that decision (train staff and integrate existing systems). Always consider whether there are any process changes or people additions you could make which would improve the effectiveness of a particular solution. Also, consider the extensibility of your solutions and capacity for integration. Can your proposed software solution be extended with APIs? Does it have a thriving plugin/extensions marketplace?

You've probably noticed that the main advice is to start up front with some deep introspection. That's very good advice that is available anywhere but rarely actually practiced. Let's say, you've barrelled ahead and built something. Once you've completed the selection, purchase, and implementation... what happens next? If you were clever enough to set out your vision and goals in any kind of detail, you should probably check the results against the original plan. Post. Project. Review. ROI Confirmation. Basically you need to ensure your expenditure results in positive outcomes. OK, sure, these can be non-monetary outcomes, and for those, you should think about assigning a monetary value to them so you can compare withe the baseline.

Peer and Customer reference sessions are critical to assess and filter out various marketing hypes during pre sales sessions!

When socializing the solution with executive approvers, speak in business terms that align with board/executive priorities. Stay away from cryptic vendor terms and acronyms. Cite short-term use cases and anticipated business outcomes. When requesting investment, include all associated implementation and training costs that will ensure successful adoption.