Have you ever been involved in a software RFP that failed to meet the stated objectives? That ran way over budget? That launched months or years later than planned? Of course you have. Research shows that only about 30% of digital transformations are successful.
One of the main reasons for this is that “software RFP” is practically an oxymoron. On paper, it seems like an RFP is a strong approach: define your goals clearly, evaluate solutions side-by-side on objective criteria, assess risk, pick the best fit with input from all stakeholders. Unfortunately this approach is fundamentally flawed. It makes a number of incorrect assumptions.
Flawed assumption 1: You fully understand the requirements up-front
You spent weeks building your buying team. You spent months interviewing users. You did your research on the market. You even brought in consultants to help you identify and document your requirements. Surely you know everything you need to know to specify exactly what you need and what you want to buy! Right?
Wrong. You will definitely identify additional requirements – sometimes extremely critical ones! – during implementation. If the project is complex enough to warrant an RFP, then it is too complex to fully document up front. It will affect too many people, touch too many systems, and modify too many business processes for anyone to understand the full impact ahead of time.
Flawed assumption 2: You are picking a static solution with your Software RFP
An RFP implies that you are looking for a software solution that will not change. You want to buy a done deal – something that you can install, turn on, and forget about.
In reality, even the best enterprise software solutions are constantly evolving. They have to in order to keep up with the rapidly changing needs of users and the rapidly changing technology landscape. The best enterprise software vendors are constantly innovating and releasing new features and functionality.
And remember: you will miss key requirements in the RFP. Therefore, in order to be successful, the solution you select must be flexible, if only to accommodate the inherent imperfection of the requirements gathering process.
Instead of thinking about a static solution, you should be identifying a partner and platform that can adapt when your own understanding of your needs changes.
Flawed assumption 3: A feature list can define the solution fit
In an RFP, you are essentially comparing feature lists. Yes, you will ask about customer references, support, security, and so on. But to compare functionality, you’re going to ask about a long list of features.
However a feature is not a solution. A feature is just a tool that might or might not be helpful in solving your specific problem.
The challenge is figuring out how all of the features fit together to provide an overall solution that meets your needs. This can be extremely difficult to do in an RFP, because you are not actually seeing the software in action. You are just reading about it.
The only way to really understand how well a solution fits is to see it in action and use it yourself. This is why trial programs are so important (more on that later).
Flawed assumption 4: You can evaluate user experience from a demo
A demo is not the same as using the software. In a demo, you are seeing a pre-planned, rehearsed, and polished presentation of the software. The vendor controls what you see and how you see it. They are carefully selected to show you only the very best parts of the software. Even when you think you have dictated the demo script to the vendor, it is the vendor that is ultimately constructing and driving the demo, not you.
In reality, enterprise software is complex. It is used by lots of different types of users for all sorts of different purposes. There are bound to be areas that are confusing or difficult. The only way to really understand the user experience is to try the software yourself in a real-world setting.
Flawed assumption 5: User experience shortfalls aren’t important
You made your product comparisons. You thought about information security. You considered vendor financial viability. You saw a great demo. You got pricing that you’re happy with. So you make your selection. And most surprising of all, implementation goes right on schedule and according to plan! Then you go live and… users revolt.
What happened?
In the last section I talked about not being to evaluate user experience from a demo. You might have read it and thought to yourself “So what if it’s a little clunky to use? If it does everything we need at the right price it will still be worth it.”
Here’s the thing: User experience shortfalls kill user acceptance, and low user acceptance kills IT projects.
Think about it this way: you can have the most technically perfect, feature-rich, and secure software in the world. But if people can’t figure out how to use it, or don’t like using it, they are not going to use it. And if they’re not using it, you’re not going to get any value from it.
User experience should be one of your top priorities when selecting enterprise software, not an afterthought. And user experience is impossible to evaluate in an RFP.
There is a better way to run an enterprise software RFP
The good news is that there is a better way to buy enterprise software.
Step 1: Use short RFIs to reverse-engineer requirements and eliminate poor fits
An RFI (Request for Information) is a common first step in an RFP process. It is usually a short questionnaire that vendors fill out to provide information about their products.
You can use RFIs to do more than just gather information, though. You can also use them to help reverse-engineer your requirements.
Start by taking a close look at your current pain points. What processes are you trying to improve? What problems are you trying to solve? Then, translate those into broad requirements. Once you have a list of requirements, you can use RFIs to eliminate vendors that are obviously not a good fit.
For example, let’s say you have a requirement that the software must integrate with your existing CRM system. You can use an RFI to ask vendors if their software integrates with CRM systems, and if so, which ones. This will help you quickly eliminate any vendor that does not support your specific CRM system.
There’s a benefit on both sides: Vendors don’t have to fill out lengthy evaluations where they could have qualified themselves out in a couple of questions, and you don’t have to process long, complex responses where a critical mismatch is buried away in hundreds of questions.
Step 2: Run a lengthy trial program with simple user feedback
After you’ve used RFIs to eliminate the obviously poor fits, it’s time to start evaluating the remaining vendors. The best way to do this is with a trial program.
A trial program will give you a chance to try the software in a real-world setting and get feedback from actual users. To make sure you get meaningful feedback, make the trial long. “Long” will vary depending on specific solution you’re looking for – it could range from several weeks to several months, or even a full year if it needs to capture a full financial cycle. And be sure to include a meaningful cross-section of future users in major and minor roles, not just a handful of “power users”.
Throughout the trial program – not just at the end – ask each user to fill out a simple feedback form. NPS (Net Promoter Score) is a great option, but you can also use a short custom form with questions about specific pain points and whether or not they were addressed. Whatever form of feedback you use, make sure it is painless for the end user to provide and easy for the buying team to process – the most important thing is to gather feedback from as many people as possible, even if it’s basic.
Also, the trial isn’t just about you! You’re giving your prospective vendors the opportunity to work with you and develop a much deeper level of understanding of your needs than they could get by looking at a requirements document in an RFP.
Step 3: Identify a very small set of finalists for the full software RFP
After you’ve collected feedback from the trial program, you should have a good idea of which vendors are the best fit. From there, you can identify a very small set of finalists to move on to the next stage of evaluation.
At this point, you’ll want to do a more thorough evaluation of information security and pricing. You should also have a much better idea of what you need, so you can make sure the finalist vendors are able to meet your specific requirements.
You’ll also get better responses from your vendors at this stage than you will by opening with a lengthy RFP! The remaining vendors will have a much clearer understanding of your needs thanks to the trial, and since they know they’re on the shortlist they will be willing to invest more time in thoroughly answering your questions and also putting their best foot forward on pricing.
Take the plunge
If you’re still using an RFP to buy enterprise software, it’s time to ditch it. The RFP process for enterprise software is broken. It just doesn’t work in this space. While RFPs not the only reason a majority of digital transformation projects fail, it definitely doesn’t help.
The good news is that by following the steps outlined above, you’ll be able to avoid the most common pitfalls of the RFP process and give yourself a much better chance of selecting best partner for your enterprise software needs. Give it a try on your next project!