In our 10 years of business I’ve seen a number of technology RFPs. Maybe – maybe – 10% of them were good. The other 90% were… lets just say “not very good”. How do you know if you have a good RFP? Here are a few clues:
- If your RFP is 300 questions long, or 200 questions long, or even anywhere near 100 questions long, it is not.
- If you use the “our auditors make us to do this for SOX” excuse as to what questions are in your RFP, it is not.
- If you ask any of these types of questions – “Do you use antivirus software?”, “Do you have strong passwords on your servers?”, “Do you run background checks on employees?” – it is not. (Why not? These questions will be answered yes regardless of whether they are actually done or not – and even garage-stage tech companies will do them. Instead you can ask just a few questions, that are not yes/no questions, to get an idea of the “stage” of your vendor and assess these types of risks.)
An RFP is just a waste of everybody’s time if you don’t’ ask the right questions. Approach your RFP as the tool to gather the most important, primarily not feature-related pieces of information that you’ll need to help make a product selection (more on that later). Don’t approach it with the idea of asking every question you can think of. With an RFP, more is not better!
Here are the 20 questions you need to ask when your department or company is buying any web-based software application.
- How stable are you the vendor? How long have you been in business? Are you public? What do your financials look like? How many new sales have you had in the last 6 months?
- How many customers and how many employees do you have?
- What is the pricing model, and what will our all-in cost be? What are all of the possible additional costs, now and in the future, that we might incur? How long or short are your available contract terms?
- How does implementation work – what happens? How long does it take? Are there any additional fees? Which party is responsible for what?
- How does training work? Is it instructor-led (how often) or recorded? How many hours are recommended for each type of user?
- Do you offer trial versions? Are they fully functional? Will the speed be reflective of what we would expect in our production version?
- How do we get our content into the system? Are there import or conversion utilities? Do you charge separate fees for conversions or importing?
- How exactly do we get our data out of the system if we cancel? Is there a fee? What format is it in? Can I see an example?
- How does customer support work? Are there different levels for different fees? How do we contact support – by phone? Email? What is the typical turnaround time to receive a reply? (Note: You should pick up the phone during your due diligence and call to see if the support line answers).
- How do upgrades work? Does everyone get upgraded at once? How many upgrades have you done in the last 24 months, and how many are expected in the next 24? How much work is required by us for an upgrade? Have you ever charged a separate fee for any upgrade or any new or additional module or feature?
- What versions of what browsers on what operating systems are supported? Are any unusual browser settings needed? Is there a requirement to download any application or plug-in to our desktops, for core or optional functionality?
- How is our data hosted – is the hosting “multi-tenant”, where a single database houses data from many customers, or does each customer have their own unique database? What hosting provider do you use?
- Have you ever had any type of unauthorized system access or security breach, to any of your servers or any of your client data?
- When was the last time that any customer was unable to access their site due to an issue with the system or the hosting infrastructure? How long was the system inaccessible for? How many instances of downtime have happened in the last 24 months?
- What is the backup procedure – how often are backups taken? What backups are stored offsite, and in what medium – tape or electronic?
- What is your general disaster recovery model? Do you have another location setup as a hotsite, or is client data mirrored to another site for redundancy? If a catastrophic accident happens to the datacenter, where would you restore our data and how would the restore process work?
- What features are coming with the next release, and when is it expected?
- What 3 features are most asked for by current customers that are not in the current version or planned for the next version? (Note: You may not get valuable information here, but you should still ask).
- In your experience what are the most important factors for our ultimate success with your product?
- Can we have 2 references from companies that (1) are currently using the version we are considering, for the same intended use as ours, and (2) have been customers for at least a year? (Note: Don’t worry about customers in the same industry unless the product/need is truly industry-specific.)
Most of these questions don’t have a “right” or “wrong” answer. If your company is buying an ERP system, you probably aren’t going to buy from a company started last month with 3 people. On the other hand, if you’re exploring new innovative products that aren’t mission critical (like a project management or collaboration tool), that new company might not just be okay, but even preferred in some cases. The information you gather needs to be evaluated in the context of your need.
You would of course add some functional-specific questions based on the type of system you are evaluating, but fight the urge and limit yourself to as few functional questions as possible. Functional requirements are what a demonstration is for. Vendor salespeople can figure out some way to justify a “yes” answer to almost any functional question you could ask. All those “yes” answers from all those vendors means you don’t have any real data to compare vendors against.
Did I miss any questions? Let me know in the comments.