Biometric RFP writing experts, to a point

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.

On win themes and proposal themes

Once you’ve figured out the benefits of your solution for various customer stakeholders, you need to communicate the benefits in your proposal.

Sorry, this is a different type of “WIN.” Whip Inflation Now needlework picture. By Unknown author – Gerald R. Ford Presidential Museum, Public Domain, https://commons.wikimedia.org/w/index.php?curid=20829024

While I try to avoid complexity where possible, there are times when the communication of benefits will follow a hierarchy. Cheryl Smith describes two levels of the hierarchy in her Privia blog post:

Win Themes. These subtle messages are woven into your proposal narrative, reinforcing your Win Strategy. Knowing specifically what they are upfront will help reviewers know what to look for and identify how and where to improve them.

Proposal Themes. These explicit, section-specific statements are used to guide the evaluator as they read. Knowing specifically what they are upfront will help reviewers test how well they support your Win Theme(s) and identify how to improve them.

As you may recall, different evaluators read different sections of a proposal. For an automated fingerprint identification system (AFIS) proposal, you may have a certified latent examiner reading the latent entry section of the proposal, while an information technology person might read the network and security section of the proposal.

Unless you’re a sole proprietor, your win themes, proposal themes, and benefits will probably need some level of buyoff from multiple people. Perhaps your salesperson will advance some themes, but maybe his or her boss will need to approve them. (Approvals are a necessary evil in the proposal process.)

And then when the writers actually write the proposal, the writing will be measured (among other methods) for its faithfulness to the themes. Smith addresses this measurement also:

Be careful what you ask for. When you ask reviewers a generic question like “feedback,” you should expect a generic answer like, “this is weak.” Instead, ask reviewers a specific question like “how can I improve this section” or “how can I support this Win Theme”? This small adjustment in reviewer mind-set will transform a “this is weak” comment into an “add this proof point to strengthen the section” instruction. 

This is something discussed by Carl Dickson (someone I’ve mentioned before in another context).

In the perfect world, a proposal—even a proposal hundreds of pages long—will have consistent themes throughout. It won’t sound like it was written by a bunch of different people—even though it probably WAS written by a bunch of different people.

One of my clients is a practitioner of something called a “book of truth,” a short document distributed to all of the writers for a particular proposal. The book of truth not only states the win themes and proposal themes, but also has some rules for consistency, such as how to refer to the customer. You don’t want to refer to the customer as “Los Angeles County” on page 2, “the County of Los Angeles” on page 7, “L.A. County” on page 9, and “San Francisco” on page 11.

Yes, the latter can happen when you repurpose text and don’t check it carefully. Watch out, because despite the fact that San Francisco and Los Angeles are in the same state, they are not the same city, despite what some people might think.

When wildebeests propose

(No, this is NOT a post about wildebeest mating rituals. If that is your interest, go here. This is a post about how businesses develop sales proposals that they send to other businesses. This process has its own rituals, but they are not studied by biologists.)

Bredemarket isn’t my first time working as a contractor.

I still remember a night in October 1994. I had been contracting for several firms, and had just started a new contracting assignment in Anaheim, in an oddly shaped triangular building. I was contracting with a company’s Proposals Department, despite the fact that I had never written a proposal before. I had once helped to write a Request for Proposal, but that RFP was pretty much just a checklist.

As a contractor, I was paid by the hour, so I didn’t mind the fact that I was asked to work extra hours that October evening. While the actual employees were feverishly working on a response to a state-issued RFP, I was tasked with writing sole source proposal letters for things I had never heard of before that day. So there I was, writing letters that explained the “Input Station 2000” and the “Latent Station 2000” and things like that.

I continued contracting after that night, and eventually became an employee of the company as a proposal writer. I spent over five years writing about Input Stations and Latent Stations and Search Processors and amazingly small Fingerprint Processor boards, and after a while I even knew what I was writing about. I still remember my joy when I mentally had an understanding of RAID.

