Tag Archives: proposals

As part of my effort to establish Bredemarket as a biometric proposal writing expert (I eschew modesty), I researched some documents that weren’t about proposals, but about REQUESTS for Proposals (RFPs).

One way to write biometric RFPs

There are various ways to write RFPs, including RFPs for biometric procurement.

I don’t think I’m giving away any deep dark secrets when I state that biometric vendors want to influence the content of biometric RFPs. I know of one blatant example of this, when (many years ago) one U.S. state issued an RFP that explicitly said that the state wanted to buy a MOTOROLA automated fingerprint identification system (AFIS). So it issued an RFP to Motorola and several other vendors asking for a Motorola AFIS.

Luckily for the state, Motorola chose to submit a bid. (The bid/no-bid decision was a no-brainer.)

As a Motorola employee (not in proposals, but in product management), I was pleased when that state, after evaluating the RFPs, selected Motorola to provide its AFIS. (Are you surprised?)

But the other bidders didn’t give up and cede the victory to Motorola. Via FOIA requests, Motorola was able to read the proposal of competitor Sagem Morpho, which I can paraphrase as follows:

Your state has requested a Motorola AFIS. Well, Sagem Morpho has provided systems that replaced Motorola AFIS in two states when these states became dissatisfied with their Motorola systems. Since Sagem Morpho AFIS is by definition better than Motorola AFIS, Sagem Morpho EXCEEDS your state’s requirement. So award us extra points for exceeding the requirement and give US your AFIS contract, NOT Motorola.

It didn’t work, but it was a good effort by Sagem Morpho.

Some of you know how this story ended. Motorola subsequently sold its Biometric Business Unit to…Sagem Morpho, I was transferred from product management to proposals in the new combined company, and two of my new coworkers were people who wrote that very proposal. I was therefore able to tell them personally that Sagem Morpho’s proposal was better than Motorola’s. The reaction of the two states who founded themselves back with “Motorolans” again was unrecorded.

(Actually, the new company MorphoTrak and its corporate parent that was eventually named Morpho were big enough that they could get around the concerns of dissatisfied customers. So I’m sure that, at least for a time, those two states were probably visited by ex-Sagem Morpho folks rather than ex-Motorola folks. And I know of at least two instances in which MorphoTrak either bid on or implemented systems outside of MorphoTrak’s geographic territory, just because the customers had relationships with MorphoTrak that they didn’t have with Morpho.)

Back to Motorola’s win of an RFP that requested a Motorola system. Usually, the RFP writing strategy of “write a proposal that favors one vendor over all the others” isn’t always the popular course. Some RFP writers prefer a better strategy, in which the overall needs of the customer are carefully considered.

A better way to write biometric RFPs

Enter the Law Enforcement Standards Office, a division of the National Institute of Standards and Technology. In 2013, this entity released its “Writing Guidelines for Requests for Proposals for Automated Fingerprint Identification Systems” (NIST Special Publication 1155), a copy of which can be downloaded here. (For historical interest, an earlier draft version is online here. The draft is somewhat longer than the final version.)

I should mention that the committee that created the guidelines included some clear experts in the AFIS world. Let me just mention three of the names:

• Peter T. Higgins, who was at the time a noted consultant for agencies writing AFIS RFPs and who had previously worked on the FBI’s IAFIS system;
• Peter Komarinski, another noted consultant and a former key AFIS person for the State of New York; and
• Mike Lesko, who was at the time employed by the State of Texas as one of their key AFIS people. He has since left the state and has a new job.

And the rest of the committee exhibited similar experience, so these people knew AFIS and knew what agencies needed when they procured an AFIS.

One of the key issues that concerned the committee was latent AFIS interoperability. I don’t want to spend the time to discuss the topic in detail here, but for now I’ll just say that when you have multiple vendors providing AFIS (there were three major vendors and several other vendors in 2013), there is often a challenge when latent (crime scene) prints are processed on one AFIS but searched on another. To sum up the story succinctly, there were methods to overcome these challenges, and the committee was clearly in favor of employing these methods.

Beyond this, the committee was concerned with two topics:

• The process to procure an AFIS.
• The process to upgrade an AFIS, which includes steps both before and after procurement.

