RFP

In my last post I shared a few ideas about software development contracts. Today I'm thinking about RFPs - Requests for Proposal. In the last month or so, we've been responding to a lot of RFPs because we've been receiving a lot of inquiries about our work. I'm certainly not going to complain about that. But I do have a few observations that can help your organization with its due dilligence the next time you go looking for software. Organizations who want to learn more about our software and services are our lifeblood. But we sometimes find ourselves grumbling at the way some of these RFPs ask us to respond. An RFP can cause us hours of extra work and nontheless prevent us from really telling an organization why we would be a good choice for them. How do RFPs do this? 1. Some RPPs make it VERY CLEAR that responding in our own format, rather than simply filling in the form provided, will disqualify us. What we'd rather do is include our boiler-plate chapters whenever possible, and in your grid just point you to the page that explains our methodology, or our tools, or how much liability we carry. This saves us time. Why should you care? Because if we are not wasting hours cutting our standard material into little bits and pasting it into your framework, we have more time to respond to the important issues your RFP raises that truly are unique and demand some original thought on our part. Give your potential vendors time to think about you and your mission and you'll get proposals that seem much more on the mark. 2. A particularly annoying style of RFP asks us to respond yes or no to whether our software supports each of literally hundreds of specified features. The real hallmark of this is the RFP that includes a matrix with numbered items such as 5.3.2.c The system will allow the entry of either a 5 or 9 digit US zipcode. What's wrong with this? Obviously there's no CRM you'd consider looking at that didn't support US zipcodes. Many of the requirements these heavily feature-based RFPs ask about are going to be supported by every contender. So these answers really don't help you distinguish between your prospects. They don't do you any good at all. What would serve you better? A focus on requirements that you suspect might not be available from all the contestants. Use a shorter grid with items that will really help you distinguish among your suitors. 3. Of course your RFP is built to reflect your requirements analysis. But that doesn't imply you should only ask questions about your identified needs. If you do this you are making it hard for any of the vendors to tell you what is unique and innovative about their approach. You ask them about your ideas, but not about their's. While you absolutely need to assess whether they meet your essential requirements, you also want to learn what is special about each of these vendors. They've worked with lots of non-profits. They each have a different take on the challenges you are presenting. You deserve to hear it. Additional Resources: If you are new to the RFP process, you might want to take a look at these RFP resources on the Techsoup site. Technorati Tags: nptech, RFP