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.

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.

(Bredemarket Premium) Getting competitive proposals WITHOUT submitting a FOIA request

One of the best ways to get competitive intelligence on a competitor is to request the competitor’s response to a government agency procurement, such as a proposal submitted in response to a Request for Proposal. This is done by submitting a request via the Freedom of Information Act (FOIA) or equivalent.

One note: this technique primarily applies to government agency procurements, since governments are often required by law to disclose this information. Bids submitted to private entities usually remain private.

Of course, actually getting the competitor’s response isn’t easy.

  • First, you have to submit the request in the proper format.
  • Second, you have to be detailed in what you are requesting, and you need to request everything that you want: the actual proposal itself, any follow-up correspondence such as a best and final offer, the agency’s evaluation score, and everything else. If you only request the original proposal, the agency is only obligated to provide the original proposal, and nothing else.
  • Third, you have to wait for the agency to prepare a copy of the proposal. Depending upon applicable law, the bidder may be able to redact portions of the proposal, and it usually takes some time for the agency and the bidder to agree on what can legally be redacted.
  • Fourth, you may have to pay (usually on a per-page basis) to receive the materials.

This entire process may take several months, and you can’t even request the material until after the procurement has been awarded, or perhaps contracted.

But guess what? You don’t always have to submit a FOIA-like request to get a copy of a proposal submitted to a government agency.

By Neep at the English-language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=3309749

And no, you don’t have to break the law; these proposals (and other valuable documents) can be obtained legally and ethically.

Subscribe to get access

Read more of this content when you subscribe today.

Subscribe to Bredemarket Premium to access this premium content.

  • Subscriptions just $5 per month.
  • Access Bredemarket’s expertise without spending hundreds or thousands of dollars.

(Bredemarket Premium) The multiple self interests of AFIS customers and vendors

In a prior post, I spent some time identifying the multiple stakeholders at a city police department (in my example, my hometown of Ontario, California) that is procuring an automated fingerprint identification system.

By Coolcaesar at the English-language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=15739992

If I may recycle what I previously said, here are those stakeholders:

  • The field investigators who run across biometric evidence at the scene of a crime, such as a knife with a fingerprint on it or a video feed showing someone breaking into a liquor store.
  • The examiners who look at crime scene evidence and use it to identify individuals.
  • The people who capture biometrics from arrested individuals at livescan stations.
  • The information technologies (IT) people who are responsible for ensuring that Ontario, California’s biometric data is sent to San Bernardino County, the state of California, perhaps other systems such as the Western Identification Network, and the Federal Bureau of Investigation.
  • The purchasing agent who has to make sure that all of Ontario’s purchases comply with purchasing laws and regulations.
  • The privacy advocate who needs to ensure that the biometric data complies with state and national privacy laws.
  • The mayor (Paul Leon as I write this), who has to deal with angry citizens asking why their catalytic converters are being stolen from their vehicles, and demanding to know what the mayor is doing about it.
  • Probably a dozen other stakeholders that I haven’t talked about yet, but who are influenced by the city’s purchasing decision.

Why is this important? And who are the multiple stakeholders OUTSIDE of the city police department?

Subscribe to get access

Subscribe to Bredemarket Premium to access this premium content.

  • Subscriptions just $5 per month.
  • Access Bredemarket’s expertise without spending hundreds or thousands of dollars.

Subscribe to get access

Read more of this content when you subscribe today.

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.