Choosing a vendor for a technology project can be harrowing
The playing field is simply not level.
You are a nonprofit superstar, spending all day running programs, delivering services to clients, and furthering your mission. You know your client’s needs in and out.
But when it comes to the language of the technology vendor – SaaS, platform as a service, AWS, named vs. concurrent licensing – you are out of your element and playing by the vendor’s rules.
The vendor spends all day selling their application. They are practiced and highly skilled at pointing out how every little feature of their product is the best, most advanced, cutting edge widget ever built. Sales reps know just enough about your world that they can throw the language around and share stories of other sales calls they have been on. The vendor will use their technical language easily and confidently – even if they don’t fully understand it themselves.
The vendor is better at this than you – but only because they do it all day, every day.
So how do you turn the tables and take control?
Get somebody technical on your side of the table
Right from the start, find someone who will sit on your side of the table who knows the technical lingo and can interpret the techno-sales speak from the vendor on your behalf.
If you don’t have someone on your staff who can do this, the role can be played by a board member with technical expertise, or by a nonprofit technology consultant like Community CIO.
Your technology advocate should sit in on all RFP planning sessions, vendor demos, and scoring sessions. Your advocate should immediately debrief the rest of the selection team after each session. The team must make sure all the technical aspects have been properly understood and no one is making incorrect assumptions about the vendor’s product.
If you think you need someone on your side now – tell us about your project and we will perform a free evaluation of your project to determine how we can help you.
Have a process and stick to it
Step 1: Know your users and what they do.
You have a secret weapon. You know your organization’s needs better than anyone and you know what your people need to be doing. Use this knowledge to turn the tables to your advantage.
Start by making a list of all the people who will use the system you are considering. Categorize them into “user roles”. These roles may be similar to your job titles, but not always.
Receptionist
Intake Specialist
Data Clerk
Case Manager
Program Manager
Executive Director
Board member
Describe each user and their relationship to the system.
What information are the expected to enter?
Where is that information coming from? Paper, in-person interviews, etc.?
What kind of information do they expect to get out of the system, and how? Paper reports, on-screen graphs?
How much time do they have to work on each task?
What is the experience level of the user? Full-time employee? Volunteer?
Is the user skilled with technology?
What kind of workstation do they have?
Do they have an office or are they always out in the field?
Now for the secret weapon – User Scenarios.
From this treasure trove of information you have collected, write a series of scenarios that your users will actually perform in their day to day work using the system. Something like this:
Mary is an intake specialist, she is a part-time employee using a shared workstation at a public desk in the main lobby. When a client approaches Mary, she will need to be able to quickly determine whether or not the the client is already in the system.
If the client is new, Mary will ask a series of intake questions (between 12 and 20, depending on the program) and enter the responses provided by the client. There is no paper intake form used. The client expects to complete this process is no more than eight minutes.
If the client is already in the system, Mary will need to be able to see which programs the client is enrolled in and the name and phone number of the assigned case manager so she can send the client to the right department. Mary should not be able to see any detail about services being provided to the client.
Each scenario must be ranked:
- Critical – must be followed without exception
- Necessary – must be followed, but we have some flexibility
- Nice-to-have -you would like to have this but can live without it
Write at least two stories for each role and make sure you write down all the critical scenarios.
Congratulations – You now have the majority of the content for your RFP and an agenda for every vendor demo you will sit through.
Step 2: Write a Request for Proposal (RFP) and a Scorecard
An RFP is a written document that serves as a guide for vendors to pursue your business. Start by describing your organization and the problem you are trying to solve. Declare the values of your organization and describe the values of the type of organization you hope to partner with.
If you have minimum technical requirements, they need to be in the RFP. For example, if you are unwilling to purchase and manage self hosted software, you should specify that only cloud-based offerings will be considered.
Be cautious about going overboard here – make sure your limitations are really necessary. You don’t want to eliminate a vendor with a novel or forward thinking approach because of a “requirement” that you would be willing to bend on.
Include the user scenarios and be clear that the vendor will be required to demonstrate compliance with each one during their demo. Be clear about whether or not you will accept proposals that cannot meet all the critical scenarios.
Finally, develop a scoring rubric to apply to each proposal you receive. The rubric requires your selection team to discuss and agree on which pieces of the RFP are deal breakers and where you have some flexibility.
For example, if the vendor can meet only 95% of the critical scenarios – is that disqualifying? Or perhaps not all of the scenarios identified as critical really are. If the RFP requires local representation, but the only vendor that meets all the scenarios is remote – how should that impact the score?
An RFP and a well developed rubric help you quantify what you need as well as what you want.
Step 3: Demos, Demos, and more Demos
Not every vendor who submits a proposal has to be invited for a demo, but you should not select a vendor without a demo.
Beware – Vendors do demos all the time, they are very good at them and will make sure to show you every beautiful feature and widget their product supports. If you are not prepared, the vendor will make you fall in love with their product without you really looking under the hood.
The demo for you, not for the vendor. This is where your RFP and user scenarios really come into play. Let the vendor run his game plan, but keep track with the rubric of what they cover and what they don’t.
If a feature is presented that does not satisfy any point on the rubric, it should not increase the vendors score – regardless of how excited the vendor is about it. Feel free to cut in and ask the vendor to explain how the item meets any of the scenarios. If they cannot explain the relevance, ask them to move on.
If the presentation does not address all the items on the rubric, ask the vendor to explain how their product meets the missed requirement. Don’t take a soft answer here – the vendor can either meet the scenario or not. If the vendor fails to demo how they satisfy a scenario, then assume they cannot.
Debrief with the full selection committee as soon as possible after each demo. Compare notes and ask questions, but do not advocate for or against any vendor at this point. The debrief is to make sure everyone’s notes are complete, not to make a decision.
Step 4: Pick someone
After all the demos are done and all the scorecards are complete, the choice will probably be clear to everyone. The selection team should be able to discuss their individual scores and impressions. If all the previous steps have been followed, this will be an easy decision.
But.. Know when to be flexible
Following the process will make sure you end up a with a clear picture of which vendors are “technically” best for you. But instinct can still play a role here. Sometimes a vendor can score well on the RFP, but you are fearful that the vendor is not stable, may be facing a leadership challenge, or maybe doesn’t share some of your closely held values.
But be cautious, instinct can be flawed in situations like this – that is why we created the whole process after all. Instinct can guide you between two well-qualified vendors, but should never elevate an unqualified bid.
If you have a vendor selection challenge facing your organization, tell us about it and we will perform a free evaluation of your project to determine how we can help you.