Government agencies are often required to use a request for proposal (RFP) process to make a software selection and purchase decision. Historically, RFPs have been implemented to ensure fairness protocols are followed that remove decision-making bias and, in rare cases, unscrupulous business dealings to secure a government contract. As a technology provider that’s been in the environmental health software space for 30 years at Hedgerow Software, we’ve seen how the RFP landscape has subtly shifted over the last decade. By that I mean, RFPs are now simply not as beneficial as they’ve been in the past for government agencies. Let me explain.

Measuring Hard Costs vs Abstract Benefits

First, let’s take a macro-level view. An RFP is most useful when making a decision based on well defined specifications for a project, such as building a bridge. In the world of software, however, no two solutions, or uses of a software, are the same. The primary reason for purchasing software is to improve productivity. For example, removing inefficient paper-based systems and providing tools that can be used by field inspectors, back office staff, and community engagement with business owners and citizens. When you think about this in terms of cost vs productivity, it’s much easier for agencies to measure costs in an RFP. That’s what a typical RFP does—it collects bids as part of the evaluation process. However, measuring productivity gain is more abstract than coming up with a technology cost. Productivity should also be considered across a whole affected organization—primary users, administrative staff, and management.

Simple example that demonstrates the importance of productivity.

Let’s say software is being purchased for a primary human resource user who costs $100,000 per year (wages, benefits, overhead, etc.). There are two possible software solutions: 

• Option A is free and improves productivity 10%
• Option B costs $2,000 per human resource per year and improves productivity 20%  

Which is the best solution? The first with zero cost delivers 10% of $100,000, $10,000 of value. The second that costs $2,000 delivers 20% of $100,000, $20,000 of value, for a net value of $18,000.

Unfortunately, the typical government software RFP tries to get apples to apples comparisons, which is difficult. RFPs ask questions like: “Does your software do X”.  Two competing vendors answer the question “Yes”.  The problem is they do “X” in different ways. How does a buyer know which method offers a more efficient solution?  The answer affects the productivity valuation.

Modern Government Agencies Are Becoming More Like Public Companies

Second, let’s look at the technology vendor landscape for agencies, which is relevant to the RFP discussion. In the environmental health industry some vendors are now providing “civic platforms,” which include EH and additional agency teams like building departments and court systems. Including more teams, especially those that have little in common during day to day operations, increases project scope and adds complexity to an evaluation process.

To take this concept one step further, even larger technology vendors have entered the space and are spending billions of dollars on sales and marketing to persuade agency leaders that a single platform is needed for an entire agency. This approach has trickle down effects on RFPs because the technology systems are developed with different feature sets and benefits based on their intended users. The more features and users that are added, the more complex measuring productivity becomes, which leads to more ambiguous decision making.

Lastly, we’ve noticed an influx of new leaders that have shifted towards a more “modern” government approach. These leaders are more tech savvy, data-driven, and manage their agencies in a similar fashion to publicly traded companies. How does this impact RFPs? Because measuring productivity gains are even more important since the pandemic. Agencies are faced with 30%+ inspection gaps, which are harder to fill with smaller staffs and headwinds to backfill critical positions. There are simply only two ways to bridge this gap: (1) hire staff that can close the delta or (2) improve productivity of current staff using tools like technology. We know hiring more staff is very difficult right now, so the answer must be a focus on more productive tools to do more with less. This leads to new thinking about RFPs…

better way to purchase government software - request for productivity

At this point, I hope you have begun to think less about the need for request for proposals and more about a request for productivity. Once you start thinking in those terms, the evaluation process becomes more straightforward. For example, a heavy focus on peer discovery and references are great places to start. Answers to the questions below will quickly winnow the alternatives:

• Who do you work with for environmental health technology? Why? 
• What has been the experience? How would you rate them?
• Is the system tailor made for EH? If not, how does it work for EH teams?
• How was the software implementation?
• Were there change orders post-implementation? Why? 
• How easy is it to adapt their software to changing needs?
• Is the vendor’s participation required to implement changes and/or expansion of use?
• What is the quality of their post go live support system? How would you rate them?

Next, schedule technology demonstrations with not only the vendor but also with peer agencies currently using the products. Take time when evaluating vendor applications/products because demos are just brief looks, as such, they can be conducted so that nothing fails and weaknesses in the products may be hidden. Done properly, demos usually take more than an hour or two, so it’s good to plan for multiple segments to keep attention spans high. This makes it easier to remember what was presented and it gives users a chance to regroup and come up with new functionality questions. As more is learned at each of the steps it is good to circle back with more questions of references, detail on costs, and more demos, if necessary.

Please note one nuance in this process. An assumption is the buyer is seeking a commercial-off-the-shelf (COTS) software solution. The expectation should not be a perfectly fitting custom solution. A buyer might have to expect to change practices to achieve full value of a COTS solution. A COTS solution is governed by a license to use provided by the COTS vendor. Not a project development contract of the buyer’s making. The license should allow accommodation of negotiated changes from the vendor’s standard terms and conditions, and incorporation of buyer’s required legal terms and conditions.

Lastly, it’s ok for some friendly tension between environmental health business users and IT teams. This is natural as each team has different key performance indicators. What usually works best is to collaborate early, openly, and honestly during the technology evaluation process. Don’t bring IT (or business stakeholders) into the process last minute; include all key team members early on, so everyone can get on the same page about the needs, approach, and best solution for the agency.

To sum up, it’s time to reconstruct the RFP. By focusing on productivity and results experienced by peers, you’ll mitigate risk of project failure and ensure you select the best technology for your agency to succeed. Do you agree or disagree we need a better approach than traditional RFPs? Make sure to comment or connect with me on LinkedIn. I also appreciate private messages on these topics!