Tag Archives: request for information

Retabulating the work that Bredemarket has done for clients (as of February 16, 2022)

My biometric/identity collateral wasn’t the only thing that I updated yesterday.

As part of my preparation for yesterday evening’s Ontario IDEA Exchange meeting, I took the time to update my “local” brochure. (Because local is important: see the first of my three goals for 2022.) This brochure includes a section that discusses the types and numbers of pieces that I have prepared for clients, including the number of case studies, the number of RFx responses, and so forth.

Those numbers hadn’t been updated since last September.

Before going to the meeting, I wanted to make sure my “local” brochure had the latest numbers.

I’ll go ahead and share them with you. This covers the projects that Bredemarket has completed for clients over the last 18 months, as of February 16, 2022:

  • Fourteen (14) case studies
  • Eight (8) articles (blog posts)
  • Three (3) service offering descriptions
  • Three (3) white papers
  • Nine (9) RFx responses
  • Four (4) sole source responses
  • Six (6) proposal templates
  • One (1) technical leave behind
  • Two (2) biometric analyses
Inland Empire B2B Content Services from Bredemarket.

As it turns out, I didn’t hand out my local brochure to anyone at last night’s IDEA Exchange. (It was a small crowd, most of whom I already knew.)

But at least I’ve tabulated the numbers.

Now I just have to update all of my NON local collateral…

Bredemarket and September 2021 on the proposal side

I was looking over the Bredemarket blog posts for September, and I found some posts that addressed the proposal side of Bredemarket’s services. (There are also blog posts that address the content side; see here for a summary of those posts.)

As a starting point, what proposal services has Bredemarket provided for its clients? I quantified these around the middle of the month and came up with this list.

And I’ve been working on additional proposal projects for clients that I haven’t added to the list yet.

Now if you’ve already read my September 2021 content post, it seems like I’ve been repeating myself. Well the repetition ends here, because my other big proposal-related accomplishment for the month was my Association of Proposal Management Professionals Foundation certification.

For details on my certification, see https://www.credly.com/badges/f177cbf8-e085-4fae-943a-1e418d86c872.

This will not only allow me to provide better proposal services to biometric firms (yes, yes, I am a biometric proposal writing expert), but also to other firms.

What other firms?

I’ll let you know.

If I can provide proposal services for you:

Using Toggl Track to quantify proposal services for marketing purposes

Bredemarket’s slogan should be “better late than never.” It took me a year to print business cards, and it has taken me almost a year to quantify my proposal services work for clients. But Toggl helped me quantify my work.

Incidentally, this post is NOT sponsored by Toggl. If I were smart I would have pitched this post to Toggl and gotten something substantive in return. But I’m not that smart; I’m just a happy Toggl Track user. Sure the service has had a couple of hiccups in April and August, but Toggl responded to these hiccups quickly. In general, Toggl Track has been very useful in tracking time, gathering data to bill clients, and (as I just discovered this week) very useful in quantifying Bredemarket’s work and accomplishments.

Quantifying hours per proposal

The whole Toggl Track quantification exercise started over the last couple of weeks, when I had two separate discussions with firms regarding the number of hours that a contractor usually spends responding to a request for something (proposal, information, comment, etc.). Acronym lovers can use RFx, RFP, RFI, RFC, etc. as needed.

After the second client raised the issue, I realized that my Toggl Track data contained time data on all of my billable proposals work. (Helpful hint: even with the free version of Toggl Track, you can set up project names to keep track of billable hours, although you have to manually calculate the billing yourself.)

So I logged into Toggl Track, selected the billable projects that I knew had Rfx hours, downloaded a comma-separated values (csv) version of all of the data from January 1, 2021 to present, opened the csv file in Excel, filtered out the columns that I didn’t need, filtered out the rows that didn’t pertain to RFx work, sorted the data by description (for example, “AFIS proposal for Noname County”), then subtotaled the hours at each change of description.

And then I realized that I did something wrong.

When the Toggl Track data was loaded into Excel, it used a standard hours-minutes-seconds format. What that meant was that the subtotals also displayed in a standard hours-minutes-seconds format. So if I had three time entries—one for 10:00:00, one for 9:00:00, and one for 8:00:00—the resulting subtotal would be 3:00:00, or only three hours.

