Salient Characteristics That Aren't
The program office hands you a draft statement of work for a commercial case-management and workflow platform that names one product's modules and specifies 'must include the Acme Rules Engine API, version 4.2 or later.' Estimated value is $1.6M over three years. The program manager explains that the incumbent's tool already integrates with the agency's identity system and that a competitor's demo 'didn't look as good.' You have 30 days before the solicitation must post to hit the customer's desired award date. The small business specialist believes four resellers and two small software firms could compete if the requirement were written functionally. Your market research file currently holds three vendor websites and one GSA schedule search.
1. Is the brand-name restriction supportable as written? What analysis and documentation would make it defensible - or kill it?
Read the worked answer
As written, it is almost certainly unduly restrictive, because the named product and the specific API version are describing a solution, not a need. The defensible question is: what must the platform do, and is the Acme API the only way to do it?
Work through three tests:
- Need vs. preference. The PM's real requirements appear to be (a) integration with the agency identity system, (b) workflow configuration without custom code, (c) case records retention compliant with agency policy. None of these requires a specific vendor's API.
- Brand-name justification. If a brand name is genuinely required, the file needs a written determination that the salient characteristics are essential to the government's needs, that market research confirms no other product meets them, and that the characteristics are not written around one product's incidental features. 'The demo looked better' is a preference statement, not a determination.
- The integration claim. Ask the technical team for the actual interface standard. If the agency's identity system supports a standard protocol, integration is a function of engineering effort, not of the product brand - and that changes the requirement.
If the restriction survives, add an 'or equal' provision with a purchase description built on salient characteristics rather than a catalog number, so the evaluation can test equivalence.
2. Rewrite the approach: how do you convert this requirement into something both competitive and evaluable?
Read the worked answer
Build the requirement from outcomes and interfaces, then let offerors propose products.
Step 1 - Extract the true salient characteristics. For each, state a measurable threshold: 'shall support SAML 2.0 or OIDC single sign-on with the agency's identity provider'; 'shall allow workflow configuration by administrative users with no vendor code changes'; 'shall retain case records for the period specified in agency records schedule X'; 'shall support at least 400 concurrent users with sub-two-second page load at stated load.'
Step 2 - Convert the API reference. Replace 'Acme Rules Engine API v4.2' with a functional statement of what the API must enable - programmatic creation and update of case records, event-triggered notifications, export in a documented format.
Step 3 - Make 'or equal' workable. Give offerors a clear path to demonstrate equivalence (a matrix mapped to the salient characteristics), and give evaluators a standard for judging it.
Step 4 - Structure the evaluation so the differentiators the PM cares about - integration effort, migration risk, user experience - are scored factors, not hidden in a brand name.
The PM's underlying fear ('the demo looked better') is a legitimate evaluation concern. Handle it as a demonstrated-capability factor with a scripted scenario, not as a pre-award exclusion.
3. You have 30 days. What does a proportionate market research plan look like, and what do you tell the customer about the date?
Read the worked answer
Thirty days is enough for meaningful research if it is sequenced rather than exhaustive.
Days 1–3: Review existing sources - GSA schedule and other government-wide contract vehicles, agency software inventories, prior procurement history, and spend data from comparable agencies. This answers 'who already sells this to government' cheaply.
Days 3–10: Post a sources-sought notice or RFI with the draft functional requirement, asking specifically about identity integration experience, migration from a similar legacy tool, and pricing models. Require short responses; five pages is plenty.
Days 10–18: Hold structured one-on-ones or a virtual industry day with the firms that respond, including the small businesses. Ask the same questions of everyone and log the answers.
Days 18–25: Draft the revised requirement, validate the salient characteristics against what you learned, make and document the set-aside decision, and confirm the estimated price is still realistic.
What to tell the customer: the posting date can hold only if the requirement is written functionally and the PM accepts an 'or equal' approach. If the PM insists on the brand name, the date slips - because a brand-name-only acquisition needs a justification the file cannot currently support. Give the PM that choice explicitly and in writing; it converts a schedule dispute into a decision the requiring activity owns.