The candid answers to the questions your program office keeps asking about contracting. None of this is the official line. All of it is what I would tell you over coffee.
Once you send your requirement, it's only the beginning. Solicit, evaluate, award, admin. An entire process kicks off the moment your package lands with contracting.
Quick deployment story: a program office walked a package over to me and on the way out one of them said "it's ordered!" That package had not even hit solicitation yet. The rest of this page answers the questions customers keep asking about everything that happens after you hit send.
The moment a requirement is ambiguous, three problems show up at the same time. Pricing gets unreliable because every vendor is bidding on a slightly different thing. Evaluation gets messy because you cannot compare apples when half the offers are oranges. And acceptance gets contentious because the contract does not clearly say what "done" looks like.
A clearly defined requirement tells every offeror the same story. It tells the CO what to write into the evaluation factors. It tells the winner what they are on the hook for. It tells the COR and the program office what to inspect at delivery. When the requirement is ambiguous, each of those roles ends up guessing, and every one of those guesses is a potential dispute later.
If your requirement is "we need better analytics," your contract is going to be a mess. If your requirement is "we need a cloud-based analytics platform that supports these specific use cases, at this performance level, accessible by these users, for this period," your contract has a fighting chance of ending cleanly.
The word "customer" does not capture what actually happens when you send a package to contracting. Nobody walks into a contracting office and says "I would like one contract, please." When you send a requirement, you are joining the acquisition team for that buy, and you own it alongside the CO from that point forward.
From the CO's perspective, you are now the technical expert on this requirement, whether you came in feeling like one or not. Your name is on the package. You answer the technical questions that come back from vendors. You attend the meetings. You sit on the evaluation panel and read proposals. You help shape the evaluation factors. You help design the quality assurance plan, because the COR and the program office are the ones who will actually measure performance after award. All of that work belongs to the acquisition team, and you are on the team.
This is not a soft ask. Acquisitions where the requester is engaged and invested produce better outcomes at almost every step. Acquisitions where the requester sends the package and disappears produce defensible but blunt outcomes. If you do not participate in shaping the strategy, you default to lowest price that technically meets your specification. That may be fine. It may also miss the thing you actually wanted.
Here is where I want you, as a partner, to show up:
The CO still owns the file, and there are moments where the CO has to overrule a specific ask because the FAR or the agency supplement requires it. That is fine. A CO working with an engaged partner can make the buy look like what the program actually needs. A CO working in a vacuum cannot.
If you are not going to participate, you get what you get and you don't throw a fit. Lowest price, technically acceptable, chosen by the CO without your input. That is the default when the requester opts out. If you want the buy to reflect what you actually need, you have to be on the team.
Zoom in on a vague requirement and you can watch the damage accumulate at every phase of the acquisition.
Market research. Vendors read the same sentence and respond with five completely different products. The CO cannot tell which one is closest to what you wanted, because the sentence did not tell them.
Solicitation. The CO has to translate your requirement into an evaluation section. A vague requirement forces vague evaluation factors, which means the CO cannot meaningfully score responses. Either the factors get padded with subjective criteria that invite protests, or the acquisition defaults to lowest price, which may not be what you wanted at all.
Evaluation. Proposals come back looking like they are solving different problems. Comparing them apples-to-apples becomes impossible. The cheapest offer is probably the one that interpreted the requirement loosest, and the most expensive is probably the one that guessed most conservatively. Both can be reasonable and still neither lands on what you actually needed.
Award. You are locked into the strategy you picked at the start. You cannot change strategies mid-acquisition. If the requirement was vague when the strategy was chosen, the foundation was already shaky, and now you have two options. Award against the criteria you wrote and accept that you may not be buying what you needed. Or cancel the acquisition and start the process over, which can add months and sometimes push the buy out of fiscal year entirely.
Administration. The contractor delivers what the contract says. If the contract is vague, "what the contract says" is contested ground. You want X, they delivered Y, and both sides have a defensible reading of the page. The COR's life gets hard. Your program's schedule slips. Amendments to clarify scope are expensive.
Every one of those costs shows up in time, money, or mission, usually all three. The investment in nailing the requirement before the solicitation is almost always cheaper than cleaning up a vague one after award.
Competition is the default for a reason, and the reason is not paperwork for its own sake. Three offers gives you price discovery, a quality signal, and protest resistance. One offer gives you the price that vendor wants you to pay, and not much leverage to push back on any of it.
Sole source is not illegal. It is legally allowed under the FAR's exceptions to full and open competition, and there are plenty of legitimate reasons to use it. What it does is shift the burden. You have to justify why no other source will work. You have to document it. Someone senior has to sign. The file has to survive review, and sometimes a protest.
Program offices sometimes land on sole source because they already know and like the vendor. That is a preference, not a justification. The CO is not being difficult when they push back on it; they are testing whether we can buy this competitively first, because if we can, we must. Competition is the default the FAR requires, and sole source is the narrow exception.
Worth knowing: everything we solicit gets posted publicly. A sole-source justification goes up on SAM.gov for the whole market to read, and your competitors will read it. A weak justification (we already have a good relationship with them, they made it through last time, we like working with them) gets picked apart in public. Protests get filed. Awards get sustained. Packages come back for rework. The speed you were trying to protect by sole-sourcing evaporates.
If your product really does have only one source, say so and show it. The J&A process exists exactly for that. Just do not expect "I already know who I want" to survive public review.
Salient characteristics are the testable features of a product or service that describe what you actually need, without naming a specific vendor or brand. They are how you stay competitive when you already have a favorite product in your head.
The phrase comes up most when a program office says "I need Brand X." The CO cannot just buy Brand X. Buying a brand by name means sole source, which means justification, senior approval, and a paper trail. Salient characteristics let you describe the thing without sole-sourcing. Instead of "Brand X Widget," you describe a widget that handles 12 amps, fits a 2U rack, supports IPv6, carries a five-year warranty, and ships within 30 days. Any vendor meeting those characteristics can compete. The CO runs a real competition. Brand X is welcome to win on the merits.
How to find the salient characteristics of what you need:
Salient characteristics are the bridge between "I know what product I have been using" and "the CO can buy a product that meets my need in a defensible way." The more honest and specific the list, the stronger the file around the buy.
Mostly no, despite how often you hear it said.
The FAR establishes an order of preference for supplies and services. GSA schedules are one of the preferred options under Part 8 in specific situations. Some agencies layer on a supplement that says "use GSA first" within certain scope. None of that adds up to a universal mandate for every buy.
In practice, you have options. GSA Schedules. GSA Advantage for commercial items. Open-market competitive buys under Part 12 or Part 13. Existing IDIQs. Agency BPAs. Which one is best depends on price, competition, lead time, and how well the vehicle fits the requirement. Sometimes GSA wins the analysis. Sometimes it does not.
Where GSA earns its reputation: speed and administrative cost. A buy that would take 90 days on the open market can close in under 30 on a Schedule. Under the Simplified Acquisition Threshold ($350K as of this writing), a GSA requirement can usually be turned around in a week or two. If you bring three GSA quotes with the package, that window shrinks to days. That is why program offices reach for GSA, and when the fit is right, it is a strong choice.
"It has to be GSA" is an answer you should be able to get a citation for if someone is telling you that. When you ask for the citation, the answer often turns into "it is easier on GSA" or "my office prefers GSA." Both of those are fine reasons to pick GSA when it fits. Neither of them is a mandate.
You have heard the stories. Hundred-dollar hammers. Ten-thousand-dollar toilet seats. The general sense that government always pays three times what a thing should cost.
Most of those stories are either old outliers that got reported badly, or they are specialized parts where the real price reflects what it cost to certify, test, and source a specific component to a specific documentation standard. A commercial toilet seat and a pressurized-aircraft toilet seat with redundant seals, traceable material certifications, and a twenty-year replacement window are not the same product.
The social media version of this runs year-round. A post goes viral with a photo of a $10,000 piece of hardware and a caption about wasteful government spending. Nine times out of ten, the post is missing the context that made the price reasonable. I have seen a $10,000 printer cited as an outrage, and the actual contract included unlimited ink and toner for five years. The price was a steal. The post did not mention the ink. Those posts travel fast because outrage travels fast, and the full context rarely travels with them.
Where government really does pay more, the reasons are usually legible. Specialized requirements. Low-volume production runs. Test and certification overhead. Compliance carrying costs. Specifications that programs ask for because somebody's life or mission depends on the thing working. All of that shows up in the price, and it should.
The version that matters day to day: government buys commercial things at close to commercial prices, usually with a bit of overhead for process. Government buys specialized things at prices that reflect the specialization. The hammer story is a meme, not the day job.
The single biggest thing you can do: give your CO more lead time.
A package that arrives six months before your need-date lets the CO run a proper acquisition. A package that arrives two weeks before need-date forces a rushed strategy that costs you options and often costs you money. The CO cannot compress solicitation periods, evaluation time, or review cycles past a certain point without creating real risk on the file.
Beyond lead time, these are the moves that actually move the needle:
None of this is hard. It just takes a habit of starting earlier and treating contracting like a real phase of the project, not a vending machine at the end of it.
Start the conversation with your CO six months before you need the contract. Not the package. The conversation. Every other problem on this page gets easier when the CO is in the room early.
Most bad requirements start because somebody wrote the product spec before they wrote the problem statement.
Start with the mission or outcome. What are you actually trying to accomplish? What does "done" look like for your program? Once you know the problem, you can ask who in the market solves it. Once you know who solves it, you can ask how they solve it. Once you know how they solve it, the product or service spec writes itself.
If you write the product spec first, you will end up with a requirement that looks suspiciously like the last vendor's brochure. That is how sole-source-by-accident happens. That is also how protests happen, because competitors read the requirement, recognize it, and file.
Order of operations: mission, problem, outcome, market capabilities, then requirement. Not the other way around.
Market research is the step that everyone skips, and the step everyone should do.
What market research is not: reading one company's website and writing a requirement that matches their product.
What market research is:
Good market research protects you. It tells the CO "yes, I looked, and here is why I am asking for what I am asking for." Thin market research tells the CO you wrote to a specific vendor and did not check. The file has to show one of those things, and only one of them is defensible.
Because the signature on the contract is theirs, and the regulatory and legal liability is theirs. If the acquisition goes sideways (sustained protest, CPARS dispute, IG finding, Congressional inquiry), the CO is the one writing the response.
When a CO pushes back on your requirement, they are not being difficult. They are doing the job. They see the risks you do not see because they see them every day across a dozen requirements. They read protest decisions for fun. They have watched a program office get the same thing wrong three times in a row and want to keep yours from being the fourth.
The best thing you can do with pushback is ask a different question: "what would it take to make this work?" That moves the conversation from adversarial to collaborative. Nine times out of ten, the CO can tell you exactly what they need in the package to proceed. The tenth time is where supervisors get involved, and even then, it is rarely about obstruction.
Saying "I don't know how to define this, I really need help" is one of the most useful things a customer can hand a CO. It redirects the acquisition onto a path built for uncertainty, instead of forcing a vague requirement into a process that expects clarity.
Here is what opens up on the CO side when a customer is honest about where they are:
The trap is pretending you have a clean requirement when you do not. That produces a brittle spec, which produces a solicitation that does not reflect what you actually need, which produces a contract that misses the target. By the time you notice, you are modifying the contract post-award, which is slower and more expensive than every one of the paths above.
Honesty up front is a shortcut. Say you need help. Let the CO pick the path.
Because you are optimizing for different things, and both of you are right.
You need: speed, the specific capability, predictable timelines, the vendor your team already trusts.
The CO needs: competition, a defensible file, compliance with the FAR and agency supplements, adequate review time, and a contract that does not fall apart in year two.
Both of those are legitimate, and they will not always point at the same answer. That friction is the system working as designed. The tension between "I want this now" and "I have to be able to defend this later" is what keeps both of you out of trouble at the end.
The partnership gets strong when the customer understands why the CO asks what they ask, and the CO understands why the customer has the timeline they have. Nothing magical. Just mutual translation.
Because the market is stronger when small businesses are in it, and because Congress and the FAR have decided that is worth protecting.
The policy framework is substantial. Part 19 of the FAR sets it up. SBA size standards define what counts as small. Agency small business goals push offices to hit specific percentages. Set-asides (small business, WOSB, SDVOSB, HUBZone, 8(a)) route specific opportunities to specific categories. The Rule of Two, now at FAR 19.502, says that if there is a reasonable expectation that two or more small businesses will bid at fair market prices, the buy gets set aside.
Beyond the policy, there is a practical reason. Small businesses are often how new capability enters the federal market. They are often more flexible, more responsive, and more willing to shape their work to a specific customer's problem. The government's pipeline of mid-size and large primes depends on a healthy small-business base underneath it.
The customer version: if you are early in shaping a requirement and a small business could do this work, lean into it. If a small business set-aside is legally required, the CO is going to tell you. Make that easier on them, not harder.
First, confirm whether it is actually stonewalling. Most of what gets called stonewalling is the CO asking for something the package is missing, or flagging a risk that has not been addressed. Ask the CO directly: "what specifically would need to change or arrive for this to move forward?" Get the answer in writing.
If the answer tells you what to fix, fix it.
If the answer does not tell you anything useful, or you get radio silence, try these in order:
One option worth knowing about is what people call CO shopping. Different COs have different risk tolerances, and a more experienced or less risk-averse CO may be willing to take on a project another CO has declined. There is a polite way to ask for this: have your supervisor contact the CO's supervisor, on the record, and ask whether another CO could take a second look at the package. Do not do this secretly, and do not walk CO-to-CO in the hallway hoping the second one does not notice. That path gets packages rescinded and working relationships destroyed. Your CO's colleagues talk to each other.
Even when you ask the right way, do not count on it. It depends heavily on manning, on whether another CO has the bandwidth, and on office egos. If nobody else is available, you are at the mercy of your current CO's judgment on the file. Sometimes that is the final answer.
The vast majority of the time, what looks like stonewalling is a CO trying to keep you from making a defensible bad decision. The times when it is real obstruction are rare, and when they happen, they resolve at the supervisor level, not at the CO level.
None of this is a manual for getting around your CO. It is the opposite. The best acquisitions I have ever worked happened when the customer understood what I needed and when, and I understood what they needed and when, and both of us treated the other as the partner we actually are.
That partnership does not start on the day the package hits the inbox. It starts six months earlier, when the program office has its first "what do we actually need?" conversation and brings the CO in. The sooner, the better. The more honest, the better. The more each side understands the other's job, the better the contract reads at the end.
Got a question you wish contracting would just answer honestly? Send it over and I will add it to this page.