On Being Pushy

A couple weeks ago I gave a presentation to one of my networking groups, to help educate them on what Grouvia is all about.  The purpose of belonging to this group is to expand my salesforce, so it’s important that these people recognize an opportunity for me when it comes their way.  In order for them to do that, they need to understand what problems Grouvia solves.

I haven’t been getting much in the way of referrals from this group, so I really worked hard to come up with some compelling content to present, and at the end of the presentation I gave them a 10-minute homework assignment.  I provided explicit and easy instructions on how to sign up for Grouvia, create a group, and add two small pieces of content.

Guess how many people got all the way through my step-by-step 10-minute assignment?  Go ahead, guess.

TWO.  Pretty pathetic, right?  Out of 25 people, I think about five people actually bothered to give it a try.  Three gave up without ever asking me a single question.  One of the people who completed the task is my business partner.  The other person who did it is the secretary of the group.  So here’s my public thank you to Betsy and Tom for showing some spunk and commitment.

I have come to the conclusion that people will not do *anything* unless you push them.  And I mean really push hard.  I think in my case it’s because people are afraid of new things, web applications in particular.

Many of the people in my audience are not best friends with the http://www.  I would be willing to forgive those people.  But I’m talking about the ones who DO have Facebook accounts and Blackberries.  This should be easy for them.

Why do they resist?

Have they been fed so many bad complicated ugly web applications over the past 9 years that they expect everything new to be bad, complicated, and ugly?  There are many new Web 2.0 apps out there that are outstanding.  The problem is they are not ubiquitous.  The vast majority of web sites still suck.  But when the tides turn, and people start having confidence in the web again, Grouvia will be right there waiting.

* * *

Do you enjoy reading these posts?  Subscribe to the RSS feed of The Making of Grouvia.

You can become a member of Grouvia and create your own group in 5 minutes or less.  Sign up for an account at http://www.grouvia.com.

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.

* * *

Request for Help Falls (Mostly) on Deaf Ears

Earlier this week I posted a message on a couple of my LinkedIn discussion groups, asking for people’s advice on how to write an RFP. The question itself was fairly simple – I was asking if there is a good way to write an RFP without divulging the full set of requirements. I believe I have good reason for wanting to keep these details private at this early stage of the project.

Here is the measly set of responses I got:
1 – the person responded on topic, but did not address my question
2 – the person asked to be on the list of companies to bid on the RFP
3 – the person said it is not possible to bid on an RFP without the full set of requirements.


Granted, I did get an acceptable answer from person #1 after I responded back saying thank you for your advice, but what about my question.

So here’s this supposedly great resource that LinkedIn offers in the way of support for people helping people, and out of maybe a couple thousand members in the groups I posted this to, I get three responses, none of which are helpful. So I feel like standing up and saying, HEY! where is everybody??? Is everyone just so absorbed by their own problems that they can’t spend a minute to reach out to help someone in need?

So anyway… the answer I gleaned from person-#1-round-2 and the here’s-why-it’s-impossible response was this — writing an RFP at an extracted level is probably fine, as long as I understand that the proposals I get will be estimates only and will need 10-20% of padding added to the final price. I’m fine with this.

Having never written an RFP before (although I’ve responded to many in my past), I went and found some examples of software development RFPs online. Unfortunately they’re from huge bureaucratic organizations (one is from the State of California) and filled with TONS of legal mumbo jumbo. But, you get what you pay for, so now I have to spend some time wading through the best one I can find and tearing it apart and revising it to work for Grouvia.

On the upside, the Grouvia design is done and the functional requirements are mostly done – yay! At least they’re done to the point where I feel confident about having enough information from which to create an RFP. Too bad knowing this doesn’t help me sleep better at night.

* * *