Client 101: How to Write an RFP

By Sean Carton , December 5, 2001

One of the biggest disadvantages of being in the Web biz is that we're all still figuring out how things should work. Even though the business has matured somewhat over the past five or six years, the practices still aren't anywhere near as cut and dried as they are in, say, the traditional advertising industry. Nowhere is that more apparent than in the Web development request-for-proposal (RFP) process.

In the ad biz (or construction or chemical procurement or just about any other business that's been around for a while), the whole RFP process is fairly standardized. Companies looking to hire a vendor for a project (or for a long-term relationship) generally know what questions to ask so they can get the data they need to make their decisions. Vendors, knowing that they're being asked the right questions, know how to respond in such a way that the potential clients get the information they need. Sure, there are always plenty of creative showdowns, and backroom politicking is inevitably involved, but generally everybody knows what to expect. Because they know what to expect, they're free to expend their energies on being creative.

But when it comes to Web development... watch out! Because clients don't know what to ask, they often don't get the answers they need to make intelligent decisions. Because the potential vendors don't get enough information, they're forced to guess, and they come up with responses that don't help the prospect. The result? Everyone goes home unhappy, and clients end up with vendors that are too expensive, too inexperienced, too mismanaged, too big, or too small for the job. In the meantime, all the vendors who bid on the job and didn't get it wasted inordinate amounts of time responding to something they had no chance of getting.

What to do? The answer will come from understanding -- clients understanding what Web developers need to respond, and Web developers understanding the needs of their potential clients. Better understanding equals better responses equals better matches equals happier clients. It's a simple equation that equals "win" for everyone.

So, dear client, what do we developers need from you to make sure you are comparing the proverbial apples to apples (as opposed to those dreaded oranges)? Here are 10 humble suggestions that'll make everyone's life easier:

• Budget. Yes, budget. Money. As in, "How much you got?" In about 90 percent of the RFPs I get, there's no indication of how much the client wants to spend. The result is a little like playing "Battleship." The developer guesses blindly as to the client's needs. The client responds with a "Hit!" when the number is somewhere within the magical range or a "Miss." when it's too high (proposed budget numbers are rarely too low).

  Why does this happen? Many clients have the mistaken perception that since Web development doesn't involve a tangible "product," the price is infinitely variable and that, given a number, all developers will inflate their prices to reach that number. Baloney. Things take time. Software costs money. People have salaries that need to be paid. You'd be surprised at how similar most companies' rates are. The only way to have an understanding of how much stuff to propose is to know how much money the client has to spend.

• Scope. If you don't feel comfortable saying how much you have to spend, at least take the time to sketch out the scope of the project. To use the old hackneyed analogy, we're like homebuilders. If you tell us you want a house, we'd at least like to know if you want a shack or a mansion. And if you don't know the scope, that's fine, too. Make a requirements phase the first item on your wish list so that the company you pick can do some research to tell you what you need.

• Speculative creative. Yes, this has been standard operating procedure in the ad industry for years. It sucks. Let's learn from the mistakes of the past and not repeat this onerous practice. First, it degrades the value of design. Secondly, it forces the better shops (those that routinely take a more strategic focus) to create design without any knowledge of you and your customers. The result? Design for its own sake. Decisions based purely on aesthetics are usually bad ones because of their subjectivity.

• Technical requirements. If your company has a religious commitment to Microsoft products, say so. Likewise, if your company worships at the altar of Linux, be open about your preferences. If you need database integration with a certain back-end database, tell us what kind of database system you have. It doesn't do anyone any good to play the technical requirements guessing game. If you let your potential vendors know what you need, you'll be sure to get answers you can compare.

• Marketing versus IT. Which is more important? If your IT department has the upper hand in picking the vendor based on technical expertise, say so. If the marketing department is running the show and wants a more strategic focus, make sure that this is something that your potential vendor knows -- and one you know yourself. Self-knowledge about this issue is vital in putting together the short list of vendors: Don't ask systems integrators that focus on back-end issues to bid against high-end, flashy design shops. You'll have a very hard time comparing the responses.

• Content and content development. Do you plan to reuse all the content on your existing site (basically just doing a face-lift to your current site), or do you want to start from scratch? Are you looking for a Web developer that can write the content, or are you planning to do it yourself?

• Maintenance and a long-term relationship. Who's going to keep the site up and running once it's launched? If you're planning to maintain content, are you interested in a content management system? If you want an agency to work with you on a long-term basis, how do you want the relationship structured?

• Third-party software. Where do you stand on third-party software? Do you want custom applications or off-the-shelf solutions? Do you own licenses for the software you want to reuse? If you don't want custom apps, say so. It doesn't do anyone any good to guess about this. If you don't mind custom apps, do you want to own them outright or license them?

• Partnerships. Where do you stand on partnerships? Does the company you pick have to do everything in-house? Many companies these days are specializing in one aspect of development or another -- some do back-end integration work, others focus on design, some do consulting, and others may just do content development. Do you care if that's all done by the same company? If you do, please say so, and let your potential vendors know that in-house capabilities are a condition of the contract. If you don't care, make sure you find out who their partners are and who to contact if things go south. Make your primary vendor ultimately responsible.

• Know thyself. Finally, take a good hard look at your company and make sure that you communicate any idiosyncrasies that you may have. If you know that any development process will involve a lot of time in committee meetings, don't be afraid to say so. If you know that certain key dates have to be met (board meetings, conferences, etc.), lay them out so that you can get a development schedule proposal that works with your dates. You'll end up with responses that address your issues and schedules that work with your key dates.

Back to Article