Whoops.

I played around a bit with the number formats in the Duration column, and found a format (displayed in Excel as “37:30:55”) that correctly rendered my subtotals—in the example above, yielding the correct value of 27:00:00, or 27 hours.

So once I got the subtotals to work correctly, what did I find, based on my own RFx proposal work data?

  • One of my projects required approximately 20 billable hours of work.
  • Three of the projects required less than 20 billable hours per project.
  • The remaining three required more than 35 billable hours per project.

Obviously my results do not apply to other independent contractors, and certainly do not apply to employees who are involved much more intimately in a company’s proposal process. So don’t try to extrapolate my numbers and make the declaration “Studies show that nearly half of all RFx responses require over 35 hours of work per person.”

But this data gave me the information that I needed in my discussions with the second firm.

But this exercise raised another question that I should have answered long ago.

Quantifying total proposal work

As Bredemarket, I have not only worked on RFx responses, but have also worked on sole source responses, and on proposal templates.

But I’ve never compiled a definitive overview of all of my proposal work.

Now I’ve certainly discussed bits of my proposal work here and there. You’ve probably already seen the testimonial that I received from a client regarding my proposal template work:

“I just wanted to truly say thank you for putting these templates together. I worked on this…last week and it was extremely simple to use and I thought really provided a professional advantage and tool to give the customer….TRULY THANK YOU!”

But after the proposal hours exercise above, I decided that it was time to quantify this work.

  • How many competitive proposals have I worked on for clients?
  • How many sole source responses have I worked on for clients?
  • How many of these “extremely simple to use” (my client’s words, not mine) templates have I assembled?

Obviously I had all the data; I just had to pull it together.

So I went to Toggl Track (and to other sources) to quantify my total proposal work, searching for billable (and in the cases of Bredemarket’s own proposals, nonbillable) work and identifying all the projects.

Sharing the quantification

Once that was done, I was able to create a neat handy dandy summary.

Which I put into a brochure.

Bredemarket Proposal Services (September 10, 2021)Download

Which I then added to various pages on the Bredemarket website.

September 10, 2021 iterative revision to https://bredemarket.com/bredemarket-and-proposal-services/.

And, of course, I’ll share the information in this blog post when I publish it and distribute it via my social media outlets-not forgetting Instagram, of course. (Did you notice that my statistical graphic is square? Now you know why.)

And I need to share this information in one more place, but that’s a topic for another time.

Can my proposal services help you?

If my experience (now with better quantification!) can help you with your proposal work, then please contact me.

DHS TSA mDL Public Meeting general observations

As I previously noted, today (June 30, 2021) was the day for the Department of Homeland Security’s Transportation Security Administration to hold its public meeting on its Request for Comment on “Minimum Standards for Driver’s Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes; Mobile Driver’s Licenses.” (See PDF or text version. The second link contains the method for providing comments.)

I will not provide a recap of the comments made by participants during the meeting, but will instead provide some general observations.

Incidentally, the list of all meeting participants will be made public at some point, and it’s possible that the chat transcript from the meeting will also be made public at some point.

Agreement and disagreement among the participants

As can be expected, there were a variety of views expressed at the meeting, ranging from industry comments about the items that should be in the DHS standard, to privacy advocates who questioned why DHS was implementing a standard at all. One example:

  • Industry participants, such as myself, were enthusiastic about the ability of a mobile driver’s license (mDL) to automatically update itself when new information became available at the DMV. For example, if I move to a new address, the DMV can automatically update the mDL on my smartphone to reflect the new address.
  • Privacy participants were, to put it mildly, a bit less enthusiastic about this feature. Physical driver’s licenses are updated as infrequently as every ten years; why should digital driver’s licenses be any different?

But there was apparent agreement between the industry and privacy participants about one possible feature on mDLs – the ability to control the data that leaves the smartphone and is sent to the verifying official. Everyone seemed to agree that this information should be granular, and that the mDL should not automatically send ALL available information on the mDL.

