So, you’ve been assigned the “wonderful” task of putting together the RFP for your new website.

More often than not, this process usually begins with a single person, mentioning a casual idea over stale coffee and donut shop goodies, and then someone else across the table says “Yeah, you should look into that… maybe do an RFP”.

Now what?

Well, as someone who has spent just over 15 years reviewing and responding to various-sized RFPs, I thought I would put together a few thoughts on how to make the most of this process – even if you’re not-so-techy yourself.

You want to ensure that every minute you invest in the process is organized, well thought out, and that you have come to a general consensus internally before you ever bring your RFP public.

Think of your RFP as the “blind date profile” of starting a new website.

You want a successful, qualified development team to choose YOU, as well.

I’ll just wait for a second while we think about that…

Now, let me explain. Technically, you’re the client, and the client is always right… right? Well, mostly, but…. not always.

An experienced, professional website development team will not necessarily respond to every RFP that they receive, no matter what the proposed budget may be. That may seem surprising, but it happens more than you think.

When a development team member receives an RFP, they review it to ensure a few very key points before deciding to respond:

  1. Can we provide all of the items requested?
  2. What else can we bring to the table by way of recommendations, and will this potential client be open to them?
  3. How knowledgeable is the potential client on what they are asking for? It is very easy to tell just by reading the terminology used whether someone has little-to-no experience in these types of projects, or if they’ve been down this road before and can accurately articulate what their needs are.

Personally, I have seen RFPs that have ranged from a single page, to a 50-page manifesto, and everything in between. Trust me when I say, the more drawn out and dramatic that the RFP is, the less likely the top developers will be responding to it. It can come across as though the potential client is trying too hard to sound as though they know what they are doing (perhaps to impress their teammates?).

Why is this a bad thing? It means that someone in the group has something to prove, will be less likely to take your professional advice (because, let’s face it, we hire professionals because they are just that – the professionals), and it is very likely that there will be more of an uphill battle from day one, rather than the side-by-side team effort that you ideally want the new relationship to be.

Think of the blind date sitting across from you at your favorite restaurant – all they have talked about for the first 10 minutes is how they disapprove of the wait staff, there are spots on their fork, the queso dip is too runny, and then – God forbid – they start talking about their mother!

Keeping it Simple.

I know I have said this before, but website development does not have to be the overwhelming, complicated experience that some people have envisioned it to be. The same is true for your RFP.

Now, simple does not mean a one-pager. Simple means clear, concise, and to the point.

This can be tough sometimes because the web world uses a specific set of terminology, and unless you’ve really been exposed to it, it can seem overwhelming to try to put to paper the things you really want. You’re worried about making sure you say the right words, or use the right phrase, so you run to Google and type “what’s that thing when the thing does the thing?”, you quickly run over 2-3 forum articles, and proceed to copy and paste what you think sounds right.

But here’s the trick – a GOOD web development team won’t need you to know all the right words… they’ll understand exactly what thing goes where, just from reading your candid descriptions.

Think of it like a phone conversation. If you called me and said, “Jenn, I need a new site”, I’ve basically got a bullet point list of questions I’m going to ask, and you’re going to answer them back, kind of in a bullet point form of your own… a check list, of sorts.

This is EXACTLY how you want your RFP to be formatted. Remember, clear, concise, and to the point.

To help add a little more clarity to the subject, I’m going to list a full set of requirements below that will help to make your RFP stand out among the rest being received, and demonstrate that you are working with a team who understands their likes, dislikes, needs, etc.

And remember… during this phase, we’re focusing on functionality. Only if the project is awarded do you need to get into design and layout specifics. The functions are where the money is spent.

RFP Structure

