Client 101: How to Write an RFP, 2008 Edition

By Sean Carton , April 28, 2008

Way back in 2001 I wrote a guide to RFP-writing for clients. It was intended to be a helpful checklist and also (selfishly) a pre-emptive strike against getting any more byzantine RFPs (define) that took weeks to complete and resulted in bids so wildly divergent that clients often had to turn to haruspicy or other ancient methods of divination to make a decision.

Recently I got a letter from a reader who found the column helpful but had a simple question: what's changed since 2001? It got me thinking: what has changed? After all, that column was written seven years ago. Something must have changed since then, right?

Yup. A lot's changed since those dot.bomb days. We've seen online advertising take off to heights that few had predicted back in 2001. Social media has arrived and taken the world by storm. Heck, Facebook, MySpace, and Del.icio.us wouldn't even exist for another couple of years. Online video shot into the stratosphere in the intervening years, spurred on by the launch of YouTube in 2005. Broadband's gone past the tipping point, online gaming's become a multi-billion dollar industry, and more and more people are moving away from traditional media and heading online for all their news and entertainment needs. Yeah, things are a little different now then they were back then.

Even so, a lot hasn't changed, at least when it comes to building online presences for companies and working to get the word out about them. Everyone still needs a Web site, though in most cases now it's about redesigning sites rather than putting them online from scratch. Even so, many companies are still challenged by the tasks of integrating their online and offline businesses and many still are challenged by simple questions of who's going to maintain the site, how content's going to get there, and how much of the budget should be shifted to online operations.

Regardless of the hype spun by many Silicon Valley wags and tech-press boosters, my experience over the past seven years tells me that a lot of companies and organizations are still making the transition to fully dealing with how the Web has changed how they do business. While nobody asks why or if they should have a Web site anymore, many still aren't sure what to do with it once they have it.

I see a lot of this ambivalence reflected in the RFPs that cross my desk just about every day. One major change since 2001: most concerns I deal with involve operations and marketing and not technology. I don't get a lot of RFPs written by the information technology department anymore (e.g., RFPs that ask obsessive questions about server platforms and development languages). However, I get a lot of RFPs written by marketing folks who seem clueless about the day-to-day work it takes to keep feeding the beast that's the Web site or how to change internal practices to make the switch from old ways to the new. A lot of the new requests I get are big on branding and image issues but awfully light on requirements for content management and database integration. They're also pretty light on understanding how most consumers use the Web now, often spending lots of time worrying about the "experiences" they want to create rather than recognizing that people go online to get stuff done.

So yeah, a lot's changed since 2001. Here's how to deal with the new realities if you're trying to find someone to redevelop your old site or build a new site from scratch so you can get responses that allow you to judge your new potential developers:

Budget. As in "how much do you have to spend." Unfortunately this is one thing that hasn't really changed much since 2001. If you want to get bids that you can actually compare, you must give some sort of budget range in your requests for proposals. Not putting in a budget is like going to a bunch of different homebuilders and asking them to build you a house. One might come back with a proposal for a mansion and another might come back with plans for a bungalow. They're both "houses" but comparing them is an exercise in futility. Thinking that developers just "make up" prices to match budgets is absurd. How much "stuff" you're going to get depends on your needs and on how much you're going to spend. It's a much more useful exercise to compare what one company will give you for $100,000 versus another company.

Content and content management. If you have a content management system you're happy with, say so. If you're planning on developing the content yourselves (or need someone else to do it), say so. Probably the biggest stumbling block for most Web projects is the content that's going to fill the site. Before you start looking for someone to build a site for you, you'd better know how you're going to deal with your content issues. Likewise, if you have specific content management system requirements, say so. Otherwise, you might end up with bids specifying systems that could range from zero dollars for open source solutions to many hundreds of thousands of dollars. Be specific!

Timeline. Be realistic with your requested launch dates. Just about everyone puts "ASAP," but doing so is a recipe for disaster because "as soon as possible" is about as subjective as you can get. If you do have a specific launch date in mind, be specific about that too. Be realistic in your expectations. Redeveloping a site (even a small one) isn't going to happen in four weeks, unless you want a crappy site. If you have specific benchmarks or events that you have to shoot for (tradeshows, product launches, board meetings, etc.) say so. It helps a developer to know what to propose to meet your deadline.

Customer/audience profiles. Who is this thing for? What are they like? How do they interact with your company now and/or how would you like them to interact with your company. Knowing whom the site's for makes it a lot easier for a potential vendor to tailor its solution to the needs of your organization and customers. It's not necessary to include multi-volume psychographic profiles. But knowing that you need a site for 18 to 35-year-old men is a lot different than a site for pre-teen girls.

Spec work. Don't ask for it. It's rude and wastes our time as well as yours. If you want to know what someone's design capabilities are, ask for portfolios and case studies.

Your goals. Why do you want to redevelop your Web site? What's so bad about the old one? What market (or internal) forces are driving the project. How will you measure success? Knowing all this ahead of time and letting your potential vendors know is key to getting a solution that will help you reach those goals.

Your internal style. This may sound a bit goofy, but take a good look at your internal work styles and let potential vendors know so that they can give you realistic bids for project/account management as part of the proposal. Is there a single person who can make decisions? Is there a group that needs to reach consensus before a decision is made? What's the path to take something from concept to approval? Providing this information means that a vendor can tailor its project management costs accordingly. If a vendor ends up losing money during the project because every step needs a series of meetings before approval or because nobody can make a decision, it will probably start charging you more or answering the phone less.

Technical requirements. Unless you're contracting for some hard-core custom development, you don't need to spend a lot of time on technical requirements besides providing a description of the platform you currently use. If you don't care and plan on throwing everything out, say so. If you do care and you're bound by internal policies or the need for a particular technology that can be maintained internally, say so and be clear about it.

Hosting and maintenance. Do you care where the site is hosted? Are you planning on maintaining it yourself? What kind of ongoing relationship do you want to have with a vendor? If you're one of the many who's gotten burned by long-term "relationships" forced on you by a Web vendor, make sure you tell potential vendors you don't want to have any ongoing costs. On the other hand, if you want to outsource everything, make sure you tell them that, too.

Social media. Think hard: do you really need to have a blog? If you do, that's fine. But don't just start asking for things you don't know how you'll maintain or don't need. Social media has transformed the way the Web works but it's also a major commitment. Make sure that you know what you're getting into and whether or not what you want is going to be strategically necessary or just "cool." Not that there's anything wrong with cool -- as long as you understand what you're getting into.

Rebranding initiatives or other major changes. If you're about to embark on a 12-month project to rebrand your company, please say so! If you're about to change everything, I would recommend not redoing your Web site until you know where you're going. Don't think you'll get a "two-fer" by using the Web development project to drive the rebranding of the company. You'll just end up with a lot of internal hassles and additional costs.

KISS. Finally, keep it simple. Don't demand multiple printed copies, odd bindings, or whole bunch of documentation that you're not going to read. You can always get that stuff later on if you need it. What you're looking for is a concise description of what you're going to get plus verifiable evidence that the company you're going to get it from is right for the job. Get references and call them. Ask for case studies that detail both design and results. Look at work done for similar companies. It ain't that tough, but if you follow the "keep it simple" rule and ask for the things I've detailed here, you're going to end up with proposals you can compare objectively and quickly.

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.