Is Competitive Bidding the Best Process for the Public Safety Industry?


Is competitive bidding the best way for public safety agencies to buy software solutions? This question is rarely asked. The RFP process is simply a way of life for buyers and sellers in the public safety software business, ostensibly because competitive fixed price bidding assures that vendors will offer their very best prices.

While many would defend this view, few would argue that the industry as a whole is innovative, or that service levels are of the highest caliber. Customer satisfaction is generally low. Is it possible that a process designed to obtain the lowest price might diminish an entire industry’s capacity to deliver the highest possible value?

Research indicates that competitive bidders, “…may perform poorly when projects are complex, contractual design is incomplete and there are few available bidders. Furthermore, competitive tendering may stifle communication between buyers and sellers, preventing the buyer from utilizing the contractor’s expertise when designing the project.” (Incentives and Award Procedures: Competitive Tendering vs. Negotiations in Procurement, Tadelis, Bajari) Certainly, public safety software projects meet these criteria. The authors suggest that in such cases, characterized by uncertainty on the part of both buyer and seller, negotiated purchases may result in greater value delivered.

In the bidding process, buyers are responsible for defining requirements, but lack the necessary time or information. Requirements are cut and pasted from others’ RFPs, or vendor-supplied lists, resulting in two problems:

Real requirements are missed. Even the best efforts to gather users’ requirements come up short because processes and workflows change, and new requirements invariably emerge.

Unneeded features become requirements. An unfortunate bit of conventional wisdom holds that extra features do no harm. Wrong! Feature-bloated products are not just a little overweight; They are morbidly obese and unhealthy. Every feature adds complexity and increases the cost of vendors’ development, support, and service, and of customers’ installation, training, and maintenance. Furthermore, excessive complexity reduces usability and makes users less efficient.

When vendors are forced to develop and support features that aren’t needed, they do so to the detriment of features that have greater value to users. They create unnecessarily costly products that are difficult to use and administer.

In a negotiated purchase, buyer and seller are motivated to work together to discover the minimum set of requirements that meets the buyer’s needs fully at the lowest reasonable vendor cost and customer price.

Consultants are often hired to assist in the development of requirements. Unfortunately, they carry long wish lists from one engagement to the next, essentially cross-pollenating RFPs to the point where every known requirement appears in every RFP. This minimizes the consultants’ time and effort, but leads vendors to charge for extraneous features, and to waste their development effort on features their customers don’t need.

Unnecessary expansion of the scope of procurements is another unintended consequence of the bidding process, especially when costly consultants are employed. When each trip to market costs thousands or even hundreds of thousands of dollars, the buyer is encouraged to fill the shopping cart to the brim.

Buyers end up replacing multiple applications before the end of their useful lives because one system is on its last legs. The lower procurement cost of negotiated purchases enables buyers to go to market more frequently and to realize the benefits of right-timing their purchases.

Vendors know that requirements are incomplete, bloated, and often inaccurate. But because they must offer fixed price proposals anyway, they pad their bids to make room for anticipated changes. In some cases, the most qualified vendor loses on price. In an even worse scenario, a low bidder is awarded the contract and ultimately fails or performs poorly under the financial pressure of an unprofitable project. In a negotiated purchase, the padding, risk, and procurement cost are all reduced.

RFP requirements are supposed to serve as measurable performance criteria by which the supplier’s performance is verified. They are not, simply because they are not nearly specific enough or objective enough.

The ambiguity favors suppliers to the extent that arbitrators or courts cannot verify delivery or failure to deliver, and vendors are incentivized to presume the least costly interpretation of vague requirements. Negotiated procurement enables the refinement of requirements and acceptance criteria from an informed perspective.

It is easy to manipulate the outcome of what appear to be competitive procurement processes. It is generally accepted in the vendor community that most bids are “wired” for a predetermined vendor. They are not rigged to the extent that they would be judged fraudulent, but prior to the formal procurement process, the preferred vendor will typically feed requirements to buyers that favor their offerings, often providing complete requirements documents (ask any vendor if they have an “RFP template” for their products). Having chosen a preferred vendor and written the requirements to match their capabilities, all that remains is to recruit predestined losers. Informal vendor consensus holds that the win rate with no pre-procurement “influence” is in the low single digits.

