Contracting & teaming

GS / 04

Define the role.
Check the fit.

Information for agency technical teams, acquisition stakeholders and prime contractors evaluating a software, platform or IT operations contribution.

Jump to the fit checklist

01 / Government organizations

Describe the
requirement.

A useful starting point is the service to change, the current environment and the result your team needs to accept. Include the procurement stage and any published requirements that shape the discussion.

Current workflow, users and systems
Desired output and acceptance authority
Timing, dependencies and applicable constraints

Prepare a project inquiry

02 / Prime contractors & partners

Identify the
work package.

Define the technical contribution your team needs, how it connects to other workstreams and which proposal or delivery commitments must be confirmed.

Solicitation reference or opportunity summary
Proposed role, interfaces and expected workshare
Proposal deadline and planned delivery period

Prepare a teaming inquiry

Opportunity fit

Resolve these questions
before committing work.

Use the checklist to structure a technical fit discussion. Requirements and evidence should be confirmed for the specific opportunity.

Teaming and opportunity fit checklist
Area	What to establish
Technical scope	The application, integration, platform or operations work package; dependencies; deliverables; and exclusions.
Delivery responsibilities	The lead for each workstream, interfaces with other partners, review cadence and who accepts the work.
Staffing and access	Required skills, proposed roles, location, availability and any clearance, citizenship or system-access requirements to verify.
Proposal support	Specific technical sections, estimates, resumes or evidence requested; review owners; and submission deadlines.
Commercial assumptions	Workshare, rate or pricing assumptions, contract type, payment terms, travel and changes to scope.
Qualification evidence	Legal entity details, registration status, relevant identifiers, past-performance requirements and any required certifications or eligibility.

Download the editable teaming checklist

Illustrative scope / Platform work package

Turn “cloud support”
into a scope someone
can evaluate.

This example shows the level of detail that makes responsibilities and acceptance reviewable. It is not a past-performance claim or a fixed offer.

Objective: Automate deployment of one application into an agreed non-production environment.
Deliverables: Infrastructure definitions, pipeline configuration, deployment records and a rollback runbook.
Dependencies: Access to the cloud account and source repository; approved network and identity design; application build instructions.
Acceptance: Deploy an identified version through the agreed checks, then demonstrate the documented rollback in the test environment.
Outside this example: Application feature development, production authorization, cloud usage charges and ongoing on-call coverage.

Use this structure for your project

Contracting facts

Confirm qualifications
against the opportunity.

Goodfellow’s legal entity details, UEI, CAGE code, SAM registration, contract vehicles, set-aside eligibility, certifications and personnel clearances are not published here. Confirm applicable evidence directly before relying on it in a proposal or award process.

A technical fit discussion establishes the possible contribution. It does not establish contracting eligibility, personnel availability or an authorization to operate a system.

Official SAM.gov registration guidance

Practical questions

Before the first
working session.

Do we need a finished statement of work?

No. Bring a description of the current system, the outcome you need and the constraints you already know. The first task is to identify missing information, boundaries and the next decision. A price or start date needs a sufficiently defined scope.

How should we separate discovery from implementation?

Use an assessment scope when the architecture, access or dependencies are not understood. Its outputs should support a decision: a current-state map, findings, options and an implementation estimate with assumptions. Implementation can then be scoped against that evidence.

Can a work package fit inside our existing delivery process?

Bring your backlog, engineering standards, review process and release constraints. Define the contribution and its interfaces with the prime or agency team, then agree on reporting, access and acceptance. The delivery model is confirmed in the engagement.

What determines cost and schedule?

The number of systems and environments, data quality, access lead times, security and accessibility requirements, testing depth, migration windows and support obligations. Assumptions and exclusions should accompany an estimate; changes should be reviewed before expanding the work.

What does ongoing support include?

Coverage hours, incident severity, response expectations, maintenance duties and escalation responsibilities need a separate agreement. A build or transition scope does not automatically include a staffed service desk or 24/7 on-call support.

Who owns the code and work products?

Intellectual property, licenses, data rights, repository access and delivery formats are established in the contract and applicable terms. Identify these before implementation, including restrictions on third-party components.

What should be kept out of the initial inquiry?

Keep the overview non-sensitive. Use a public opportunity reference where available. Credentials, controlled data and procurement-sensitive documents should use a channel agreed with the responsible organization.

Scope the work

Define the contribution
your team needs.

Start with the current system, the change you need, and the date that matters.

Prepare a teaming brief

Define the role. Check the fit.

Describe the requirement.

Identify the work package.

Resolve these questions before committing work.

Turn “cloud support” into a scope someone can evaluate.

Confirm qualifications against the opportunity.

Before the first working session.

Define the contribution your team needs.