We are very pleased to host this blog post by our good friend and colleague Peter Campbell. Peter has been a tireless advocate for the effective use of technology at nonprofit organizations for over 2 decades. He is actively involved in several nonprofit technology communities, including NTEN. He is currently the CIO at the Legal Services Corporation in Washington, DC.
He wrote a fantastic forum post recently and generously agreed to expand it to a full length blog post for Community IT.

 
Requests for Proposals (RFPs) are a controversial topic in the nonprofit sector. While governmental and corporate organizations use them regularly as a tool to evaluate products and services, their use in our sector is haphazard. I spoke recently about the RFP process and how it could work for us at the 2014 Nonprofit Technology Conference. My slides from that talk are here, along with this blog post outlining my key arguments in favor of RFPs. But a recent conversation on NTEN’s DC community list really summed up the topic.
A member posted an RFP for CRM consulting and asked why he was getting scant responses from the vendors. I looked over the RFP, and saw that it requested a fixed bid quote for work that was not well defined. I popped back into the forum with some comments:
 

“This five page RFP contains about a tenth of the information that a decent consultant would need in order to propose a meaningful bid for the work. If you’ve received any such bids already, I would advise you to throw them out, because those bids are wild guesses, and you will either be paying more than you need to, or setting yourself up for a combative relationship with a vendor who is angry that the project is taking far more hours than they guessed that it would. Decent consultants are passing on the RFP because it lacks so much specificity. There are two ways you could address this problem:
 

  1. Significantly beef up the RFP. If I were to go this route, I might hire a consultant to help me write the RFP, because they can better communicate the requirements than I could.
  2. Stop asking for a fixed bid. Query their expertise in the areas that need it, and request ample examples of work they’ve done. Also, ask for their hourly fees by role. The RFP can provide a fairly high-level overview of the project, as you won’t be asking them to generate a meaningful estimate. Instead, do reference checks and ask specific questions about their billing in order to vet that they are honest and sensitive to nonprofit budgets.

Many consultants would pop in here and say “forget the RFP – let us come talk with you and get a sense of the project and we can go from there.” As a customer, not a consultant, I wouldn’t go for that. A good RFP, sent before any face to face meetings, can tell you a lot about the professionalism, insight and care that a company will bring to your project.  Rapport and relationship are also critical, but assessing those elements is the second step. (And when it comes to that step, insist that you are meeting the people who you would almost certainly be working with). An RFP response can also be attached to the contract to make sure that the vendor is obliged to live up to their claims.
I do fixed-bid quotes for phone systems and virtualization projects, where I can tell them exactly what the project would entail. I don’t for websites and software development, because not only do I not know what the ultimate product will look like or require, I shouldn’t – a lot of learning takes place during the project that will shape the requirements further. Once I’ve hired a good consultant, we can do a defined discovery phase that will allow them to provide a fixed quote — or reasonable range — for the rest of the work.  It’s a much better way to set up the relationship than by basing it in unrealistic projections.”

Subsequently, a consultant posted a reply suggesting that RFPs are a pain, and they should really just hire a consultant they like and see if it works out, perhaps after doing a small Request for Information (RFI) to learn more about the consultants available. I replied:
 

I did say that consultants will often dis the RFP process and say, “just hire us and see if it works out.”  It certainly is easier on the consultant. As Clint Eastwood would say, the question is, “do you feel lucky?” Because if you feel lucky, then you can just find a suitable-looking consultant and hope that they are ethical, not over-booked (and therefore liable to under-prioritize your project), experienced with the technology that they’re deploying, etc, and do a discovery phase that will cost you x thousands of dollars, and then find out if they are the right consultant for you. Or you can do an RFP, throw out the responses that clearly don’t match your requirements, throw out the ones that don’t seem interested or well-resourced enough to respond fully, and interview the two to four consultants that look like good matches. It’s more work up front than hiring someone and hoping they’ll work out, true, but, here’s what it gets you:

  1. Focused. Just writing the RFP gets you more in touch with the goals and requirements for the project.
  2. Informed. The RFP review and interviews are a chance for the project team to explore the project possibilities with various experts.
  3. Confident. Without investing thousands of dollars into a “vendor test,” you will know who has the right experience and a compatible approach. For me, it’s often less about the skill and experience than the approach (e.g., we want a collaborative partner that would teach as they go, rather than experts to outsource the work to).
  4. Accountable. The RFP can be a contractual document, so if the vendor lied about what they can do, they can be held responsible for that lie. And, not all consultants lie, but some do. I’ve caught them at it.  😉
  5. Documented. In the future, after you’ve left the organization, your successors might wonder why you selected the partner that you did. The RFP process leaves a knowledge management trail for key organizational decision making.

And finally, RFI vs RFP is a question of scale.  For smaller projects, without much associated risk, RFI. The investment in doing a full RFP does have to be justified by the cost and complexity of the project. For big projects, doing an RFI in order to identify who you want to include in an RFP can be helpful.