Procurement from the engineer's chair

Lesson preparation and outcomes

Prerequisites: Architecture, risk records and basic work-breakdown estimates.

By the end, you can: Translate requirements/evaluation factors into technical evidence without inventing capability.

Worked scenario and practice feedback

A fictional solicitation requires citations and denial tests. A proposal claiming full authorization from the cloud brand lacks evidence. Map each requirement to deliverable, verification, owner, assumption and unresolved dependency; estimate implementation and review work separately.

Guided and independent practice: Use a synthetic requirement matrix. Independently find an ambiguous throughput target and draft a clarification for local review without sending or bidding.

Answer criteria: Exact solicitation criteria guide the response; no invented past performance, certification or agency approval; estimates state range/assumptions; no transaction or external message. If the local pack or interpreter is unavailable, trace the synthetic input, expected output and failure guard on paper; label execution unverified. Required practice uses no paid API calls, accounts, purchase, operational data or actual deployment.

At the Expert tier, senior engineers contribute to proposals, read solicitations, and brief contracting officers. The Leadership Track covered procurement from the leader’s altitude. This lesson is what the engineer at the keyboard needs to know to help win and execute federal AI contracts.

Part 1 Reading a solicitation as an engineer.

For a solicitation using the Uniform Contract Format, the sections below provide a useful engineering reading order. Other formats and exceptions exist under FAR 15.204; locate the equivalent instructions, evaluation criteria and requirements in the actual solicitation, and follow its controlling terms.

1. Section L: Instructions to Offerors. What you must submit. Page limits. Format. Deadlines.
2. Section M: Evaluation Factors. How you’ll be scored. This is where you decide whether to bid.
3. Section C: Statement of Work (SOW) or Performance Work Statement (PWS). What the work actually is.
4. Section H: Special Contract Requirements. Government-furnished property, security, data rights. Watch for traps.
5. Section J: Attachments. The technical reference documents, eval data samples, DD-254 (security classification specification).

What you are looking for as the engineer:

• The actual technical scope. Strip the requirements language and ask: what does the contractor have to deliver, and what does it have to do?
• The performance standards. What does “acceptable performance” mean? What is the eval criteria?
• The hidden complexity. Often in Section H or the attachments. “The contractor shall maintain ATO” is one sentence with months of work behind it.
• The schedule realism. Look at the period of performance and the major milestones. If the timeline is unrealistic, you’ll be expected to make it work anyway.

If the solicitation is unclear, vendors can submit questions (typically before a stated cutoff). Engineers should drive those questions; they’re the ones who know what’s actually being asked.

Part 2 The technical volume: what good looks like.

The technical volume is the proposal section that describes how you’ll do the work. As an engineer, you contribute to or write this directly.

A working structure:

1. Understanding the requirement. Demonstrate that you read the solicitation and understand the actual mission need behind it. Two pages. Don’t paraphrase the SOW back; explain what it really wants.
2. Technical approach. How you’ll execute. Architecture diagrams. Specific tools (named, justified). The phased plan with milestones.
3. Past performance specific to AI work. Not generic IT past performance. Cases where you delivered similar AI capabilities. Quantified outcomes.
4. Risk and mitigation. Honest risks. Specific mitigations. Not boilerplate.
5. Schedule and staffing. Who, when, doing what. With named individuals where the proposal allows it.

What evaluators read for:

• Specificity. Vague proposals lose to specific ones every time.
• Understanding of the work. Surface-level proposals get lower technical scores even if the writing is polished.
• Realistic schedules. Aggressive but achievable beats both “easy win” and “impossible heroics.”
• Risks acknowledged. Proposals that pretend there are no risks lose credibility.

What evaluators downvote:

• Boilerplate that doesn’t connect to the specific work.
• Architecture diagrams that don’t match the actual proposed implementation.
• Past performance that isn’t actually relevant.
• Buzzword density.

Part 3 Estimating level of effort honestly.

Estimate from a work breakdown, analogous evidence, review dependencies and uncertainty; no fixed underestimation percentage is assumed:

