Don’t Let Your Government Website RFP Go Off the Rails: Avoid These 3 Missteps

October 19, 2022

Man overwhelmed by crumpled paper. His hand sticks out of the pile holding a sign that reads "HELP"

Let’s cut to the chase: If you’re reading this article, then it’s likely you’ve been tasked with writing or contributing to a Request for Proposal (RFP) or similar document for a redesign and/or redevelopment of your government website. This process can be daunting, time-consuming, and will have lasting effects on your organization’s digital success, and potentially even your personal career. 

With all that pressure, it can be hard to know where to get started — and this is where we can help. 

Because our firm exclusively builds government websites, our team at Interpersonal Frequency has analyzed thousands of government website RFPs, Request for Qualifications (RFQs), and Invitations for Bids (IFBs). We’ve learned how to read between the lines of these documents to see the thought process behind each organization’s request. We keep track of what we see and even share out the yearly trends we find in city, county, and public library RFPs.

Through all this review and analysis, we’ve also spotted some approaches and decisions that can tank an RFP’s chances of getting quality, qualified responses. Here are the three biggest missteps we see in government website RFPs and how you can avoid them.

Misstep #1: Only One Department Writes and Evaluates the Website RFP

Even if you’re the web administrator of your government website, you may not know the intricacies of how every department uses your current interface. If you don’t do the work to gather feedback across a variety of your departments, divisions, initiatives, or programs, you could miss valuable information about the features and functionality that matter most to your project stakeholders. 

The most common group to spearhead a government website RFP is the information technology (IT) team; the second most common we’ve seen is from the communications team. More commonly, we see some sharing of responsibilities between these two groups, but insufficient involvement from other large departments such as public works, public libraries, health, and transit-related agencies for municipal organizations. 

For example, perhaps your communications team has major issues with your current calendaring solution. If your technology team doesn’t know this, they may ask for a similar calendar in the RFP. The selected vendor doesn’t know there’s a hidden issue, and a new solution could roll out with the same old problems.

Conflicting information can also appear within the RFP. Our team was recently working on a proposal for an RFP that was titled as a “redesign.” Only a few days before the deadline, a Q&A was released that clarified that this RFP was only a “refresh.” Because of this new smaller scope and last-minute conflicting information from the evaluators, we decided to cancel our response. 

Getting a bunch of vendors to respond isn’t typically an issue for a government website RFP; getting qualified vendors to respond who will best be able to help you is the challenge.

Long-Term Risks of Allowing a Single Department to Write Your RFP

  • Departmental grudges, both old and new. Not every department in a government organization is accustomed to working across departments or is naturally open to sharing feedback about what is or isn’t working with their technology. They may have problems they feel have been ignored for years. They may have come up with extensive workarounds to fit their needs. Your website redesign is the time to remedy these issues, not keep old wounds festering or invite new ones. 
  • The wrong vendor wins the bid process. You could end up selecting a vendor that doesn’t know how to work with your entire organization. For example, a vendor may know exactly how to work with the technology team to build a new website, but lack insight on how to make sure other stakeholders, like elected officials, are satisfied by the process and the final product. 
  • Rogue “microsites.” You could increase the likelihood of insecure microsites. While a high-quality microsite has its place, it needs to be built with the same security as your main website. It also needs to be easy for users to return to the main website. If certain departments don’t feel the new redesign supports their needs, they are more likely to go their own way and build their own subsites on a different platform, which could create major security risks as well as content governance headaches. 

A Better Solution

A cross-departmental team should be writing and reviewing the scope of work for the project. They should also be involved in evaluations and interviews.

If your project timeline and budget allows, consider a pre-proposal process by working with an external vendor to gather stakeholder (citizen/resident, as well as departmental) input for you. This may sound like extra work, but given the scale of the investment you’re making, it’s more like an insurance policy. After all, we see most government agencies keeping a redesigned website for 8-10 years, if not longer in some instances. We would recommend you pair a website analysis with a content assessment, in-depth interviews with stakeholders, and community focus groups.

Misstep #2: The Website RFP Aims to Recreate Your Existing Website, but with Fresh, Prettier Pictures (and Doesn’t Look at Content or Other Functional Issues)

