RFP: Request for Probably?
Or How to Lose a Job in 2,000 Words
We recently responded to an RFP (request for proposal) with a shocking omission: we didn’t include a cost estimate. This wasn’t by accident – it was by necessity, really.
Per our usual form, we were rather transparent and forthcoming about the fact that we purposefully did not include the very thing they requested, namely a price tag, pointing it out immediately in the cover letter:
Typically in this part of the cover letter, I explain to prospective clients that we have reviewed their site and have a good grasp of what needs to be done to solve the problems they are facing. In this case, while we have reviewed the site thoroughly, we will readily admit that we don’t have all the answers right now. It’s a big, complex website, and the only way to improve it is if our team of talented web professionals work closely with your team of content experts to produce a well-considered plan of action.
I usually follow the previous paragraph with a note about the attached estimate, but again, in this case, you won’t find one here. Attached you will find information about COLAB – our process and proficiencies – as well as descriptions of the work that is typically involved in such a project. In place of an estimate you will find some explanation of our approach to this project and why an estimate at this stage of discovery is likely to be misleading. COLAB is not in the business of disappointing clients, so we apologize for not giving you the specific information you requested, but we hope our explanations will help you ultimately make the best decision for your website.
It still remains to be seen whether or not we will win this job – we aren’t expecting to win it, actually – but it illustrates an important problem in our industry, one we face with more than half of the proposals and estimates we write. The problem can be crystallized into a simple statement: It is nearly impossible to know what a client truly needs for their website until we start working with them and digging into the details of their circumstances.
Every client and web project is different, thus the requirements for every project are different, directly making the cost of every project different. Our industry (generally) prices work based on a projected number of hours required to perform that work. The more detail we know about the work, the better the projection of costs; the less we know, the more inaccurate the projection. If we don’t have a very detailed understanding of what a client needs from the RFP, there’s a very good chance our estimate won’t reflect the costs required to build what they actually want.
Too often websites are viewed as a commodities with set prices that can be negotiated as if being traded in a market, like a car that has an MSRP price with a final sale price being negotiated between the buyer and seller. With most web developers, the reality is that a website is a bundle of services being offered by a developer in a package, and the final cost of that package depends largely on the services you choose. It’s more akin to ordering a meal from a menu at a restaurant or having your kitchen renovated – the cost will vary greatly if you order a steak with salad versus a salad with baked potato, or whether you choose granite counter-tops versus laminate in your kitchen. In other words, the costs vary based on what you want.
This is why, when a prospective client says, “I need a new website. How much will it cost?”, we can’t offer a very clear answer. It depends on what type of website you need. We could build a $100 website or a $1,000,000 website, but they would differ as dramatically as a hand-drawn stick figure differs from the Mona Lisa.
This isn’t just a problem for web developers who find themselves in difficult circumstances trying to estimate work. This is a significant problem for anyone trying to make sense of responses to an RFP. When you write an RFP and send it out for responses, you almost invariably receive a number of responses with wildly different costs attached to them (I know this from several first-hand experiences). The reason the responses tend to be so different, and difficult to differentiate, almost invariably comes down to requirements – namely, how clearly and thoroughly you have defined your requirements.
As noted previously, a website could cost $100 or $1,000,000 – the only way to know the difference is to understand how the requirements of the work differ. Here’s more from our response to the aforementioned RFP where we tried to explain this:
Proposed Technical Approach
Without detailed technical requirements in your RFP, you are likely to receive replies from potential vendors that differ greatly in cost. This is because, in the absence of specific instructions, each vendor will formulate their own approach to delivering you the website they think you want. When you select a vendor, you are really selecting a technical approach to solving the problem of how to build (or rebuild, in this case) your website. This is actually the most important decision you will make in the entire process.
We appreciate this difficulty, so we want to make our approach as clear, transparent, and easy to understand as possible.
The details of the recommended approach are what makes the difference between a website that suits your needs, and one that does not. Those details will affect how easy the site is to update and administer, how well the site works on different screens, and how intuitive the site is for visitors. Unfortunately, the details that are most important are also typically the most difficult to apprehend for those who are not fluent in the terminology of the web, which makes choosing a vendor a difficult task.
So what do you do?
The cost of redeveloping your website will follow directly from the amount of work (in hours) it takes to reorganize, redesign, and recode the site. In order to estimate that final cost, we need to be able to estimate the number of hours it will take to perform the work. This is a difficult task under normal circumstances, even with small websites. [Your website is] thousands of pages deep, each quite rich with content. Any number we estimated for the cost of redeveloping the site would be little better than a guess at this point, which is not fair to you (or us, ultimately), and would likely put both of us in a bad position because we would be working under an assumption that would probably prove false.
The truth is, you need a balance of budget, discovery, and phasing. For certain aspects of the project, you will need to set a budget and accept that there are limitations to what you can afford. For other aspects, you won’t know what you need until you starting exploring options, so your costs will be unknown until you make the necessary choices. Finally, some features may simply not be affordable now, and may need to be de-prioritized and scheduled for another phase of development.
A good example of smart budgeting is setting a design budget. The design process can go on forever, if you allow it, but after a certain point, changes to design cease to make a significant improvement in the end product. Setting limits here saves money and doesn’t pose great risk to creating a great site that serves your needs.
Good examples of discovery are the use of automation and dynamic display of content in the site. In other words, the website can apply some intelligence or logic to how it displays your content, such as displaying a list of articles that can then be sorted by subject or filtered by keywords. There are varying levels of complexity and logic that can be applied in the programming of a website, and costs can vary drastically based on those decisions. Here is where some discovery of options can help you make appropriate and affordable choices.
Lastly, is thinking about the work in phases and prioritizing the most important things to be done first, and features of lesser importance to be handled later when more funding can be appropriated.
Taking these approaches will help you get the best value for your budget, and better ensure you are happy with the end-product.
To be perfectly honest with you, we don’t know what it will cost to redevelop your website. We don’t have enough information right now, and we won’t until we’re able to sit down with your team and start digging into what you really need (not what we imagine you need based on your RFP). There is a lot of content to deal with, and probably a lot of stakeholders to satisfy, so to presume we know how to solve all the problems without talking to your team is foolhardy.
We respect that you have budgets and that you want to get the best value for the money you can afford to spend. We also respect that you have a complex and content-rich website that you need to redesign. That being the case, we don’t want to win this job by promising you a budget number if we don’t know we can achieve it and give you the site you need (and want).
What we can offer is to work with you to get the best possible end-product for the budget you have so that you get the greatest possible value for your investment.
One approach to get started, which we have used successfully in previous projects of similar complexity, is to agree on a budget (i.e. a fixed number of hours) to do the Discovery portion of the job. This will allow us to explore and define in more precise terms what work needs to be done and can be accomplished within your budget.
For example, we may set a 30-50 hour budget for Discovery, spend that time meeting and conducting interviews with your stakeholders in order to gather and document requirements of the job. After that was complete, we would then estimate the time required to achieve those requirements and present it to you in an itemized format, so you could decide which features you really want and which may be held for a later phase.
If at that point, you decided you didn’t want to continue working with COLAB, or wanted to see other estimates from other developers for the work, you would have full ownership of the Discovery documents which you could use to get more refined estimates from developers. We feel confident you will like working with us, and wouldn’t anticipate you wanting to get other estimates, but we offer that as an option.
That is a lot of reading to do for no estimate! And perhaps it was an ill-advised approach if we wanted to win that work, but the truth is, we didn’t want to win that work if it meant promising a client the world for a specific price, only to point out later it will cost double. No one is happy in those circumstances.
The important takeaway here is that, as a client, sometimes you don’t know exactly what you need, so it may be worth allocating some budget simply to discover what you need before diving into a full project budget. For developers, be as transparent as possible in your proposals and estimates (use non-technical language as much as possible), clearly outlining what is included in the cost, and maybe even what is not included if it is something clients regularly mistake or assume is part of the deal.
A functional, appropriate, and reasonably good looking website can be developed for just about any budget – whether it’s a porterhouse cut of Kobe beef or your average Idaho baked potato.