Let me provide an example. When I go to a bar and use my physical driver’s license to prove my age, the verifier (Jane Bartender) is provided access to my name, my address, my date of birth, my height, my (claimed) weight, and all sorts of personal information that would freak out your average privacy advocate. NONE of this information is needed to prove my age, not even my date of birth. All that the verifier needs to know is whether I am over the age of 21. An mDL can be designed to specifically state ONLY that I am over the age of 21 without revealing my birthdate, my address, or my (claimed) weight.

(You’d think that the privacy advocates would be thrilled about this granularity and would urge people to use mDLs because of this privacy benefit, but privacy and security folks are naturally suspicious and have a hunch that all of the information is being provided in the background anyway through double-secret means.)

But are the participants ready to respond to the RFC?

I had one other observation from the meeting. Before sharing it, I should explain that the meeting allowed the participants to ORALLY share the views that they will subsequently express in WRITTEN comments on or before the July 30 deadline.

And based upon the oral comments that I heard, some of the participants are ready to share their written comments…and others are not.

There were participants who spoke to the DHS about their items of interest, not only briefly stating these items, but WHY these items should be important to the DHS and to the general public.

And then there were participants who concentrated on unimportant details that were NOT of interest to the DHS or the general public. I won’t provide specific examples, but let’s just say that some participants talked about themselves rather than about DHS’ needs.

If these participants’ written comments are of the same tone as their oral comments, I can assure you that their comments will not influence the DHS in any way. Although I guess they can go back to their organizations and proudly proclaim, “We told the DHS how important we are!”

The DHS doesn’t care how important you are. In the DHS’ mind, you are not important. Only the DHS is important. (Oh, and the Congresspeople who fund the DHS are important, I guess.)

Perhaps in the next 30 days these other participants will take a look back at their message drafts and ask themselves the “So what?” question. What will motivate the DHS to incorporate desired features into the standard? And why should they?

And, as always, I can help. If nothing else, I can confidentially review your draft comments before submission and provide some suggestions. (Yes, it’s shameless plug time.)

If I can help you with your RFC response:

Or perhaps you are ready to respond now. I guess we’ll all find out when the DHS publishes its final standards, which may or may not reflect your priorities.

The DHS RFI “Minimum Standards for Driver’s Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes; Mobile Driver’s Licenses” is NOT due on June 18 (it’s now due July 30)

Back in April I wrote about a Request for Information that was issued by the Department of Homeland Security. Its title: “Minimum Standards for Driver’s Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes; Mobile Driver’s Licenses.”

The information was due to DHS on June 18 (tomorrow), and my post included a “shameless plug” offering to help companies with their responses.

No company requested my assistance.

But all is not lost, because you can STILL request Bredemarket’s assistance in composing your responses, because, according to Jason Lim, the due date has been extended.

DHS will hold a virtual public meeting on June 30, 2021 on mDL REAL ID RFI to answer questions regarding the RFI and to provide an additional forum for comments by stakeholders and other interested persons regarding the issues identified in the RFI.

DHS is also extending the comment period for the RFI by 42 calendar days to provide an additional period for comments to be submitted after the public meeting. New deadline is July 30, 2021.

If you want to register for the public meeting, click on the link at the bottom of Jason Lim’s LinkedIn post. I’ve already registered myself (the meeting starts at 7:00 am PDT, but at least I don’t have to commute to go to the meeting).

And the shameless plug still applies: if you need assistance in managing, organizing, writing, or checking your response, contact me (email, phone message, online form, appointment for a content needs assessment, even snail mail). As some of you already know, I have extensive experience in responding to RFIs, RFPs, and similar documents, and have been helping multiple companies with such responses under my Bredemarket consultancy.

Requests for Comments (RFCs), formal and casual

I don’t know how it happened, but people in the proposals world have to use a lot of acronyms that begin with the letters “RF.” But one “RF” acronym isn’t strictly a proposal acronym, and that’s the acronym “RFC,” or “Request for Comments.”

In one sense, RFC has a very limited meaning. It is often used specifically to refer to documents provided by the Internet Engineering Task Force.

A Request for Comments (RFC) is a numbered document, which includes appraisals, descriptions and definitions of online protocols, concepts, methods and programmes. RFCs are administered by the IETF (Internet Engineering Task Force). A large part of the standards used online are published in RFCs. 

