A successful website design project is about much more than the software code, images, and text. To execute an effective design, you need to have solid documentation. It can either be in the form of a contract, a proposal or a statement of work. It goes without saying that the document's name is a lot less important than its contents. It does not matter whether you are a large enterprise or a small business. Documentation is indispensable if you want to pull off a website project that is on-time, on-task, and on-budget. The more diligently you document during the sales process, the smoother it goes for everyone involved. Let us look into how to deal with 'Request for Proposal' responses.

Evaluating 'Request for Proposals'

Reviewing proposal requests might sound easy, but it is not as simple as it might seem. If the members of the project team solicit quotes from a number of design agencies, the task of reviewing proposals for the website design project can be a little overwhelming. As the proportion of your RFP injuries start to rise, so would the response pool and the variation within the said proposals. Here's hoping that you made a short list of site developers before you sent out the RFP to help you curb the number of proposals and make the review a lot easier.

Once the proposals start to arrive it is absolutely essential that you ask yourself the following questions:

  • Did the client respond to the RFP response within the indicated timeframe?
  • Was the response professional?
  • Is the Request for Proposal written well enough?
  • Is the proposal for the website within the budget constraint of the project?
  • Will the website get finished on time?

By answering these questions, you will be able to eliminate design firms that are not a good fit. If the RFP response is unprofessional, incomplete or late, then it is a sure-fire red flag. If the RFP response is priced twice as high as your budget, or if it barely manages to come up to a third of the budget, then it should be a cause for concern.

Once you have reviewed the responses and removed the red flags, you need to review and compare the remaining responses

What are the design requirements you need to look out for in the RFP response?

The length of the RFP response can vary depending on the vendor. So, let us leave aside the text volume or the number of pages. The content and the solution are all that should matter. The RFP response should cover the following details:


  1. Project plan – Typically, this includes a list of high-level tasks. While this will not be as detailed as the project plan itself, it will have enough details for you to get an idea of the flow of the design and build.
  2. Project management – The website design agency should clearly list the toolset they use for managing the project. This tends to vary from firm to firm as there are a number of available options. The most important thing is to verify that the project management process is structured and the owners, tasks, and dates will be documented.
  3. Team members – The team structures tend to vary between agencies. The larger the design agency, the larger your project team. As a buyer, you need to have a clear idea as to who will work on your team and the capacity of the work they can provide. You do not need the full resumes of the designers and the other players, but you do need to have a fair idea of who is involved.
  4. CMS and Baseline technology – If the website RFP does not specify an optimal solution, then you need to sit up and take note. Always ensure that the RFP response lists out a desirable CMS and any other technology that will be used for coding and launching the new website. Pay special attention to anything proprietary. Proprietary packages are red flags, as they lock you with the developer for the life of your website.
  5. Deliverables – A list of deliverables is very important as it gives you a roadmap of what is to be delivered when. This can include anything from the volume of content that needs to be migrated, design templates, plugins utilised and a lot more.
  6. Functionality list – If you want your website to have more complex functionality than a brochure website, then a functionality list is critically important. It should be directly proportional to the complexity of your website.
  7. Content migration – If the website project includes the migration of content, then you need to have clear documentation on the amount of content that needs to be migrated to the new website. This might include posts, pages, events, products, attachments, users, and so on. If you don't clearly define the nature of the migration and content volume, it will add to your costs.
  8. Image usage – It is critically important that you have a clear idea of who owns the images that the designer is going to use in the website design. You need to know the parties responsible for selecting, purchasing, editing and placing the images. This tends to vary from project to project. So make sure that you define this early on during the process.
  9. SEO – Keyword research, page mapping, meta-definition, on-page optimisation and 301 redirects are very important. If organic SEO is your modus operandi, and you need to protect the traffic source during the redesign. The easiest way to do it is to make sure that the topic is at the forefront during the scoping and proposal.
  10. Mobile responsiveness – Any modern website needs to be responsive on mobiles as well. Large websites are the only exception to the rule as they tend to have a separate mobile app or website. If you don't have a mobile website, then make sure that the proposal includes a plan for managing display for phones and tablets.
  11. 3P integration and APIs – Enterprise and mid-market companies usually have a number of software packages and systems in their organisation. They need to be able to effectively communicate with the new website by pushing, pulling and syncing data. If APIs or integration need to be used, then you need to ensure that the proposal delineates the third party system, data points, and the responsible party.
  12. Milestones – These ensure that the project team that you have contracted hits their target goals at every step of the design process before they move on to the next one. Typically, these include discovery, graphic design, information architecture, content migration, theme coding and beta testing.
  13. Schedule – Every website proposal must include a schedule corresponding to the project milestones. This will give you a fair idea of how much time is allocated to each milestone and whether the overall project fits within your timetable.
  14. Delays – Every project tends to run into delays, either because of the client or the developer. You need to have a clear idea of how they will be handled when they crop up and how they will affect the overall timeline and budget of your project.
  15. Payment terms – If the website project is small, you will pay 50 percent at the start and 50 percent at completion. If the website is large, then the payment is based on set timing or milestones. Make sure that the proposal clearly defines the terms of payment.
  16. Expenses – These include domain fees, plugin licenses, hosting fees, travel and stock images. Ensure that the proposal details the anticipated items and the responsible parties.
  17. User training – This is a very important part of every design overhaul. If your users are new to the CMS, then you have to establish guidelines for online training tools, training documentation, and interactive training sessions. The training methodology has to match your user base.
  18. Warranty period – The warranty for the website includes the cost of fixing software bugs. It is usually specified for a set period and is stated clearly in the contract or proposal. The warranty covers coding by the website developer. However, it does not include third party extensions or plugins.
  19. Ongoing maintenance – Warranty period often tends to get mixed up with maintenance. But, they are a different beast altogether. Maintenance agreements are usually paid on an annual or monthly basis and they are used to provide software updates over time. For instance, if it is a SilverStripe website, it would include the update of core CMS software or plugins that are installed on the site. Maintenance also includes security, backups, monitoring, reporting and personal assistance as and when it is needed. 

Once you have reviewed the proposal and narrowed down on the supplier, you should focus your energies on the contract negotiation. This involves focusing on any open issues or questions, which will provide a solid basis for the design and execution.