Negotiated purchases are not inherently non-competitive. Many states, government councils, and cooperative groups of buyers conduct full competitive procurement processes that make it possible to work openly and cooperatively with pre-qualified vendors to:

· Negotiate contracts that fit the buyer’s real requirements;
· Eliminate the cost of unneeded capabilities;
· Provide for inevitable refinement of requirements;
· Eliminate extraneous time, effort, and cost of the bidding process.
When possible, a negotiated purchase from a reputable vendor has the potential to be more efficient, less contentious and wasteful, and to deliver far greater value.

At the very least, smart buyers should:

1. Include an assessment of negotiated purchase options in their procurement process. Explore existing contracts, reciprocal purchase vehicles with other jurisdictions, the Federal GSA schedule, and options such as extending an existing contract with one agency to include others.

2. Consider the full cost of a competitive procurement; not just the price of the consultant and out-of-pocket expenses, but also the cost of the inefficiency of a process that is known to be poorly suited to nature of the purchase. Effectiveness is diminished and costs are increased every day that users have to live with a feature-bloated product that is poorly matched with their real requirements.
Public safety agencies and vendors have long suffered under the current procurement system. Those who can’t avoid traditional competitive procurement can at least recognize and take measures to mitigate some of the pitfalls. Ultimately, a process is needed that acknowledges and manages uncertainty rather than denying its enormous effect. Negotiated procurement, where applicable, goes a long way in that direction, and offers the additional advantage of leading to significant cost savings.

Posted in Public Safety
5 comments on “Is Competitive Bidding the Best Process for the Public Safety Industry?
  1. Breck says:

    Having been in the pubic safety software business for 15 plus years, this article hits the bulls eye.

  2. John Rosati says:

    It would be great to see a comparison between similar projects that were procured conventionally (RFP) vs. non conventionally (negotiated). It would be enlightening to see how the projects compared on key objective and subjective criteria including costs (initial and total life cycle), project success (customer and user perspective) and implementation time. As long as the market only sees the initial price competitiveness in the traditional competitive RFP process, there is little incentive for them to change. And since buyers don’t perform post-mortem analyses on their RFP procurements, they don’t know what they don’t know.

    • MarkF says:

      Marvelous idea! The authors I cited offer some objective evidence based a study of highway projects in Northern California, but they are hardly definitive. One of the authors went on to write a book on Public Sector Procurement that I have not yet read. Of course measuring customer satisfaction is a subject in itself.

  3. Dan Deveson says:

    ” all that remains is to recruit predestined losers.”

    I’ve spent 20+ years as the distant second in a five-horse field, and I’m here to tell you that your article is absolutely right on every count. More than right, if that is possible. But know well that it is not limited to public safety, software, or any vertical limitations whatsoever; it is endemic.

    Recently I’ve seen a rash of new procurement efforts, and a couple months ago I sat in a room where vendors held competitive bake-off presentations — the room was electric! My point being the recession has really trimmed a lot of procurement fat in my circle, and I’d expect elsewhere too.

    At the heart of the matter is that the customer should, and generally does buy what the customer wants. Smart customers know their marketspace, attend trade shows, and develop peer-relationships with other jurisdictions as a matter of course. Everybody knows that selling is all about relationships, and the astute sales-and-marketing team generates that want.

    I have employed every known mechanism of project management/procurement on 6-to-9-figure jobs, and in my travels I’ve found one particular approach that really sinks in: http://incose.org/

    They sport an engineered approach that spans requirements through finance and any technology project could benefit by a subset of these general principles.

    Thank you for your insightful article.

  4. Jake Smitty says:

    Good food for thought. Thanks for sharing!

Leave a Reply

Your email address will not be published. Required fields are marked *

*