Choosing My Million Dollar Development Team

This past week was spent collecting proposals for the grouvia.com project, in response to the RFP I sent out last week. I had about a dozen early candidates and two dropped because they didn’t feel they could respond within the very short timeframe I required.

I suppose if I had to do it again (you’d have to put a gun to my head) I’d change my RFP to request that each company put their proposal in a specific format. One of the biggest challenges I found was having to “re-frame” each proposal into a common format so I could put them into kind of a mental comparison matrix. I don’t know if I succeeded that well, and I think when it came down to it I went with my gut feeling about which proposals would ultimately rise to the top of the list. But I believe strongly that gut feelings are generally based in some fact. So after reading each proposal carefully, I had a good sense of what kind of company this was, and whether I felt strongly about them one way or the other.

The three that have made it to the short list are quite different from each other. They each suggested different technologies, they have different approaches, and different personalities. The longest proposal (of the three) is 40 pages long and came with 10 supplemental documents. Another one was seven pages long and I had to go back and ask for some missing information. How am I supposed to interpret that?

BTW I didn’t hold it against any of them for missing information. My turnaround time was very short and they did their best I’m sure. I merely asked for it and they gave it to me.

So here I am with a decision due tomorrow and feeling a little paralyzed by indecisiveness about three major factors:

  1. Drupal vs. Symfony (I know, I know, they’re not the same type of thing!)
  2. Eastern Europe vs. India
  3. Hourly vs. fixed price – there’s more to this but it’s too much to go into here.

Did I mention that none of the US companies I asked to participate responded? The overwhelming majority of the firms are from India. One was from Sweden (they dropped) and one from Ukraine. All their english skills are good, they all offer US based phone numbers, they all work late hours to compensate for the time zone issue. None of the offshore issues are really issues, to me at least. And the prices are all very close, and all within my budgeted range.

So I guess I’ll have to keep you in suspense until next week. If you have any thoughts or commments I’d love to hear them!

* * *

Advertisements

A 5-Step Process for Creating an RFP When You Don’t Have a Clue

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

* * *

Group Tools Revealed

I finished crunching all the survey data. What it all boils down to is two major findings…

1. What features people believe would be most useful to them.
2. What tools people now use, or have used in the past, for their own groups.

Features

Item 1, the prioritization of the list of features, is interesting but not very exciting. We generally found that most people didn’t care much about personal blogs, circles of friends, external calendar entries, anyone can join type groups, and carpool support. So all of these items have been removed from the 1.0 feature list.

There were a couple of other features that fell just above the line, so we have added those to a “Possible Descoping List” to consult if the project starts to run over and we need to reduce effort.

Tools

Item 2, the tools people use, was quite an eye opener! For the past few months we had been planning on gearing our marketing materials on comparing our features to our major competitors’ features. We did a competitive analysis a while back and found a handful of web apps that support clubs, teams, families, and other groups. Most of these sites are ones we had heard of but didn’t have much personal experience with. The list included sites such as Wild Apricot, eTeamz, Active.com, ClubExpress, etc. These are the big players for the most part.

After extracting and analyzing the complete list of tools people used, it occurred to me (it actually hit me over the head like a brick), that we have been focusing our competitive marketing efforts in the WRONG PLACE! Here are the top ten mentions from our survey:

Email – 50%
Group web site – 25%
Yahoo Groups – 19%
Facebook – 19%
Meetup – 13%
eVite – 13%
US Mail – 13%
Telephone – 6%
Outlook – 6%
Forums – 6%

Facebook? REALLY?!?! Ok, yeah I’m dramatizing but I was truly astounded. Now, email makes a lot of sense, and can actually be an integrated part of another tool, so I have no intention of trying to compete with email. People love email and it won’t go away any time soon. Email will be a big part of the grouvia solution.

I think the biggest WOW here is more relief than anything. Not one single “big player” web site was mentioned. Which means… I think… that we don’t have to compete with them – at least not at first. They are not in this space. I also believe that Yahoo groups, Facebook, group web sites, Outlook, and Forums will be relatively easy competition to beat. Meetup could be a little harder. Mail and telephone I won’t even try.

Can you tell I’m excited?

Next week, a new topic! I’m sure you’re as tired of survey results as I am, so I’m happy to get on to something new.

Happy Independence Day!