Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Monday, May 22, 2006


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: ,

Comments on "RFP"


Anonymous Anonymous said ... (May 23, 2006 at 8:00 AM) : 

RFPs can often be a hindrance to our clients as well. At Apex ( We have found the biggest problem with RFPs is they are often solving the worng problem, or merely applying a band aid to a root process that may need a complete overhaul.

-Lisa McGrath,


Blogger Michael Stein said ... (May 23, 2006 at 4:02 PM) : 

Lisa -
You are taking on an even deeper problem than I was thinking about here - solving the wrong problem! Often organizational development issues are more comfortably viewed as technical difficulties. An RFP warning sign of this are "Pathological requirements" - undue complexity, fear of information sharing within the organization, security requirements that reflect a history of staff distrust...


Blogger David Kutcher said ... (August 23, 2007 at 10:39 AM) : 

Have you ever been to the RFPdb ( to find RFPs?

Give it a try!

If you’re interested in helping us draw more traffic to the website there is a RSS feed that you can plug into your blog that shows the most recent RFPs posted to the site.



post a comment