The easiest solution is not always the best solution for your needs. If you’re expecting to simply “reskin” your current website with new, more modern visuals, be prepared to introduce a host of issues that could plague your website for years to come.

Long-term Risks to Recreating Your Existing Website

  • Content rot. Your website content has a lifecycle. It can quickly become out of date. “Lifting-and-shifting” old content to a new website is like bringing your garbage with you when you move to a new home. This can lead to frustrated users, stressed staff, and low accessibility scores. If you already have a high call-volume of people asking questions over the phone that should be answerable online, expect those numbers to continue or even increase with your new design. 
  • You may end up with a legacy website. If you take this approach, your selected vendor may suggest building a new website, keeping your old site available, and having your organization move old content to the new site after launch. In our experience, this approach brings serious risks. Given the bandwidth of typical government website content editors, this process could take years, or never get done at all. If your legacy website remains live, users will be confused about which resource is the source of truth. New staff will also feel the effects of this messy system; prepare for plenty of onboarding headaches.
  • You might have to put out another RFP sooner than you expected. A redesign that only focuses on visual design does not account for the entire user experience of your website. It often ignores your content, information architecture, and the overall usability of your interface. You may find yourself in the place of having to find a new vendor to fix the old vendor’s issues. That is a lot of wasted tax dollars.

A Better Solution

If you’re not sure where to start with your redesign, consider putting out a Request for Qualifications (RFQ) rather than an RFP. This way, you can look for the vendor who is most qualified to assess your current website and provide a range of solutions, rather than just a product.

Don’t ask for mock-ups of your website with new visuals in the RFP. The best government website vendors will want to take more time to investigate your content and information architecture before adding a visual layer. Along the way, they will want to perform usability testing to ensure your community can actually navigate this vital resource. 

Instead, have vendors provide you with samples of their work, including “live examples” or URLs of government websites they’ve built recently. That will give you more of an idea of what’s possible.

Misstep #3: The Website RFP Hides Important Information about the Project from Prospective Bidders

Too often, an RFP will refuse to provide information about the project budget, required integrations, or the known statistics about the current website. This makes it much harder for prospective vendors to gauge the right cost-point to include, get input from their technical team, and properly scope out the project timeline.

Long-Term Risks of Hiding Important Information from Prospective Bidders 

  • Your budget may take a bigger hit than you expect. If you have an idea of the project budget, but don’t include it, vendors may give you low-cost responses with a variety of hidden fees for the features that you need. If you have more integrations with APIs than you disclose in your RFP, this can also quickly cause a project budget to increase.
  • Your contracting process will take longer. Government procurement is a detail-oriented, lengthy process that is different for every organization. Not every vendor is prepared for what happens after they’ve been awarded a project. The less work you do to prepare your RFP to support this contracting process, the more work you’ll end up doing to get the project approved after vendor selection. 
  • Your project implementation will take longer. Surprises in the project scope create bottlenecks, require change-orders, and delay launches. You may end up with a crowded “parking lot” of work that will need to be done after the new site launches. If you haven't partnered with a vendor who can support you after launch, you may even find yourself trying to do this work alone. 

A Better Solution

Transparency is the best way to build trust with your prospective vendors. If you know your budget range, include it. If you don’t know the answer to a vendor’s question, be honest. It will help us give you options, rather than guess.

If you want to learn more about the market, try first releasing a Request for Information (RFI). This will give you a broad understanding of who the industry players are, what they offer, and at what cost. This could help you build a budget and scope of work for your RFP.

Government Website RFPs Require Your Thoughtfulness

Government website RFPs are unique: they are not simply a construction project or a marketing project, nor are they strictly an IT project. Website redesigns require a level of change management akin to moving your entire organization to a new office. You don’t want the people who will maintain your new website to feel burnt out before they even start to use it. 

The more time, collaboration, and attention to detail used to write your RFP, the greater your return on investment. It may seem like extra work up front, but the payoff will come when you launch a new website that not only takes your entire organization to the next level but has a meaningful, positive impact on everyone living in your community. 

Take a look at our library of public-sector website RFPs  city, county, and public library as a starting point for what other government organizations are doing. Prefer an expert hand to guide you through the process? Let’s talk.