Repsonding to RFP’s
Tuesday, July 22nd, 2008At Refactr we don’t often get RFP’s (Requests for Proposals). Most of our consulting project work comes from word of mouth and referral where we help brainstorm what is to be created at the outset. It is the only time in a project where there are routinely meetings for more than an hour - a time of much personal interaction. I would say that sending out an RFP, sends an entirely different message. At best, it is impersonal and puts up walls that must be knocked down. More seriously, when it comes to software development projects at least, RFP’s can set the stage for failure.
An RFP attempts to describe and document the project. The first part of this (to describe) is good, but the intent for an RFP to do anything other than get some ideas down and start a dialog between the stakeholders and developers* is misguided. An RFP is drafted prior to development, when the least amount of information is available and with a small subset of the whole team in place.
Another side-effect of the RFP process is the creation of a mindset that software development is something that happens to an organization by an external source. Software development should be one of the most collaborative endeavors into which businesses enter. Stakeholders and developers should work side-by-side in designing the software, customers and those who use the software should be involved in the use-and-feedback loop.
To underscore the idea that RFP’s are simply the “hello” to a longer conversation, we often informalize the process right up front by meeting in person and responding with text emails rather than fancy Word or PDF file proposals. Our hope is that this helps to establish a new tone for the project and have found that when formality dissolves away, real communication happens.
* The terms developers and software developers are used here to encompass all people who develop software including visual, information, and interaction designers, client-side coders, server-side programmers, etc. I could also have used software designers to mean the same bunch of folks.

