Home

Working with the Government

Published 04/11/2018

In our trio of client types, government is the newest.

We’ve been working with private companies and entrepreneurs since we opened our doors in 2010, but Uncle Sam didn’t come onboard until 2017.

Since then, we’ve won several contracts at various levels of government (albeit we’ve lost more than we’ve won, which is a big takeaway from working with the government).

With that said, working with the government has been way more difficult to break into than it was with other types of clients.

Part of that is because Gunner Technology is not a typical software company and our model of doing business is different than traditional companies.

And one thing you learn quickly when working with the government is anything non-traditional initially is viewed as a pit viper.

We’ve learned a lot more in our time working with the government and we wanted to share that for others looking to do the same.

Acronym Soup

Your head will start to spin with the number of acronyms that will come flying at you.

GSA. SWEP. AAPC. CPI. OSBP.

I mean, there are hundreds if not thousands.

Do yourself a favor and search the Internet for the phrase “Guide to Government Acronyms” – print it out and keep it with you whenever you’re dealing with the government.

COTS, MOTS, GOTS and NOTS

 

Speaking of acronyms, there are a few you really need to know, including these four as they describe the type of work the government is looking for.

When you’re searching for government work, you’ll be trying to separate all the potential opportunities into either “good” or “service.”

Personally, we offer a service, so we’re only going to be interested in opportunities that are service-based.

The problem is trying to separate the two as the government often is unclear on which they are looking for.

So you’ll have to decode these acronyms or straight up ask the contracting agency during Q&A.

But what they heck do they mean?

A COTS (commercial off-the-shelf) product is one that is used “as-is.” COTS products are designed to be easily installed and to interoperate with existing system components. Almost all software bought by the average computer user fits into the COTS category: operating systems, office product suites, word processing, and e-mail programs are among the myriad examples. One of the major advantages of COTS software, which is mass-produced, is its relatively low cost.

A MOTS (either modified or modifiable off-the-shelf, or military off-the-shelf, depending on the context) product is typically a COTS product whose source code can be modified. The product may be customized by the purchaser, by the vendor, or by another party to meet the requirements of the customer. In the military context, MOTS refers to an off-the-shelf product that is developed or customized by a commercial vendor to respond to specific military requirements. Because a MOTS product is adapted for a specific purpose, it can be purchased and used immediately. However, since MOTS software specifications are written by external sources, government agencies are sometimes leery of these products, because they fear that future changes to the product will not be in their control.

A GOTS (government off-the-shelf) product is typically developed by the technical staff of the government agency for which it is created. It is sometimes developed by an external entity, but with funding and specification from the agency. Because agencies can directly control all aspects of GOTS products, these are generally preferred for government purposes.

A NOTS (niche off-the-shelf or not off-the-shelf) Niche off-the-shelf refers to vendor-developed software that is for a specialized and narrow market segment, in comparison to the broad market for COTS products.

Also, it hasn’t been formalized, but there is also something we call FOTS or “Frankenstein off-the-shelf” which is when the government wants a bunch of COTS products fused with duct tape to fill a requirement.

Typically, we are looking for GOTS and NOTS work.

We want to build something either with the government’s assistance or for the government that doesn’t exist yet.

We’re looking to make them a suit tailored specifically for their bodies rather than sell them one off the floor.

Can we just talk about this?

Some opportunities will have a “pre-bid conference,” which are a cattle-call or press conference of sorts where bidders can attend in person or (sometimes) dial into a conference line.

This is your opportunity to ask questions, but not have a dialog, but in a very formal, impersonal setting.

Most opportunities don’t even have this, and you are relegated to “Q&A” where you email the agency all the questions you have about the opportunity.

All bidders submit questions and the agency responds with an updated posting that contains the “answers” to these questions.

I put answers in quotes because often, the answers don’t provide any additional insight into the original question.

No follow up questions.

This is so different than how we normally operate where we have at least five pre-meetings with a client – all non-billed – where we interview the client to discuss the needs of the project as well as the vision.

There’s as much back and forth needed until we are both comfortable with the direction of the project.

So… Agilefall?

In the software world, most of the opportunities claim to want an “Agile” project management approach.

In fact, some even require certified SCRUM masters or the like.

And yet, when you read into the opportunity, the agency wants firm dates, budgets and deliverables – and probably a gantt chart or two.

All of which are hallmarks of Waterfall Project Management – the antithesis of Agile Project Management.

We have reconciled this with an approach we call “Agilefall” which creates hard milestones and then backs into those milestones using an agile approach.

RFP vs RFI vs RFQ

Again with the acronyms!

Opportunities comes in three different flavors (largely), so make sure you know what kind of opportunity you’re going after.

Short for “request for information,” the RFI is really a preliminary document used by companies that don’t understand the marketplace they’re about to enter. In the case of a company searching for a CRM, for instance, it would use an RFI if it had no prior experience with CRM and wanted to gain an understanding on the range of options in the CRM space.

Because the RFI is more of a fact-finding document, you’ll want to ask open ended questions, ones that allow the vendor to talk about its full range of offerings. Typically, the RFI will state the broad business challenges you’re having, and then the vendor can tailor its response within the context of those challenges. Often times, the vendor will explain its position in the marketplace (for instance, what industries it specializes in), how it licenses its product, and what other fees you can expect.

An RFP, “Request for Proposal,” is a document that asks vendors to propose solutions to a customer’s problems or business requirements. An RFP is usually what follows an RFI; in fact, it’s rare that a company will go from an RFI to an RFQ (for reasons that will become clear below). An RFP should contain much more specificity in terms of what a company’s needs are by outlining the business goals for the project and identifying specific requirements that are necessary for the work being requested. The key to this document is that there is sufficient detail to give vendors the context they need in order to propose a valid solution, yet it still needs to allow enough leeway for the vendors to apply creativity and best practices to fulfill those needs.

Short for “request for quotation,” the RFQ is an even more detailed document that drills down to the exact specifications required by the company. In a situation where an RFQ is used for a b2b software project, the company knows enough about its current system and exactly how it wants to change or improve it in the future.

Unlike the RFP, which allows for the flexibility of the vendor to suggest creative solutions to the problem, a company deploying an RFQ isn’t looking for creativity, but rather for the vendor to deploy the software using predetermined specifications. Typically, the RFQ contains a table that lists each requirement and then asks the vendor to assess its ability to meet that requirement. The vendor then will specify whether it can meet the requirement out of the box, whether it will require some configuration, whether it will require some custom code, or whether it will require leveraging a third party vendor.

Scoring and Set Asides

Contracts can no longer be awarded based on cost alone.

Meaning, just because you’re the low bidder doesn’t mean you’ll get the gig.

Most will publish a scorecard and whichever bidder scores the highest, wins the gig.

Also, some scorecards award points for things like “small business” or “minority owned business”, veteran, woman, etc.

So if you qualify, keep an eye out for those opportunities.

Be patient

It’s a long but profitable road.

The government can be a lucrative client and a good client, but it’s hard to earn their trust.

Keep trying and build that portfolio and you’ll eventually break in.