[consulting] "How to write a RFP"

[Evan Leibovitch]

Boris Mann wrote:
> Here's a secret: most RFPs aren't useful.
Well, they're not useful to bidders. Very often they're quite useful to
the publisher of the RFP, because in so many cases the company already
has a contractor in mind, and wants to tailor the RFP so that only one
target bidder is qualified while presenting the facade of an open
process. This leads to RFPs that are overly vague in places, and/or
strangely over-specific in others (ie, "the winning candiate must have
an excellent knowledge of Pascal"). The person in my company who goes
through RFPs says he has a radar to be able to tell from the wording,
which RFPs are like this (and thus a waste of time to bid on) and which
are legit.

Qualifications notwithstanding, often "comfort" is as important factor
than "suitability", with the assumption that any suitably skilled
technician (who's already working there) can learn on the job,
especially if he's cheap enough. (This is especially applicable to
software such as Drupal, promotes itself as being easy to learn and use.)

I've observed a few bidding processes in which

1) a consultant writes the RFP,
2) the consultant sits in on interviews with "short-listed" bidders
3) the consultant clues into how to do the job based on the RFPs and
interviews, then convinces the company he can do it,
4) the consultant gets the work because he's familiar, seen as skilled
"enough" while already knowing the client's needs

Completely legal, and usually considered ethical and 'part of the game'
by the client. Though I use the term "he" above, this scenario also
applies to larger consulting firms who pretend to have the capabilities,
then go scrambling to hire subcontractors if they get the job.

- Evan