Since our decision only two weeks ago to stop responding to RFP’s we’ve gotten a number of questioning e-mails and phone calls ( understandably, perhaps, given the ubiquity of the Request for Proposal ).
One-by-one I’ve been attempting to explain to each questioner our new position and, invariably, some will ‘get it’ and some will not ( the latter due, of course, to ’same language communication issues’ – a subject for another time ).
The notion that all software development companies can be viewed as equals ( i.e., each having an equally talented and proficient staff of engineers ) is obviously flawed, yet this is exactly what RFP’s assume; it only follows, then, that the idea of selecting a firm based on info contained in a response to an RFP ( as opposed to researching different firms, spending time getting to know a few, contacting some of their clients, learning about their reputation, etc. ) is inherently flawed as well.
Just this morning, in response to one of my e-mails explaining our position, I got this:
Take my advice for what it is worth (the worse [sic] vice in the world is Advice): Answer RFP’s it [sic] is similar to going on added [sic] interview, it cannot hurt…
Here’s the thing: answering RFP’s thoughtfully and estimating the effort involved in a software development project with even a moderate degree of accuracy takes significantly longer than a second or third interview ( or even all the interviews combined, for that matter ). The alternative to this time-consuming effort is, of course, ‘the easy way,’ and as with most endeavors, choosing the easy way typically provides for less-than-optimal ( I’m being kind here ) results.
Be that as it may, however, the easy way is far-and-away the approach most often taken when answering RFP’s; we’ve seen a number of proposals that were clearly piece-mealed together from bits of previous proposals as well as information gathered from the Internet. In some cases it was difficult to discern how the proposed solution would achieve the desired results, and contrary to the Advice I was given above, this does hurt – and in the most painful ways: it results in wasted effort and increased stress on both sides and invariably leads to misunderstandings ( at best ), and disappointing ( and very often unacceptable ) results ( at worst ).
Unfortunately, in the vast majority of cases, the problem lies with the RFP’s themselves – most are ill-conceived and rarely outline solutions that are the most cost-effective/efficient; moreover, they almost always fail to paint a clear ( and true ) picture of the problem(s) the client is trying to solve. ( We routinely dismissed 95% of RFP’s as ‘unanswerable.’ ) Also, the notion that there would only ever be a need for a single question-and-answer round for an RFP is, frankly, ludicrous – has learning the answer to one question never led the minions who broadcast RFP’s down a path that begs additional questions? Really?
Listen, here’s a radical, out-of-the-box idea for those of you who may be considering developing an RFP for your web application but are not application architects or even software engineers: get help from professionals. I know it sounds crazy, but before you reach for that RFP template consider for a moment how much working with someone who does this for a living would increase the odds of success for your project; I submit that a partnership of this nature will not only help you solve the problem(s) you’re struggling with, it will also save you a significant amount of time, effort, and unnecessary stress, both now and in the future.
Before we decided to ‘stop the madness’ we routinely spent 30-40 hours on our proposals ( and often more for larger projects ), only to find that the pointy-haired bosses of the world were too easily swayed by dazzling sales pitches and ( unrealistically ) low quotes. Our position is this: if the work we’ve done and the reputation we’ve built to this point is not in itself enough to get us considered for your project, then we’re happy to leave it at that. If, on the other hand, you’re sufficiently enough impressed with our track record to ask us to invest 40 hours developing ( what amounts to ) a preliminary design document and providing a truly accurate and reliable quote ( regardless of whether or not it’s more than you expected ), we’d be pleased to do that as well, but as professionals we expect to be compensated for our time and effort.
So, yes, yes – we’ll answer your RFP already – just be sure to include a check along with it. This will be a clear indicator to us that you’re committed to the success of your project and your priorities lie firmly on the side of substance and results, not fluff and BS. Make sense?
