I’ve certainly responded to plenty of RFPs in my career, but I’ve never written one. Recently I’ve gained a new appreciation for people who can do this well.
In my quest to find a reliable and skilled development team to build the Grouvia back-end, I crafted an RFP. But I’ll admit, I did something any self-respecting entrepreneur would do, I copied someone else’s. Unfortunately the one I chose was from UConn (the University of my old home state) which had all sorts of blather in it about working with the government, etc., which I had to sift through and remove.
I couldn’t actually *read* this thing, and God help the poor souls who are trying to bid on it. Bidding on government contracts is a skill in and of itself and an advanced degree from a law school seems like a good prerequisite.
I scanned each section and deleted the stuff I was sure didn’t apply to me, and now I’m left with this icky shell of remaining sections that I have to read through and either (1) delete, (2) keep as is, (3) re-word, or (4) add a note to come back later. Unfortunately most of the sections are 4’s so far. And truth be told, it was giving me a headache to read it.
So at this point I decided to try a different tactic. I have to create an abstract out of my requirements to include in the RFP so the bidders have some clue about what their bidding on. I opened up my 150-page requirements document (technical writing is one of my strengths) and started by taking each section of the document and creating a high-level version of it.
This is not an easy task, as I essentially have to READ each section and decide what parts of this feature are worthy of being includedm then figure out how to abstract them. It’s not hard work but it’s incredibly time-consuming! In the meantime I have three development firms waiting for me to send this to them. No pressure there!
What I’ve boiled it all down to is six fundamental sections of an RFP:
1. Overview of the project and background of the company and founder.
2. Legal stuff about holding harmless and confidentiality and no warranties and all that.
3. My expectations about communications, deliverables, timelines and the like.
4. Overview of the scope, technology to be used, project phases and skills required.
5. The functional requirements abstract.
6. Instructions to the bidder on what I require in their response (such as samples of their work, explanations of their methodology, their support policies and mechanisms, references, etc.)
In addition, I’ve come up with a five-step process to orchestrate this whole proposal-gathering task, which I believe is going to work out well:
- Send out an open call to vendors that includes some basic marketing type of information about the project as well as links to the preliminary website and this blog. Ask them to review the information and links, decide if they want to bid and get back to me with some basic information about their company, past projects and a brief paragraph explaining to me why they believe they should bid on this project. This step should filter out the tire-kickers and the people who just collect RFPs for weird reasons. I sent this message to personal friends and family who probably know people in the business, posted it on a discussion board on one of my relevant LinkedIn groups, and hand-selected about a dozen development companies I found on Guru.com.
- Evaluate each respondent, take a quick look at their info, and make a gut decision about whether to include them. If yes, send them an NDA (Non-Disclosure Agreement). I’ve already told them in the first step that they’ll need to sign this in order to get the RFP.
- Upon receipt of the signed NDA, send the RFP. They all have until August 21st to get me their proposals. With any luck I will send out at least a dozen, in the hopes I’ll get 50% of them to actually bid.
- Receive and evaluate all proposals. This one scares me a little. I know this is going to be a big job. I have no idea yet what criteria I will use to evaluate them. The RFP I copied had a whole section that explained exactly how they intend to do this, using a point-based system thing. Blech. I prefer going by a gut feeling, but I know I have to somehow cull these all down to some logical set of criteria so I’m comparing kiwis to kiwis.
- Award the project! This will be the fun part. I hope to have someone on board by the end of August and started coding by mid-September if not earlier.
I just want to make some quick comments about my gut-feelings. I know when some of you read that you probably thought “Hey, you can’t make a decision like that!” Well, I beg to differ. I agree you can’t choose someone just because you like them, but you should certainly take that into consideration. If the best qualified candidate is a jerk, it might mean we just have bad chemistry, but still I wouldn’t hire him. Not ever. You can NOT work with someone you don’t like, no matter how good they are.
Another gut feeling that I don’t ignore is when the candidate says something that just doesn’t sit right with me. Maybe they tried to “pull one over” on me because they think I don’t know anything about programming or some technology or other. Many development companies make this assumption because the truth is most of their clients *don’t* actually know much about technology. But I have 25 years of experience in this business, so there’s not much I don’t know and nothing I can’t find out. Anyone who assumes otherwise is not going to get my business. I could go on and on about this, but you get my point. The gut-feeling criteria stays.
By next week I should have all the RFPs out and maybe I’ll even get some proposals back. In the meantime, I’m running an experiment by starting up a new vegetable-swapping club in my other blog, The Grouvia Groove. Check it out.
* * *