Looking at alternatives to the broken RFP process
We get asked to answer RFPs for projects on a semi regular basis, and occasionally will pursue a particularly good looking RFP out in the wild if we think it fits our work. Most RFPs we see, however, are really, really problematic. This post by Jonathan Wold echoes the feelings that I’ve heard from many colleagues over the last couple of years. A lot of what is typically asked for in an RFP is either impossible to estimate with any accuracy because of variables that can’t be known without some serious research, or R&D work that should really be paid for as a service to the client. Blair Enns’ Win Without Pitching manifesto has gained significant traction among designers and developers who like to remain profitable and in business.
Given this growing anti-RFP climate, I decided to write a post that is targeted not at my fellow designers and developers, but rather at the businesses who are going to need to adapt. Organizations looking to get work done by highly qualified designers and developers are going to need to rethink how they go about hiring. The good news is that this is actually good for business.
To clarify – this article is not for small businesses seeking business card or brochure websites. Those problems are largely solved. This article focuses on mid-sized businesses and organizations that have unique content or complex needs not met by standard out-of-the-box websites, and are trying to get a good site built to serve their needs. I’m talking about the $30,000-150,000 ballpark range – folks that want a lot, but don’t have limitlessly deep pockets.
Why should I pay for what I can get for free?
Many businesses go on the assumption that if they can get it for free as part of the proposal process, then they’ve gotten something of value. This is rarely true to any great degree. When a developer puts a bid in on an RFP, they’re limited by the amount of time that they can devote to the proposal for free. If a developer is good, they’re probably also busy. That means that your job is probably not as big a priority to them as the job they’re currently getting paid to do. The estimate you get is going to be based on guesswork about your needs that haven’t been thoroughly investigated. In other words, it’s probably not going to reflect reality once the project actually gets started, or by necessity will be so heavily padded that it will be profitable no matter what.
Why should I believe you when someone else tells me they can do it faster/for less?
Frequently our experience has been that when we take the time to do a serious analysis and accurately price the job, we get turned down because someone else underbid us in either price, estimated time to complete the project, or both. And without fail, when we check back in later, the site is not launched on the projected schedule. We have not had the cojones to ask whether it was done on budget, but if it’s late, it’s costing the client money whether that money is going to the developer or not. This has led us, and many other designers and developers, to begin to reject the pitch process in favor of other ways of winning business.
When we do pitches, it’s generally because we’ve really liked the project and are willing to invest some time to engage with the client to understand their needs. That makes it all the more difficult to hear “we really like you guys and want to work with you, but you were underbid by 40%, and the team that’s bidding says they can deliver a lot faster.” It’s hard because we want the job, of course, but also because we know that the client has made a bad decision that will bite them in the ass. We’ve had two experiences like that recently: one new client was very interested in working with us, but would not believe it when we said “what you’re asking for is not possible even with 5 times your budget.” Their goal was to launch by November 1, 2011. It was mid-June, and it was a project that wanted nine months to do comfortably, six as a rush. Our proposal had a phased launch plan. Another team said they could do it for 35% less and could meet their Nov 1 deadline, and they went with that team. With a sad heart, we said “good luck, please let us know if you need help down the line.” It’s now almost March 2012, and they’re still not launched. In another example, an existing client decided to take their site to someone else. I just checked in with them a year and a half later after noticing that they had the same “coming soon” splash page in place that they put up 18 months back. Apparently they had been through the wringer.
In short, when a development studio that has loads of experience tells you “it can’t be done,” it’s worth considering that it might not just be them trying to sell you their version. They might actually be right.
How can we get better, more accurate numbers?
Instead of asking a bunch of developers to submit proposals for free for your project, select one or two favorable vendors and ask if they’d be willing to do an in-depth evaluation of the project… for pay. The research phase of any project is generally about 10-15% of the budget. So instead of trying to make a decision based on some half assed quasi-research slammed together in between projects, engage a developer to do the the research work up front in a way that will be useful to the project. The deliverable at this stage is a document covering the results of their research (formatted in a way that can be used to solicit competing bids) and an estimate to proceed with phase 2. A good developer will probably be happy to provide an analysis because a.) it’s not costing them any money – it’s actually paying them money; b.) it gives them insight into the project that will allow them to form a very competitive bid for the second phase of the job. From a business standpoint, it’s a win-win scenario: the developer is able to get paid to do what they do best, and the client is given a detailed roadmap that they can then show to other developers to get competitive bids in an apples-to-apples comparison for the actual work that needs to be done.
Of course, this needs to be a transparent process: the developer doing the research needs to understand up front that the evaluation is not a guarantee of more work. But if they’re being retained to help the client clarify the project, not to do the whole job, this should never be an issue. Alternately, you can avoid conflict of interest by making it a condition that the evaluator is not allowed to actually bid on the project, so they become a truly neutral advocate for your project – you can even ask them to help you pick a developer for phase 2.
Solve common problem areas
This process can help to build you a proper scope of work that allows you to avoid putting out a crappy RFP that qualified vendors will hate to bid on. The biggest problem areas that we typically see in an RFP are:
RFP closes in (very small amount of time relative to scale of job)
When we see an RFP for a job that has a $90,000 budget, has poorly defined scope, and the process has one week for questions, and is looking for a response in three weeks, we can be pretty sure the client either isn’t serious about wanting qualified proposals, or doesn’t understand the scope of their own job. A well defined scope, on the other hand, should be relatively easy to estimate. You’ll still want a fair amount of time for your potential vendors to read through and process the evaluation, but it’s much easier to estimate something that’s well defined.
No specified budget range, no clear feature list
If you don’t give at least some indication of the range you’re looking to spend, or a very detailed specification, it’s impossible for a developer to have any idea what the limitations of scope are and how much work to put into the proposal to balance the risk with the potential reward. If I know exactly what a client wants built in great detail, I can price it out pretty specifically. If I know how much the client wants to spend, I can define the features that will go into the project in pretty good detail. But not knowing either means that I’m taking a shot in the dark, and very likely wasting both my time and the client’s. For that reason, releasing an RPF with minimal scope while not disclosing a budget is an amateur mistake when it comes to attracting qualified responses.
You can avoid this by getting the evaluation done and looking at the resulting estimate as a starting point for ballparking the project. Instead of the dreaded no scope/no budget RFP, instead you can present a well defined scope of work and target budget. That will gain you many more qualified responses than the opposite.
Asking to evaluate 3rd party options for integration as part of the proposal
There are loads of 3rd party tools to do almost anything you could possibly want to do, from mailing lists to CRMs to specialized content hosts and much, much more intricate systems. These tools have varying degrees of support for integration with a range of website CMSes. Aside from the fact that it often takes many hours of research to even identify good 3rd party options for a given set of functionality, without a solid understanding of the business logic behind the need for the tool it’s usually impossible to make any kind of a recommendation as to which one would be appropriate. Being able to make those kinds of evaluations is a skill. This kind of knowledge is hard earned, and comes from spending lots of time doing what we do. Parting with it as a throwaway piece of an RFP response devalues our knowledge and experience, the very reasons you’d want us to answer your RFP in the first place. What you need is a technical consultant to perform diligent research for you, not a proposal that’s got a goal of getting a foot in the door without understanding your actual needs.
Deep content analysis without context
As websites grow in size, complex relationships often form between the various pieces of content that make it up. As a site’s feature list grows linearly, the complexity usually grows exponentially as each type of data is cross referenced with each other type. Beyond a certain size, it’s impractical to estimate how different custom features will work together, and how much it will cost to integrate them without spending a lot of time wrapping our heads around the way that content will interact and how this works with the needs of the client. This is really R&D for your business, and should be considered as such, not left to the folks responding to try to ballpark (and usually failing miserably).
Brand new, never before seen features
When you have a new idea for something never seen before, chances are it can’t be estimated. Proof of concept? Sure. But anything new will need to go through several rounds of iteration before it’s solid, and there’s no way to know exactly what that will entail. So rather than trying to get a firm quote for a brand new feature, start small and realistic: get a proof of concept built to understand the areas where it will require more work. Then use the proof-of-concept to help define the scope of a more refined version.
So what now?
When you’re starting to plan your next big web project, think about changing how you handle the process. Look for references like you usually would. Find the shop that you would love to work with if only you had unlimited funds. Then see if they’re willing to get on board for a smaller phase 1. If you’re a good client and have a good project, my bet is that few developers would turn their noses up at a chance to engage with you. And if they do? Call us instead.