Below are 10 of the most important things to include when composing your RFP:

  1. Contact information
    1. Of the person who will run point during this process for any questions that arise
  2. Company Overview
    1. A short paragraph about your community, and the size of your town/service area
    2. What is your largest age group based on your current census reports? It is very important for a developer to consider what target demographic they are going to be servicing. If you are a retirement-aged town, or a farming county, you are going to have different needs than a University town; your RFP response recommendations should reflect that.
  3. New website goals
    1. What is your primary goal for your new site (increased engagement, focus on family involvement, increase volunteerism, increased tourism, etc.)
  4. Current website information
    1. When was the current website built/last upgraded?
    2. Include a bullet point list of the items you like and do not like about your current site. You do not need to present solutions for issues, but a good developer will be able to read between the lines and recommend functionality that perhaps you didn’t realize was available to you.
  5. New website requirements
    1. Again, try to avoid the jargon explanations here if you’re not sure, and just have a “conversation” – put into a bullet point list the things you know you’d like (i.e. a great way to display businesses in your area, a place where families can look at rec centre schedules, highlight hotels and restaurants in the area for passerby’s to increase tourism, etc).
    2. If you have seen other municipal websites that you really like, include them here and be specific (in bullet point, preferably) why and what you like about each example.
  6. Hosting & Support needs
    1. Are you wanting to host your site internally, and have your own IT department manage support and updates?
    2. Are you looking for an all-inclusive hosting and support option once the new site has been built? If so, mention if you are also requiring email hosting and support recommendations.
    3. If you’re not sure – ask for suggestions.
  7. Budget details
    1. Yes, this is important. Some think that you don’t want to disclose your budget because you don’t want someone to increase their markup just to max you out. However, if you do not set a budget – or at least a range – then it’s possible that you will end up with a lot of estimates over your projected cost, and you’ll waste a lot of your time in review, and someone else’s in putting the proposal together in the first place.
    2. Not sure what a realistic budget is? There’s an easy solution. While you’re putting together your RFP, call 3-4 reputable website companies and ask for an initial basic consultation. Briefly explain your project and ask them to provide you with a range of what their company might charge. You may find that the prices vary greatly, but you can then use this as a starting point for your budget.
  8. Timelines
    1. What is your desired completion date? Note – most standard municipal website projects take anywhere from 3-6 months depending on the complexity and scale of the project, and regular websites (depending on whether you’re including an online store) can take only 4-6 weeks.
    2. It isn’t necessary for you to break down the individual component dates, but you can request that the RFP response includes a detailed project timeline from the developer so that you can communicate with your in-house team what they can expect during the process.
  9. Proposal Organization
    1. You want to make reviewing each of the responses as uniformly as possible – it will make your job easier. Here is a recommended proposal outline:
      1. Cover: identifying key contact personnel
      2. Cover Letter & Sales Rep Bio (the bio is important because you want to get a feel for who you will be working with)
      3. Table of Contents
      4. About the Company
      5. Core project overview and pricing
      6. Additional recommendations
      7. Hosting & Support options
      8. Timelines
      9. Client References
      10. Project Terms (to include the payment schedule and developer expectations)
  10. RFP response deadline
    1. What date will you accept questions up until and how quickly you will answer each question.
    2. When you need the response to be submitted
    3. How you would like the response submitted (print or electronically, or both)

Choosing the Development Team for You

You’ve gone through the process of putting together a stellar RFP, and it’s been sent out. All questions have been answered and you’re sitting with 3-4 proposals in front of you. Now, how do you choose?

Remember… price isn’t everything. You’re about to choose your next long-term relationship, and you don’t necessarily want it to be the lowest bidder.

So, here’s my 3 key points on how to choose the right developer for you:

  1. Do a quick overview of each document to see how closely they were able to follow your Proposal Organization outline (#9 above). Seems silly, but if a company has ignored your request for the outline, chances are they are placing more value on how they like to do things, rather than what you’ve requested – a recipe for disaster and a quick way to end up having to beg for things you want in the end. Be flexible for things like recommendations, or other additional pieces of information that the respondent wants to provide you, but the general flow should be close to what you’ve asked for.
  2. Evaluate the company and sales rep bio carefully. Do they have a lot of experience working with organizations like yours? Remember, a good development company is not just there to check the boxes you’ve asked for, but also to ensure you have everything you need, including the things that perhaps you didn’t know to ask for. Only experience will afford this. In addition, a company with a lot of experience will reflect this in their pricing – they may bid high, or low in comparison, but you can be assured that their price reflects their experience – they picked this number knowing exactly what it takes for their team to give you what you need.
  3. Evaluate their client references. Visit the websites. Call the contacts. Have these conversations. And remember, it’s not about comparing site functionality – it’s about what the working experience was like. Was the Project Manager easy to get a hold of if you needed them? Were responses timely and thorough when addressing questions/concerns? Was the overall experience positive? How was the development company at problem solving and recommendations? What has the contact and support service been like since launching the new site? These are all extremely important questions to ask.

“But, Jenn, you don’t even mention the project requirements?”

Yes, I know… and these are important. Did the respondents address each of your items? Did they bring anything to the table in addition to what you’ve asked for? Do they sound like they know what they’re doing? All good things.

But remember – it’s just paper and ink – anybody can say anything to try make a sale – doesn’t mean that the experience you get is going to fulfill all of your needs.

Look for someone that can be your go-to. Someone that will treat you like a valued voice. Someone you can roll your eyes with, or laugh with, and who can make the process easier for you.

If you’re not just a number to your developer, your website has a far better chance of actually becoming what you need it to be, and not just a paycheck for someone at the end.

Lots to take in, I know. Once you get started, if you’re looking for a range, or just some ideas on things to include in your RFP, by all means, please feel free to contact me directly. I would be happy to help, or even look over your document before you send it out (providing of course, that you let me also respond to it in the end – ‘cause, you know, I’d like to eventually work with you too!! LOL).