Hacker News new | comments | show | ask | jobs | submit login

3/4 through this article I started wondering whether this was some kind of Swift-ian satire about the graphic design "spec work" argument. I don't think it is.

Here's the deal: it's called supply and demand. If clients have 10 quality firms to choose from, and they pay their firms enough, then building an excellent RFP is simply going to be the cost of doing business with them.

Sometimes, some firms are so good, and provide output that is so hard to match with any substitutable firm, that they get to set the terms for the client/vendor relationship. Those firms know who they are, because they have waitlists, and are already turning down clients.

If you want to boycott RFPs, by all means, get your lunch eaten by the companies who are willing to throw those two extra non-billable days at the task of making themselves extra easy to work with. But I don't think you're going to manage to demonize the RFP process the way designers have the spec-work process, because RFPs are simply the way consulting works.

> because RFPs are simply the way consulting works.

Not all the time. I never respond to public RFPs, and neither does the OP. Apparently in our (separate) niches, you can get by just fine.

Agree with your point about supply and demand, but good hackers are (nearly) always in demand, and so can nearly always find work. It's the strange outsourced companies that spend all their time searching for work that end up responding to RFPs, and that's dangerous even to clients.

Look at it this way: if you have a pool of proposals sitting on your desk, 90% of which are from firms that are simply incapable of doing the job[1], and you are a business/nontechnical chap, it's going to be difficult to find the 10% who are capable, let alone competent.

Meanwhile, technical guys who are good hackers but don't understand this see lots of firms sending out and responding to RFPs and think this is how it works, so I guess we have to do it too.

[1] http://www.elance.com/php/search/main/eolsearch.php?matchTyp...

Knowing what I know about the bill rates for the kind of work we do versus the kind of work you likely do, I'm going to humbly suggest that we're in more demand than you are (not a value judgement, just an observation about scarcity).

We absolutely do respond to RFPs, when they're for projects we want to work on or clients we really want a relationship with. And we always spend serious otherwise-billable time on proposals, even though that's the same speculative work that this article argues against.

It's important to us to be easy to work with, because we want good projects. We don't want to confine ourselves to whatever lands in the margins of "unusually liberal clients"; those clients don't necessarily have the best projects.

I read the other post referenced on this thread, and so I'll add that being able to smoke out the bogus RFPs you shouldn't waste time responding to (because they indicate inept purchasers, or, for instance, because they probably mean the client is in the tank for another vendor) is just one of those things you need to be able to do to succeed as a consultant.

Different markets lead to different practices.

I would imagine that good clients in security/pentesting fields probably have well-written RFPs, so an RFP in a market like this would be a positive indicator for a client.

In contrast, for web and iPhone projects (what I've been doing lately), RFPs are a very strong negative indicator. I have yet to find a well-written iPhone RFP.

I don't know, and that's a good question. Most security research proposals I've seen are crap, too. But then, in competitive proposal situations, we tend to win. So I'm an advocate of competitive proposal situations, be they formal RFPs or otherwise. =)

Any pointers on how to identify clients already in tank with another vendor? Being overly specific in the RFP and demanding the exact features a vendor has is a clear giveaway but I am wondering if there are any other signs.

I am new to this RFP business.

We get on the phone before we respond to expensive RFPs, and there are questions you can ask (incumbent vendors, past experience with vendors, is there a formal requirement for the RFP, or do they genuinely want real proposals, etc).

On "real" RFPs, especially if you have a good shot, you'll find the purchaser you talk to is accomodating; they'll set aside time for calls to answer questions, and they'll do a good job with your Q&A submission (as a general rule, real RFPs have Q&A phases, though note that you never know whether your Q's are going to other vendors too).

There is an old negotiating trick a bizdev guy taught me once, which is, if you want to figure out whether a deal is real or whether the other side is just wanking, figure out a reason to schedule a meeting on a Saturday. If the deal is big and the other side is serious, they'll do it. Similar idea here, although less aggressive.

If your firm's way of handling the RFP process is to simply pick up the forms off some website, mail them in, and hope, then yes, I can see how the RFP process would upset you.

That's great advice. Thank you!

If the RFP is being issued by a government agency, assume that the answer is always 'yes.'

Personally, the only reason I'd ever recommend responding to [a public-sector] RFP is if it's a hoop you need to jump through in order to formalize a deal that's already been effectively struck.

If anything I think you're probably underestimating the extent to which GSA-style RFPs are rigged. I tag-teamed a bunch of times with our FedGov sales guy at the last company I was at, and we closed deals at the Pentagon and elsewhere, and (a) the stories you hear are ridiculous (like the companies that pay, say, an Inuit to be on the board so they can get some obscure diversity credit), and (b) even our company, which had multiple tens of millions of dollars in both funding and topline revenue at the time, had to work through a subcontracting arrangement.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact