During my career, I have been on both sides of the software selection process. I have helped my company and customers create an RFP, and I have also been on other side responding to the RFP. Based on this experience, here are seven tips to make your software selection process more effective and efficient.
1. Answer some simple questions and shorten your list before you begin
This may seem like a simple statement, but there is plenty of information available to help you whittle down the list of potential software providers up front. For example, some solutions are built for large enterprises while others are meant for smaller companies. Do you want to have a cloud solution or are you looking to buy software that you build and maintain internally? What are you willing to pay for the software, subscription, and implementation fees? Do you need a solution that is tailored to your industry or can a general solution meet your needs? By answering these high-level questions up front, you can narrow down the list to a manageable subset of vendors before creating your first functional requirement.
2. Get everyone engaged
Again, this may seem simple, but too often, I see the process owner build the requirements and select a solution based on their specific needs. Unfortunately, this is a recipe for disaster. All processes and systems have inputs and outputs. There are other stakeholders that provide data to your system and/or need data out of your system. For example, if the AR manager is selecting a new billing and receivables system, have they considered how it will integrate with the contract management and billing engine/operations systems on the front end? Have they explored how well the system integrates with banks on the back end? Can the system produce aging reports based on how the business units interact with customers (can you do an aging by the project manager of the account vs. the account name)? You should identify your stakeholders early on, inform them of the project and seek their input. Not only will this result in a better product selection, but it will also help on the change management side of the implementation by getting buy in from step #1. One final thought – after you create your stakeholder list, ask the stakeholders who they interact with as it relates to this process – you might find stakeholders that you never thought about. CrossCountry has a Finance System Diagnostic that you can have your stakeholders take together their opinions and better understand everyone’s role in the process.
3. Define use cases and key requirements
I sigh when I see an RFP comes out that has 14 pages of detailed requirements similar to “amounts should be up to six decimal points”. Is this really the key requirement that your business revolves around? All too often people copy and paste requirements into an RFP from some previous document, and these things carry forward. What you end up with is a long list of “stuff” that you really don’t care about. On the other side of the coin, as a responder, I need to spend time figuring out how to answer yes so I can proudly report that I “meet” 98% of your requirements. My colleague, Tom Ayotte, always says you should not just write down requirements. Instead, document why the requirement is a requirement. Why does an amount need to be six digits? The reason is you work in multiple currencies that require different level of precision. Why do you work in those currencies? Because the company evaluates customer usage in a local currency which then needs to be translated on a monthly basis and billed in your businesses transactional currency. By pulling the string on the requirement, you are building a use case that outlines key business processes with key requirements built into the system. You should provide these use cases to the vendor and ask them to explain in detail how their system would handle each scenario. This is a much more effective way to evaluate the systems vs. the checking the box requirements matrix (which are highly dubious to begin with!).
4. Skate to where the puck is going - not where it has been
This is an old hockey adage but very true when selecting a new solution. When developing your use cases and key requirements, build in future requirements. Determine your company’s Big Hairy Audacious Goals (BHAGs) and consider them when selecting a solution. What happens when you expand internationally? What about the introduction of services business to support the product sales team? What if you need to change the way you are forecasting revenue and expenses? You will need to weigh these possibilities and build a few use cases that address them. By thinking outside of your current processes, you will get a good idea of how the system can respond to future changes.
5. Get hands on
Many people select a solution without testing the application themselves. That is an issue. When the vendors come in to demonstrate their solutions insist on hands on time for you and your colleagues. This can be tricky because you haven’t been trained, but it is do-able. Ask to be part of the demo. For example, if you are evaluating the procure-to-pay process, you should be the purchase requestor. If you cannot figure out how to put in a request with minimal guidance, then that is a big red flag. Your casual users need to be able to pick up the software and start using it straight away without much training. If you are evaluating a budgeting solution, play the role of the budget owner for a department. Insist that you are the one to put in the drivers and see the results in the budget. By getting hands on the keyboard, it will help you see what is really happening vs. watching an expert effortlessly click through the application. In addition to being part of the demo, ask for one hour of playtime with the application for people to see different parts of the application outside of the use cases.
6. Ask for successes and failures!
Every vendor will provide references that give glowing reviews. Be sure to ask for a few where not everything went as planned. You want to hear how the vendor responded in these situations and how they worked with the customer to meet their needs even with challenges along the way. You can learn much more from failures than you can from the home run successes.
7. Understand what happens after go live
Selecting a new solution is daunting, but when you sign on the dotted line there is a feeling of hope – now our lives are going to get easier. What people often overlook in the selection process is what happens after go live. What will it take to support the application on a day to day basis? What are the on-going costs? How do upgrades work? How often does the software change? What if my business process changes – can the software be easily configured to support the change? Do I need to have a dedicated team member with specialized skills support the application and for how long? What resources are available to help me and how much do they cost? These are all great questions. As part of the evaluation process, you should ask about the typical support structure for an organization using the solution and the extra costs that occur annually (maintenance) or periodically (upgrades)? Build out a five year Total Cost of Ownership model to evaluate not only initial costs (both in terms of dollars and resources), but costs over time.