What is an RFP (Request For Proposal) Anyhow? And Should I Even Care About Them?

An RFP is a Request For Proposal. They can be put out by any company or organization, but they are most common in a government agency situation where they are looking to have multiple bidders each propose their own solution to the problem that is presented.

An RFP is typically just a Requirements document that the requestor is then looking for companies to submit a proposal that provides details on their particular solution that they would implement if awarded the contract.

A guy I had worked with a couple years earlier called me up to see if I was interested in joining him and another guy in responding to an RFP that had been published on the Colorado website. Colorado has set up a joint website that many of the state government agencies participate in, including the Department of Transportation, who had released the RFP we were discussing.

In this particular case the requirements document that the Department of Transportation published as their RFP was at a fairly high level, so there were a number of areas that will need to be fleshed out further as a part of the project itself, but that is pretty common.

The Proposal is quite a bit of work in and of itself, and while you are building the response, you have no idea if you will even be chosen as the winning bidder, so that can be a little unsettling. If you put together a good response like we did, then it makes you feel good and that you did a good job even if you don't end up winning.

Like everything else in life, gaining experience is valuable all by itself. Putting together this response was good experience for the next proposal even if we don't win this one. It also gave the 3 of us a chance to work together building our response so it wasn't all just on my shoulders, which is how my other RFP responses have been, so that was a nice change.

I have responded to a couple RFP's and the hard part is that you are basically competing on price. They use the $ as their apple-to-apples comparison frequently with little input from the other factors, like experience in the specific skill sets required or capability of actually performing the tasks that will be part of the project. I lost out on a Proposal one time because a company that was totally unqualified from a technical perspective put in a lower bid, but that story is a whole topic by itself so I will leave it alone for now.

Occasionally the RFP will include a maximum budget available for the project, but more often it will not. In cases like this one where there is no budget specified, the responders have a more difficult time in deciding how much work there really is and therefore how they are going to charge for their proposed solution to the RFP.

In our case, what we did was propose a Time And Materials contract, which is basically that we would get paid based upon an hourly rate for every hour worked. As part of this particular Proposal, we identified a number of different roles for the project and then assigned a bill rate to each of the roles.

We also identified a level of effort each of the roles would be expected to participate on the various portions of the project. Sometimes this strategy is used to come up with a blended rate, which is then presented as a single rate for the project.

Part of the reason that we structured our Response in that fashion was that they are requesting the project be run in 2 phases, a 1st phase that will solidify the design and overall architecture and then a 2nd phase that will implement the solution using an Agile project management style.

Agile in case you aren't familiar uses an iterative approach in short "sprints" or iterations. It takes small chunks of functionality where each chunk is typically end-to-end and can be deployed into production at the end of the iteration. A typical iteration duration is 2-4 weeks.

Now if they truly wanted an Agile project management, the design and architecture wouldn't be split into a separate phase, but would be implemented as part of each iteration throughout the whole life of the project.

By doing the project split up in this manner, they are actually breaking one of the primary tenants of Agile methodologies and it will likely make their project less successful and will definitely make it less flexible, which is one of the huge benefits of utilizing Agile methodologies in the first place.