After my five years in Proposals, I stayed with the company in another role (product manager) through two corporate acquisitions, and after the second corporate acquisition I rejoined the Proposals organization, spending another five years there. And even after I left Proposals for the second time, I continued to contribute to proposals afterwards. My flying pig did a lot of flying.

I have continued to do proposals work for Bredemarket, helping a firm develop standard proposal templates that its salespeople can use.

But Bredemarket also writes its OWN proposals, which is how Bredemarket gets some of its business.

You’ve heard the saying about eating your own dog food. That statement bored me, so I started talking about eating your own iguana food. Eventually I tired of iguanas and pivoted to wildebeests.

Black wildebeest. By derekkeats – Flickr: IMG_4955_facebook, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=14620744

Whether dog, iguana, or wildebeest, you get a slightly different perspective on proposals when you’re writing them for yourself.

But only a SLIGHTLY different perspective. After all, you’re still promoting a product or service, and still communicating benefits to a potential customer. That remains true whether the proposal was written on behalf of Printrak, MorphoTrak, Bredemarket, or one of Bredemarket’s clients.

But things are still a little different when you’re proposing for yourself and your service.

For one, the approval cycle is streamlined. As part of a multinational corporation, the MorphoTrak proposal approval cycle was relatively complex, even after my boss took extreme steps to simplify it. If MorphoTrak was going to release a $20 million dollar proposal, there was a good chance that someone at MorphoTrak’s corporate parent in France was going to have a seat at the approval table.

Now I’ll admit that Bredemarket has never issued a $20 million dollar proposal. Because of this, all of the proposals that Bredemarket has issued have only required a single approver.

Even then, however, you may have to wait a day to get that proposal approved. After all, the proposal approver is a strong practitioner of the “let’s sleep on it” school, and usually comes back with revised proposal ideas a day later after sleeping on it.

For example, let’s take a recent proposal that Bredemarket submitted to a potential client. The proposal was pretty much done, but the “sleep on it” interval had to take place before it was re-examined the next morning. I incorporated my new ideas (my dreams?) into the text, and then I printed a copy of the proposal for one last review.

A few minutes later, the printed copy was filled with changes.

So I made the changes, printed the new final version, and reviewed it one more time.

And added more markups, resulting in changes.

In the end, the proposal exceeded the three review cycles common in some of my offerings. And I probably could have reviewed it one or two more times, but I wanted to get the proposal out the door.

And even as I emailed the proposal to the potential client, I realized that proposals are often iterative, and that my potential client may have some requests for changes, resulting in a proposal modification.

Or maybe more than one proposal modification.

Back when I was at MorphoTrak, I regarded a proposal modification as a sign of failure. It meant that we didn’t get it right the first time, and therefore MorphoTrak would have to spend money to issue a revised proposal, and perhaps a re-revised proposal, and perhaps more. At the time MorphoTrak appended a letter to its revised proposals – “a” for the first revision, “b” for the second revision, etc. To my knowledge MorphoTrak never issued a “z” proposal revision, but we did go fairly deep in the alphabet.

By Serg!o – Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=83494916

From my present perspective, I’m a little more welcoming of proposal revisions. It’s an admission that I don’t know everything about the client, although I can hazard a guess as to what the client needs.

Remember Bredemarket’s client who needed standard proposal templates? Well, my own proposal to that client went through a few revisions, even after the original contract was finally approved. There weren’t any huge overhauls in the original proposal content, but there were a few things here and there that needed to be tweaked so that both parties were satisfied.

While I’ve had some successful proposals, some of Bredemarket’s proposals to potential clients did not result in business. (Yet.) These potential clients, for various reasons, decided not to pursue business with me.

Of course, this is true of any proposals organization. No proposal team that I know of has sustained 100% success over an extended period, although I know of one team that won the majority of its competitive bids over a 2 to 3 year period.

But the wildebeest continues to hone his own proposal skills, while using what he learns to benefit future clients.