But the IETF doesn’t hold an exclusive trademark on the RFC acronym. As I noted in a post on my personal blog, the National Institute of Standards and Technology recently requested comments on a draft document, NISTIR 8334 (Draft), Mobile Device Biometrics for Authenticating First Responders | CSRC.

While a Request for Comments differs in some respects from a Request for Proposal or a Request for Information, all of the “RFs” require the respondents to follow some set of rules. Comments, proposals, and information need to be provided in the format specified by the appropriate “RF” document. In the case of NIST’s RFC, all comments needed to include some specific information:

  • The commenter’s name.
  • The commenter’s email address.
  • The line number(s) to which the comment applied.
  • The page number(s) to which the comment applied.
  • The comment.

Comments could be supplied in one of two ways (via email and via web form submission). I chose the former.

Cover letter of the PDF that I submitted to NIST via email.

On the other hand, NIST’s RFC didn’t impose some of the requirements found in other “RF” documents.

  • Unlike a recent RFI to which I responded, I could submit as many pages as I liked, and use any font size that I wished. (Both are important for those respondents who choose to meet a 20-page limit by submitting 8-point text.)
  • Unlike a recent RFP to which I responded, I was not required to state all prices in US dollars, exclusive of taxes. (In fact, I didn’t state any prices at all.)
  • I did not have to provide any hard copies of my response. (Believe it or not, some government agencies STILL require printed responses to RFPs. Thankfully, they’re not requiring 12 copies of said responses these days like they used to.)
  • I did not have to state whether or not I was a small business, provide three years of audited financials, or state whether any of the principal officers of my company had been convicted of financial crimes. (I am a small business; my company doesn’t have three years of financials, audited or not; and I am not a crook.)

So RFC responses aren’t quite as involved as RFP/RFI responses.

But they do have a due date and time.

By Arista Records – 45cat.com, Fair use, https://en.wikipedia.org/w/index.php?curid=44395072

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.

Are you responding to the DHS RFI, “Minimum Standards for Driver’s Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes; Mobile Driver’s Licenses”?

I already posted about this Request for Information (RFI) on LinkedIn and Facebook, but I wanted to highlight the details of the Department of Homeland Security’s recent request (see PDF or text version).

https://www.govinfo.gov/content/pkg/FR-2021-04-19/pdf/2021-07957.pdf

The RFI delves into a number of questions about treating mobile (i.e. smartphone) driver’s licenses as REAL ID-compliant. The RFI itself states:

DHS invites comments on any aspect of this RFI, and welcomes any additional comments and information that would promote an understanding of the broader implications of acceptance of mobile or digital driver’s licenses by Federal agencies for official purposes. This includes comments relating to the economic, privacy, security, environmental, energy, or federalism impacts that might result from a future rulemaking based on input received as a result of this RFI. In addition, DHS includes specific questions in this RFI immediately following the discussion of the relevant issues.

The RFI can be responded to by any member of the general public, although it is expected that the majority of responses will come from mobile driver’s license vendors and various interest groups. And trust me, there is a wide range of interest groups that are interested in this topic, and in the broader topic of REAL ID in general. Federalism itself is a popular topic when discussing REAL ID.

(Although personally, I believe that if the Federal Government is controlling air travel, and if the Federal Government is…obviously…controlling Federal facilities, then the Federal Government can implement rule-making regarding access. Needless to say, since all 50 states and several territories have adopted REAL ID, the decision has been made.)

While respondents can conceivably talk about anything in their responses, DHS (as noted above) has 15 specific questions to which it is seeking information (see section IV beginning on page 20325). Some are general, such as general questions about security, and some are more specific, such as question 4, which specifically focuses on DHS adoption of requirements derived from “Industry Standard ISO/IEC 18013–5: Communication Interfaces Between mDL Device and Federal Agency, and Federal Agency and DMV.”

Responses to the RFI must be submitted by June 18, and are submitted electronically. (Read the Commenter’s Checklist, and note that DHS prefers that respondents address all 15 questions.) I’m sure that a number of companies and organizations are already starting to think about their responses.

Shameless plug: if you need assistance in managing, organizing, writing, or checking your response, contact me. As some of you already know, I have extensive experience in responding to RFIs, RFPs, and similar documents, and have been helping multiple companies with such responses under my Bredemarket consultancy.