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.

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.

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.

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