Writing a Successful RFQ for Web Site Projects: What to Do and What to Avoid

By Antoine Dubeauclard

Regardless of the industry you work in, you should be familiar with the request for quote (RPQ)/request for proposal (RFP) process and how it affects your business. I experienced a need for this firsthand when I was working as an IT expert for the United Nations as part of a set of projects for the United Nations Development Programme (UNDP).

We were tasked with analyzing financial models to determine how businesses impacted economic development and social impact in developing countries. My team was from all over the world; each member bringing expertise in their own discipline. Together, we constructed a complex platform connected to Salesforce that captured and analyzed corporate efforts to work within developing countries while having positive social impacts. This project was a mix of big data, best practices, and data visualization. In the last two years of the initiative, I worked as a consultant to create specifications for the system so vendors could properly understand and bid on available work.

While I occasionally participated in the outsourcing of work in my primary role of President at Media Genesis, it was a new experience to act as the client and create RFPs for a few six-figure projects. It was useful to be able to explain how the project was likely to reach a certain scope and budget and, therefore, why it would require more specificity to be able to attract the right bidders.

Being on the receiving end of hundreds (if not a thousand or more) RFPs/RFQs/RFIs/etc., I was able to mitigate many of the issues I had previously seen that led to projects starting incorrectly from the beginning – usually the creation of the RFQ.

Common Challenges

From my work with the UN and as President of Media Genesis, these are some of the more common challenges I’ve seen companies face when issuing RFQs:

  • Knowing exactly what is needed. It’s easy to assume that a vendor understands your inner workings and desires, but there may be a big gap between each party’s understanding of the project that isn’t identified until after project launch.
  • Cost overruns. Many projects in the IT space, whether web, software dev, app dev, etc. have a high ratio of failure and high cost overruns. There are obvious examples of this in government projects in particular, but this can happen to everyone. A study once showed that 14% – 49% of IT projects were never completed or completed significantly above budget.
  • Identifying the appropriate budget. Vendors respond with such a wide range of costs that it can feel nearly impossible to establish what the right budget should be and what each vendor will provide. It is common to have ranges of 2-5X the cost between low and high vendors. Keep in mind, too, that some vendors purposefully provide a low cost in order to win the business and then leverage the client’s lack of knowledge to tack on additional fees that can lead to a much higher cost.
  • A need for specialists. The whole process of bidding assumes that by providing the same scope to each vendor that each vendor’s understanding of the project is the same. In reality, digital has become so sophisticated that, much like medicine or law, there are many specialists needed to address a wide range of needs. Many vendors won’t address what they don’t do or don’t know, leaving the client facing the challenge of realizing the gaps after the fact (if they ever do).
  • Vendors disappear. Most commonly found with freelancers, some vendors may abandon a project mid-stride, leaving you with a project that other vendors typically can’t pick up easily. This is incredibly common; especially as work has become virtualized and it’s easy for a vendor to be unresponsive. Vendors may also disappear after project hand-off. Once the allotted contract has been completed, the vendor simply vanishes and becomes unavailable for any maintenance work post-launch that may come up. This makes it difficult for another vendor (or internal team) to manage the site because they don’t know its inner workings nearly as well.

Recommendations and Best Practices

With all these possible pitfalls, what solutions exist to mitigate these, and what best practices can you implement to increase your chances of success?

  • The Bake-Off Strategy. The strategy of having 10 or 20 vendors on a bid process is often a bad one. The vendors who play this game usually are adept at phrasing their proposals a certain way and coming up with price-driven approaches that look good on the surface but actually cost you more in the long run. The ideal scenario is to vet 2-4 possible partners who can align with your internal team and other organizations you work with. From there, you can use a bake-off strategy. Specifically, you can dedicate a small budget for each company to work with you through an early phase of the project. You can then easily see which vendors produce top-quality work and where you have the best fit.
  • Get a professional to write your RFP. The best bet is to hire a consultant or, better yet, a firm that you are considering to actually write the scope of work. This should involve quite a bit of time asking your team questions and understanding your needs and internal capabilities. A good scope of work is not only the first part of any well-run project, you can also use it to get an accurate quote from vendors if you decide to bid it out. This also allows you to experience working with a single firm without committing to the whole project.
  • Separate the analysis phase from the rest of your project. Start by parceling out the analysis phase and possibly some design prototypes as a smaller project (usually 10-20% of your budget) within the larger-scale project. This makes it easier to sell internally as the project and its objectives should be well mapped out and a return on investment becomes more evident. Ideally, the analysis phase should provide numerous options which can be priced out individually, giving you flexibility to choose what makes financial and strategic sense.
  • Partner up. One approach is to avoid a project approach and, instead, look at a partner relationship with a vendor where you both figure out what resources you have, which ones the vendor can complement, and establish an ongoing relationship. Often, it’s price prohibitive and strategically hard to justify having a large team in-house to do all the tasks needed for a web project. Have a heart-to-heart with a vendor where you look at your combined resources – human resources, financial resources, etc. – and evaluate how you can work with one another. These approaches are often great for clients who have ongoing needs.
  • Evaluate process. It is hard to evaluate a vendor based on their work. The dazzling, show-stopping projects vendors love to show off are often the ones that had the largest budgets, amazing assets, numerous resources, and large teams backing them up. While this is not always the case, the better way to evaluate vendors is to ask them to define their process. Those with loose processes or those who struggle to explain how they manage budget, time, scope, etc., are likely going to mismanage the project. Those who are clear about expectations and how you get to the finish line will more likely get you there.
  • Own your assets. While custom-packaged solutions sold by some vendors might sound great, make sure that you are the one who owns your website and the content on it at the end of the day. You should always have a solution that you (or other outside vendors) can manage independently of other vendors you hire for work. Otherwise, you run the risk of operating on a platform owned by your vendor where, worst case scenario, your website/content could end up being held hostage.

Whether you are writing an RFQ/RFP/RFI for a web site, software development, content management system, or mobile app the suggestions in this blog should help you increase your success with finding the right partner and get the project done right. A parting thought is perhaps one of the most important – digital projects are never really just projects. They need to be maintained, and as such procuring or specifying these as individual projects with a defined start and stop is not the right approach. Instead look at digital as an ongoing endeavor and account for the heavy lift of an initial project combined with ongoing support to maximize your investment.

As always, we are here to help – don’t hesitate to reach out to our team for advice, suggestions and methods to improve your digital success!