As one of the owners of BlueBolt, I have had the pleasure of answering to a number of client RFPs (Request for Proposals) for website development projects. The problem is that there is no “industry standard” RFP to work from or compare against, either for the creator or the submitter. So in the past seven (7) years, we’ve seen only a few that have been tailored to solicit contiguous, comparable responses. For this reason, I wanted to share some of my general thoughts on how to determine important technical questions, how to get responders to properly format the document, and how to provide enough information about your business to get the most relevant feedback.
I am breaking my Blog up into a 3-parter, and will follow a schedule:
Part 1 – This is it!
Project Pricing vs. Project Risk – Budgetary considerations
Part 2 – written on 02/24/2012
For the RFP Writer: Project Definition and RFP Format specification
Part 3 – written on 03/13/2012
For the RFP Respondent: Project Scoping and Preparing a Response
Budgetary considerations (for a web development project). There is nothing special about web project work (vs. other service oriented work) for where the components can’t be broken down into bite-sized pieces. In brief, the estimator must determine effort for each piece (usually in hours), come up with a workable cost/hour, add a fair profit margin, and then provide a cost that everyone can understand and agree upon. This assumes that the RFP respondent can determine client expectations from the information provided. But, a caution: This assumption may not be valid. At the project onset, it is possible that the prospective client simply does not have insight into what they need.
Ok, so how might a prospective client, and the prospective developer start to agree on costs/budget, even if project unknowns exist? Here are four (4) options for costing website projects. The percentage represents the approximate frequency that we respond with each option.
Fixed bid (60%)
The developer simply dives in, attempts to understand as much as possible in order to scope the work, and agrees to accept the risk for unknowns. This is typically the most expensive way for a client to involve a website development agency because the developer generally must make many assumptions and has to build risk into those costs. Depending on the trust level between client and developer, Fixed Bid proposals could also present risk to the client.
Time and Materials (T&M) (15%)
T&M bids usually yield the lowest client costs, because the developer has no reason to add a risk quotient, and the developer only takes on the project work assigned to them, or where needed most. This is an ideal way to work with a known developer, especially when budgets are tight or when some level of the project work can be taken on by the actual client.
Hybrid: Fixed Bid + T&M (20%)
At BlueBolt, we often provide Fixed Bid costs for RFP proposals. For functions like project management, meeting time, hosting installation, advanced SEO and keyword analysis (unless it is specified in detail), and other items that are auxiliary and difficult to estimate, we add time to the quote and disclose the purpose. Using a hybrid costing approach, the client only pays for hours used. So, we limit a portion of the hours built into our proposal, offering T&M to hours for functions beyond the scope of the project. We think this benefits both parties, both from a risk and a cost perspective.
Client Budget Abdication (5%)
We see this only rarely, but I believe it may be the best approach, especially for clients. Basically, the client provides system requirements, along with a functional specification, and those items act as a sort of ‘wish list’. It is best if the client prioritizes those items, and once done, the client simply shares the budget with all prospective respondents. In this case, the vendors have to be the creative ones, adding as much value as possible in order to attract the most attention and interest to their proposal. As long as the basics are outlined in the provided scope, this takes the price-guessing game out of an RFP response, and allows the developer to think about how much effort (and in what creative ways) it will take to build their solution at a set cost.
It should be remembered that some organizations only value fixed bid project proposals, asking their vendor prospects to accept all the project risk. That is no problem for BlueBolt; but, it should be realized that the more complicated the project, the more that risk gets multiplied and higher costs often accompany the effort and the risk.
Other organizations prefer developers to act as an extension of their own team, and those groups usually prefer T&M proposals. They challenge their internal project managers to closely guard the hours spent to assure they appropriately manage the costs being assigned. This is a great approach as long as the vendor is able to effectively communicate project hours, and managers of the client staff are realistic about project complexity and associated costs.
In Part 2 of my series, I will discuss the things clients might consider in writing website design and development RFP’s, what information is needed for a respondent to accurately scope the work in order to successfully take on the project, and how to make sure respondents format the proposal appropriately, for best comparisons between proposals.