Client 101: How to Write an RFP, 2008 Edition

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.

Related reading

women-in-tech
nurcin-erdogan-loeffler_wikipedia-definition-the-future_featured-image
pwc_experience-centre_hong-kong_featured-image
12919894_10154847711668475_3893080213398294388_n
<