RFP Website Design: Rules of Engagement

Crafting it correctly: Writing the perfect RFP website design request

You need a website designed. Luckily for you, there are dozens and dozens of Web design and development firms who want to finish it for you. That’s pretty exciting! The next step is getting in touch with those people, and that means taking one of two paths: either a lot of phone calls and emails, or you can let them come to you by writing a request for proposal (RFP).

The RFP is one of the most popular ways to get bids for your project, and there’s a certain science to writing a really good one. In a way, its like a game of Jeopardy; you provide the answer and your respondents provide the question. The difference is that Alex Trebeck isn’t behind the podium. You are. You have to know exactly what you need, how much is in your budget, and the amount of time to complete the project. Otherwise, the dozens and dozens of firms who want to do your website won’t know what they’re making.

Get the RFP Toolkit

Includes: glossary, checklist, and more

  • This field is for validation purposes and should be left unchanged.

Crafting an RFP website design plan correctly is about getting back to basics.

1. Know Your Budget

Money is a finite resource. That’s why it’s money. Your project has a budget, and understanding how and where that money will be spent is integral for success. When writing your RFP, you should know where every dollar is headed. Outlining it in the RFP will let you, your bosses, and your potential contractors know what is being spent, where and when. This eliminates potential confusion before it starts. Otherwise, your RFP Web design project is an invitation to disaster.

2. Where Are You Going With This?

I’m willing to bet you have an idea in your head of what success on your project will look like. One of the biggest hitches when writing RFPs is that authors forget to effectively translate that idea into the RFP. This lack of focus complicates every step of the process. Without proper definition in your RFP, you will end up wasting time reading responses from under-qualified firms, potentially leading to ballooning budgets and unmet deadlines. Lacking a structured and focused plan wreaks havoc on a website design project. Envision what a successful projects looks like, and then translate that vision into your RFP.

3. Deadlines Are For Real

Speaking of unmet deadlines, your RFP should establish all benchmarks and deadlines as clearly as possible. When they aren’t clearly defined, some designers and developers will try to push additional work. This means extra hours — hours that you aren’t budgeted for. It’s a trap you don’t have to fall into. Make sure your deadlines are firm and real and clearly defined to your respondents.

4. Do Your Own Research

The reality of the RFP process is that you are writing and submitting the request precisely because you need help. If you didn’t need help, you wouldn’t be asking for — well, paying actually — people to be part of your project. Don’t fall for the kinds of Web design buzzwords that your RFP respondents will use to impress you. Do some research about your project ahead of time; the more you know about your project, the better. Will it take a little extra time on your part? Yup. Is it worth making sure that your RFP respondents aren’t leading you down paths that you — and your budget — don’t need to take? Absolutely.

5. Seeing Is Believing

You have a picture in your head of what you want your website to look like. Why would you have design firms try to guess what that picture looks like? The more information you can include in your RFP, especially pictures, the better. Diagrams, designs, even drawings on the back of a bar napkin can all help the final product match up with what’s in your head.

  • zkatkin

    #1 and #2 – Excellent points, wrote a similar article recently: http://www.atilus.com/website-rfp-request-proposals/ and these are some of the biggest mis-steps in the course of RFPs. Organizations should definitely list a budget and need to be more clear on the goals or objectives of the project, instead of the technology.