Avoid a Website RFP Horror Story with these 13 Questions

At Diagram, we aren’t shy about our dislike for the Request For Proposal (RFP) process when building a new website. The bottom line is that they often create more risk for organizations than they reduce. However, sometimes RFPs are necessary. In these cases, a poor RFP can doom a project before it can start. In these situations, I see a repetition of similar problems. Below are some questions each organization should ask of itself before issuing an RFP, so a project won’t get buried alive.

1. Should this go to RFP?

   This is the most important question to ask internally. A big reason why I see RFPs fail is that an organization doesn’t really know what it’s asking for, so when new requirements pop up in a discovery process they are not in a position to pivot around these needs. Also, since organizations aren’t always continually versed in the digital space, they are looking for something that used to work and not looking forward to what will work best.

   It’s not any fault to these organizations. However, not knowing what is missing can lead to ambiguous RFPs that don’t provide enough detail – resulting in overly optimistic vendor responses. This lack of value can hinder an organization’s digital strategy initiatives, in some cases, setting some organizations back for years.

2. What is my total budget?

   Knowing the total budget, and communicating that number to potential vendors is key. When given any RFP – specific or ambiguous—most organizations are forced to guess the actual amount an organization can spend. This uncertainty can cause bidding vendors to either offer below the need (coming in at a low price) or offering more than can be afforded (risking losing the bid). To keep pricing low, many vendors will only include a minimal amount of resources in their bid which won’t account for overlooked needs as they’re discovered, leading to delays and changes.

3. What does the lowest responsible bid mean for our organization?

   The RFP process is typically built around the intention of awarding the lowest responsible bid. However, the determination of what constitutes a “responsible” bid is often undefined at the beginning of the RFP process. If requirements aren’t specified, this can lead to uncertainty when selecting the final vendor. Unfortunately, I’ve witnessed too many organizations selecting what they thought was the lowest responsible bid only to find out during the website migration that there are many unanticipated setbacks causing change orders, price increases, and project delays. Some of these RFP horror stories resulted in website projects taking twice as long and costing twice as much as the original bid.

4. Do we have the whole project scoped?

   This is probably the most difficult question to answer because most organizations do feel that they have the project fully scoped when they issue an RFP. Often, though, an integration or technical oversight can be found after the project begins – causing unseen delays and adding risk to the project. Some of this risk can be mitigated by providing website documentation with the RFP. If an organization doesn’t have a fully documented website, then it might make sense to partner with a vendor for a discovery project to help create a scope and help build the framework for an RFP. Remember, an RFP should reduce project risk and not add risk.

5. How do we define a successful migration project and what are our KPIs?

   Websites are no longer static, like buildings. Websites need to generate value and provide a return on investment. Metrics help measure the value of a website and identify areas for improvement. Setting goals and communicating these goals is important to the success of an RFP. Once goals are set, the next step is to identify how success against these goals will be measured.

6. What does our ideal partner look like?

   Knowing the evaluation criteria will help alleviate potential headaches when making the final decision to award the contract. Are you looking for an agency with experience in the platform you’re leaving, in addition to the one you’re migrating to? Do you want someone with experience in your industry? Are they offering the lowest cost? Do they have experience with your integrating software? These are questions to ask internally to build a profile for your ideal vendor, so that when evaluating you can see if the potential vendors fit the mold.

7. What are our licensing needs?

   Procuring your licensing isn’t always necessary before issuing an RFP, but knowing what licensing you intend on acquiring can be a big help in improving the success. At a minimum, the platform needs to be selected before issuing a website RFP. The RFP nightmares I've encountered tend to start with an RFP issued without a defined platform. This leaves too much uncertainty and will cause drastically different proposals. However, knowing the platform and license will help the organization plan for sustainability once the new site is built.

8. How will our new website be hosted?

   This question helps inform question 7. With increased licensing options, such as Episerver’s Digital Experience Cloud Service as opposed to on-premise licensing – it’s important to determine how the site will be hosted. This can alter how certain aspects of the site will be built and can directly impact the site launch. Having this information will also help build a foundation for the ongoing website support and maintenance.

9. What plans do we have for ongoing maintenance and support?

   RFP’s are not iterative and often rely on making one decision that will affect the next 5 to 7 years of an organization. However, the digital space is now anything but static. More than ever before, organizations need to determine what their plans are for ongoing maintenance and support. For example, if you are initiating an Episerver RFP – how will you address the bi-weekly updates? Having a plan and determining if this needs to be included in the RFP is important, as new functionality and security updates are released. Not having a comprehensive plan for ongoing updates, whether it’s internal or external, introduces a huge ongoing risk for the website.

10. Should we include training in our ask?

    Even if your team is already familiar with the CMS platform, training makes a lot of sense in learning how your site is built. Not asking for training in the RFP can result in bids that don’t include any training, leaving a team to try to learn how to use a brand-new site on their own. Having the proper training will help get your team up to speed with the new site more quickly.

11. What are our expected deliverables?

    When issuing an RFP, it might seem easy enough for the deliverable to simply be a completed website. However, that’s not always the case. Before you issue your website RFP, it’s important to determine who will be responsible for some key actions such as migrating content, launching the website, taking care of 301 redirects, setting up the CMS environment, etc. These gray areas, if not specifically addressed, will cause issues. Clearly assigning and defining all deliverables within the RFP is key to getting accurate proposals.

12. Should we be looking for a long-term partner?

    Website RFPs carry an enormous amount of risk for organizations. Part of this risk comes from the RFP itself – often RFPs come from a mindset of commodity fulfillment as opposed to finding a strategic partner. By looking for a strategic partner as opposed to a website vendor, you can shift the risk of the project from the organization to the partner by keeping it within the context of a long-term potential engagement. We find that website designs and implementations are best when completed within an overall strategic roadmap. You don’t have to commit to a long-term partnership when issuing an RFP, but by looking for a partner as opposed to a vendor, you can set the foundation for long-term digital success.

13. Should we outsource our RFP to a consultant?

    This is a tricky question and depends on the organization. In any website project, having an internal project owner will directly impact the success of the project. Sometimes an external consultant can help provide guidance, especially if the organization lacks experience in the selected platform or in CMS projects. However, other times a consultant can become a barrier to completing a project on-time or on-budget due to a variety of factors. Some examples include not fully understanding website needs, not knowing platform capabilities, or creating more levels of bureaucracy by positioning herself/himself between the website vendor and the organization. A key point to consider is if having a consultant will enable the project or create more barriers.

Feel free to comment below on any RFP horror stories you’ve encountered. Or if you want to talk about how to avoid an RFP disaster - let’s chat.