Regarding procurement, the committee identified four specific phases:

• Phase 1: Establish Leadership and Align Resources
• Phase 2: Develop the RFP Requirements and the Document
• Phase 3: Evaluate Proposals and Award a Contract
• Phase 4: Manage Procurement Implementation

The meat of the guidelines, however, covered the upgrade itself.

First, the agency needs to explicitly state the reasons for the upgrade.

Once this is done, stakeholders who have a vested interest in the upgrade need to be identified and given assignments; consultants need to be selected if needed (did I mention that at least two committee members were consultants?); and plans to govern the upgrade process itself need to be created (did I mention that one of the consultants had federal government experience?).

Then the procuring agency is ready to…plan. Where is the agency going to get the money for a new AFIS? What should the new AFIS do? What do the latest AFIS do today that the agency’s (older) AFIS cannot do? Are these new features important?

Once the procuring agency has a high-level view of what it wants, and the money to do it, it’s time to solicit. (I’m talking about legal solicitation here.) This involves the creation of a draft of the Request for Proposal (RFP) that is eventually finalized and distributed to bidders. Perhaps a Request for Information (RFI) may be released before the RFP, to solicit additional information to flow into the RFP. This can be an involved process, as is shown by this one example of something to place in an RFP (I’ll return to this example later, and don’t forget that this example was released in 2013):

Form and fit requirements (type, make/model, or physical size/capacity), such as specifying an Intel® dual-core processor that runs on Windows 7® with a 500-gigabyte hard drive and a 20-inch monitor…

Once the vendors get the RFP, the procuring agency has to manage the bidding process, including questions from the bidders, perhaps a bidder’s conference, and then final submission of the proposals to the agency.

Then it’s time for evaluation. The committee includes this statement at the beginning of the evaluation section:

The evaluation of submissions must be fair and consistent.

I don’t think the members of this committee would have authored an RFP that stated “we want a Motorola AFIS.”

And the evaluation would similarly not favor one vendor over another, and would use a previously-defined Source Selection Plan in which each bidder is graded on specific criteria that were prepared well in advance.

Eventually a vendor is selected, and while the original RFP is still part of the package government the implementation, it is usually superseded by subsequent documents, including plans jointly agreed upon by the vendor and agency that may differ from the original RFP.

But is the “better way” truly better?

In general I am in agreement with the guidelines, but as a former employee of a biometric vendor, and as a present consultant to multiple biometric vendors, I have one piece of advice.

Concentrate on the WHAT rather than the HOW.

(By amazing coincidence, this is something that the engineers liked to tell ME when I was a product manager. Live and learn.)

A biometric RFP should state an agency’s biometric needs, but shouldn’t go into excruciating detail about how a potential vendor should meet those needs.

Take the example above. Would the world end if the hard drive only had 400 gigabytes, rather than 500? (Again, I’m thinking in 2013 terms; in 2021, it’s possible that the computer may not have a hard drive at all.) Every time that an RFP includes a low-level requirement that is not met by a vendor’s offering, the vendor has to take time to create a special offering just to meet the requirements of the RFP, an effort that increases the costs to the agency.

Sometimes these special requirements (I don’t call them custom requirements) are justified, but sometimes they are not.

By the way, my least favorite requirement that I ever encountered was the one that told the bidders and their R&D teams exactly how the fingerprint matching needed to be conducted. As long as the system meets the accuracy requirements agreed upon in whatever document dictates accuracy, who cares HOW the match is conducted?

As I’ve noted a couple of times, this document was written in 2013, and therefore is fingerprint-centric (although it notes that the principles also apply to other biometric systems), includes dated technological references (Windows 7 being an example), and does not account for the cloud systems that are offered and/or have been implemented by several biometric vendors. (Storage of biometric data in the cloud introduces a whole new set of requirements to ensure that the data is protected.) I don’t know whether there are any plans to update these guidelines, and some of the principals who authored the original guidelines have since retired, but an update would be beneficial.

Oh, and if anyone plans to write an RFP mandating a Motorola AFIS, don’t. Motorola left the AFIS business over a decade ago.

But Motorola can supply a real-time computer aided dispatch system.