Blog Details

Part 3 of my series on RFP’s will be targeted to the RFP Respondent, and is specifically intended to give guidelines for project scoping and responding to RFP’s.

Interactive agencies receive opportunities to respond to many different types of RFP’s. As opportune as that seems, the question often arises about whether or not a specific RFP warrants a response, because of the valuable time required to prepare a worthy response vs. fit between organizations, or the likelihood of being chosen as the vendor. There can be a great deal of risk introduced when the RFP does not provide enough information for full scoping purposes. However, if the opportunity warrants a response, and a decision is made to do so, it should be given as much effort as needed to provide the very best response possible.

This blog will concentrate on two parts:

  1. Deciding on whether to prepare a response to an RFP.
  2. Information needed to prepare a confident response.

Do I put the work into this RPF?

I can confidently say I wish I hadn’t put SOOO much work into a few RFP’s, and on serveral occasions. So, instead of giving qualifiers, maybe it is better to give disqualifiers, and then recommend each respondent make their own decision based on their own subjective analysis.

When to NOT respond to an RFP:

  1. When the RFP is open to the public. 
    Not that we don’t feel competent to compete, but if we aren’t confident our response will get the attention it deserves, it may not be worth the effort to participate.
  2. When a real dialogue can not be had with the RFP creator(s).
    No matter how detailed the RFP document might be in defining project requirements, a complex web project ALWAYS requires some level of interaction to accurately scope the effort. Having a dialogue, even if it is through an email Q&A, is vital for both parties to understanding the fit between the organizations.
  3. When budget expectations are not available.
    If the RFP Creator is not willing to share any sort of budget direction, this often presents too much risk for a real RFP response. Any serious RFP Creator should know that at least some level of budget expectation must be set. (Example:  Imagine accurately quoting a web project, based on requirements, for $225,000, when the client’s budget was actually $30,000!  That kind of situation is frustrating for all involved.)
  4. When the RFP Creator can not provide basic technical direction.
    The RFP respondent should not have to guess about things like IT infrastructure, in-house preferences for technology, and platform expectations (Example: vs. PHP).  It may be impossible to scope a project without this information.

Once a confident decision is made to respond, the real work starts...

What information do I need to gather for my response?

Formatting aside, the following questions will have had to be answered by the RFP creator. Of course, these only break the surface for each area. They have been broken into the following:

  1. Organizational
  2. Technical
  3. Solution-oriented


  • Who is driving the changes requested? (End goals may be different for Executives vs. Marketing vs. IT staff)
  • What happens if NOTHING is done? (People lose their jobs?  Profits decrease?  The CEO becomes angry?... what??)
  • What does 100% project success look like?
  • What barriers (internal or external) are there to prospective project success?
  • How many Administrators/Content Managers are likely to use the website?
  • How many Users will need log-in access, and how will those users get the access they need?
  • How many content “approvers” are likely?
  • Does the website generate (or help to) generate revenue, and if so, how?


  • Does the site need multilingual capabilities?
  • Are there any site navigation expectations, and if so, what are they?
  • Taxonomy...specific requirements must be addressed, if any.
  • Does the site need to be able to sell products online (Ecommerce)?
  • Which Web Content Management System (CMS) is expected by the RFP Creator?  (If none is specified, it begs the question whether a separate analysis is required for that selection effort.)
  • Are there likely to be integration points to 3rd party systems?
  • Hosting decisions? Is it expected that there will be more than one server required?
  • How many pages of content might be required for the website, both at website launch, and at site maturity?
  • What information from the current site needs to be brought to the new site?
  • What SEO requirements are expected?
  • What content search requirements are being put down for the site?
  • Does the site need the site developer to execute on Information Architecture, User Experience/Wireframes, creative design?
  • Is there a concept of ‘web publishing” for site content?  If not, this should be made clear. If so, make sure to clarify the use of content modules, and the way content should be distributed online (including video, events, articles, images, etc..)
  • Are there any mobile site expectations, and if so, what are they?
  • Is Document Management part of the web project, and is it required?
  • Contact modules, and Survey/polls integration?
  • Learning Management solutions, or other education requirements?
  • Are there any security-specific requirements, performance requirements, or any items imperative for visitors/users with disabilities?
  • Can this project be broken into phases?
  • How is it best to quote the effort required? Itemized? Categorized/Bundled? Phases? Fixed Bid or T&M preferred or is a combination of the two a possibility (See my earlier blog post on budget types)?
  • Is the project “turnkey” so that content creation and entry is included in the proposal, as well as full site launch and deployment (including all 301 redirects, URL rewriting, IIS and DNS edits, etc...)?
  • What web analytics expectations should be addressed?
  • Are there any inbound marketing or lead generation requirements being put down by the RFP?
  • How might social media, or any social networking requirements be described?
  • What Training and/or Maintenance requirements might be assumed, or requested?


Hopefully, the ideas presented in this blog series will provide insight to both RFP Creators and respondents, alike. If there is anything to remember, it would be that costs, time, and stress are all determined by project risk, and the more that risk can be mitigated, the less will be required of all those variables. The way to mitigate the risk is for all parties to fully be on the same page regarding what is truly being requested and proposed. Painful detail is a requirement for both great RFP creation and responses. Good luck!