• Estimate the engineering work bottom-up. List every task. Estimate hours for each. State a low/base/high range and uncertainty drivers. Justify contingency from actual risks rather than a universal percentage.
• Add the non-engineering work. Project management, security/compliance documentation, deployments, training, customer meetings. Estimate these separately from the actual scope and uncertainty; no universal percentage is assumed.
• Add the surge requirements. Major milestones, demonstrations, security assessments. These compress effort into specific weeks. Plan for the spikes.
• Sanity-check against past performance. Use comparable work only after adjusting for scope, staffing, environment, reviews and workload. Explain material differences rather than copying its duration.

Two failure modes:

• Sandbagging. Padding the estimate so the team has slack. Sounds prudent; loses competitive bids. Find slack inside execution, not in the estimate.
• Heroic estimates. “We’ll do it in half the time the competition will.” Sounds aggressive; usually loses to a well-explained realistic estimate. Customers prefer the proposal they believe over the one that’s cheaper if they don’t believe it.

For AI work specifically:

• Estimate eval design, measurement and review explicitly.
• Estimate compliance/security artifacts and assessor/decision dependencies from the actual system; no universal ranking or percentage is assumed.

Part 4 Capability statements.

A capability statement is the one-to-two page document that introduces your organization to a potential federal customer. It is referenced often, especially for SBIR/STTR and OTA work.

A working structure:

[ORGANIZATION NAME]
[Logo, tagline]

CORE COMPETENCIES
- 3-5 bullets, what you actually do well. Specific.

DIFFERENTIATORS
- 2-3 bullets, what makes you distinct. Honest.

PAST PERFORMANCE
- 3-5 contracts. Customer, period of performance, value, role, outcomes.

NAICS CODES
- 541512, 541511, 541715, others applicable

CONTRACT VEHICLES
- GSA MAS, SeaPort-NxG, OASIS, other IDIQs you're on

CERTIFICATIONS
- SDVOSB, 8(a), HUBZone, ISO 9001, CMMC level
- Cleared facility status if applicable

POINT OF CONTACT
- Name, title, email, phone
- UEI (Unique Entity ID) and CAGE code (the DUNS number was retired in 2022; SAM.gov issues the UEI now)

What good capability statements have:

• Specificity. “Applied AI for federal customers” is weak; “Production RAG systems on FedRAMP-Moderate cloud for federal civilian agencies” is strong.
• Verifiable past performance. Customers will check.
• Realistic differentiators. “Industry-leading” without evidence is noise.
• The right NAICS codes. Federal procurement is heavily code-driven.

Part 5 Working with the contracting officer.

The contracting officer (CO) is the only person who can bind the government to a contract. Everyone else can recommend, evaluate, request, or sign off; only the CO commits.

Three things engineers should know about COs:

• They protect the government’s interest. Their job is to ensure compliant, fair, accountable procurement. They are not your adversary; they are also not your champion.
• They communicate through documented channels. Use the solicitation/contract’s documented authorized channels. An email alone does not necessarily modify a contract; scope and authority must be verified by the responsible officials.
• They sit between you and the program office. The COR (Contracting Officer’s Representative) is the day-to-day technical point of contact, often within the program office. The CO is the contractual decision authority.

Three habits that make COs want to work with you:

• Be on time. Every deliverable on or before the due date. Reputations form fast.
• Be honest about scope. If something is creeping outside the contract, raise it early through the right channel. Surprises in the final month are how contracts go sideways.
• Document everything. Decisions, changes, deliverables, customer feedback. The trail protects everyone.

Part 6 Funding purpose is a review dependency.

Appropriation purpose, time, amount, account rules and contract scope constrain work; account labels alone do not establish that a particular build or operation is permissible. Describe the proposed technical work and any scope change, then refer funding-law and contractual decisions to the responsible financial, legal and contracting officials. An engineer’s estimate is not authority to commit funds.

In the fictional scenario, an operations task changes into developing a new capability. Record the changed requirement, affected deliverable, estimate and unresolved funding/scope review. Do not infer permission from an RDT&E or O&M label, and do not proceed with any monetary transaction in this classroom exercise.

Interface/reference limits

Use the workflow reference to connect task, model, deployment, harness/tools, evidence and the responsible human decision. Synthetic demonstrations establish only the stated tested conditions.

Primary source checked October 2, 2026: FAR Subpart 15.3. This orientation does not authorize procurement or replace the controlling solicitation and professional review.