Evaluating software solutions for your school can be a daunting task. What are requirements versus nice-to-haves? Who should be involved? Where should I begin? Developing an RFP (Request for Proposal) can help provide structure for the process. Below are 9 suggestions based on our experience responding to customer RFPs.
1. You may not need an RFP
Some schools submit 100-page RFPs but don’t have a process established for vetting proposals once they are received. Other schools do not use an RFP but have a process that is organized, efficient, and managed well. The most important thing is to know what your school needs and ensure that vendors meet those needs. If you do decide to use an RFP, format doesn’t matter—just clearly articulate your needs, timeline, and requirements for the vendor. Speaking of which…
2. Give clear instructions to your prospective vendor
What are you asking the vendor to do? Should they explain how their system meets requirements with detailed documentation? Screenshots? Videos? Or just “yes” or “no” answers? When do you expect responses? Each RFP should begin with very clear instructions for the vendor.
3. Your school’s appetite for change drives your timeline
You might need to move quickly through your process. Perhaps your contract is up, your current solution lacks required functionality, or there was a significant change with a vendor. If your school embraces innovation and technology, and change management can be done in hyperdrive, you may only need a simple RFP, or no RFP at all (see above). Or you may be starting the process early and know that change management at your institution can take time. Either way, any successful implementation starts with good leadership and a thoughtful change management process.
4. Identify your “Why”
Implementing new software can be challenging and requires time and energy. The first step in an RFP is identifying the “why.” The answer to this question helps frame your process with context and provides motivation when the process is at its most laborious. The “why” is the anchor that you’ll likely return to repeatedly throughout the search and implementation process.
5. Start with informal interviews
Ask key stakeholders about your current software. Does it make them more efficient, or is it frustrating to work with? Ask director-level staff but remember that the solution is typically used by their direct reports. Remember to ask good questions. “Do you like [insert software solution]?” won’t get you a helpful response. “Does [insert solution] help make you more efficient or less?” will get at the heart of workflows.
6. Identify key workflows and start formally collecting feedback
After getting a 30,000 ft view of software use at the school, begin to formalize the feedback. I recommend a simple survey like:
- How much time a day, on average, do you use the software?
- What are the key workflows you use the software for?
- If we were to upgrade this solution, what are your most important requirements?
- Are these necessities or nice-to-haves?
- Do you think we should investigate a different solution for your department?
7. Make it clear who is making the decision
Ultimately, the decision will likely come down to a handful of people. Ideally, most people are excited about the decision, but inevitably, some people may be disappointed. Remember the “why” and set expectations early that sometimes the best solution for the whole school community is not the best solution for specific individuals or specific workflows.
8. You can learn a lot about a company based on their response to your RFP
Was it done quickly but perhaps lacks detail? Do they claim to meet all your requirements but don’t provide enough specifics? Do they ask you good questions about the RFP? How completely and accurately vendors complete an RFP can be a good indication of how they will manage the ultimate implementation.
9. You drive the implementation schedule…but be willing to be flexible…
After identifying key workflows and the “why,” you’ll have a good idea of when you want the software implemented. Share this timeline with the vendor. However, depending on the size and complexity of the system, they might recommend multiple scenarios or timelines. To be most successful, implementation and training should be a collaborative partnership.
This is all great. Can we see a few examples?
Best of luck in your search!