The difference between a subcontractor that makes a prime's life easier and one that creates overhead isn't usually technical capability — it's delivery discipline. Prime contractors need subs who integrate smoothly into their delivery cadence, produce documentation that passes COR review without rework, and generate ATO evidence as a byproduct of how they work rather than a scramble at the end of the period of performance.
This article describes how a federal IT subcontractor should structure delivery to be a genuine asset to the prime programs they support.
The Prime's Perspective on Sub Delivery
Prime contractors carry CPAR ratings, contract compliance risk, and client relationship responsibility for work their subs perform. From the prime's perspective, a sub that:
- Misses sprint commitments without early notification
- Produces deliverables that need multiple revision cycles
- Creates ATO documentation separately from their technical work
- Requires excessive PM oversight to stay on track
...is a liability, not an asset — regardless of their technical quality.
The sub that prime BD teams compete to include in future proposals is the one who:
- Shows up to every standup prepared and concise
- Surfaces risks before they become issues
- Produces first-draft documentation that's 90% ready
- Manages their own quality
Delivery model is the mechanism that produces these behaviors consistently.
Sprint Cadence and Government Program Integration
Most DoD and federal IT programs run some variant of agile delivery — SAFe, Scrum, or a hybrid. Government programs often have slower sprint cadences than commercial software (2–3 week sprints are common rather than 1-week), driven by government review cycles.
A sub's sprint cadence needs to synchronize with the prime's program cadence:
Sprint planning: The sub participates in the prime's sprint planning, committing to specific story-point allocations and clearly identifying any blockers that require prime or government coordination. Dependencies are documented in the sprint plan, not discovered mid-sprint.
Daily standup: Brief, structured updates covering: what was completed yesterday, what's planned today, blockers. Subs should not require extended time in government standups. Three sentences per active workstream is the target.
Sprint review: Subs demonstrate completed work to the prime's PM and, where appropriate, the government COR. Working software is the measure of progress — status percentages on work in progress are not acceptable sprint review outputs.
Sprint retrospective: Subs contribute candidly to retros, including identification of process issues on their side. Primes need subs who are honest about what's working and what isn't — not subs who only report good news.
Documentation Standards That Survive Government Review
Government program documentation fails COR review for predictable, avoidable reasons:
Failure mode 1 — Wrong format: CDRLs specify documentation formats. A system design document that doesn't follow the DI-IPSC format specified in the CDRL will be rejected regardless of content quality. Know your CDRLs.
Failure mode 2 — Generic language: Government reviewers reject documents that could describe any system. Effective government documentation is specific to the system being described — specific IP addresses, specific configuration values, specific personnel roles. "Access controls are implemented using industry standard practices" fails. "Access is restricted to named IAM roles documented in Appendix A, with least-privilege policies defined in the Terraform modules at [path]" passes.
Failure mode 3 — Outdated architecture diagrams: Architecture diagrams that don't match the deployed system are a common ATO submission problem. IaC-generated architecture documentation that's automatically updated reduces this failure mode.
Failure mode 4 — Missing evidence links: Security controls documentation needs to link to specific evidence — screenshots, exported configurations, test results. Assertions without evidence don't satisfy ATO reviewers.
ATO Evidence Generation as a Delivery Byproduct
ATO documentation is expensive when treated as a separate phase. It's inexpensive when baked into how the team works:
IaC generates system configuration documentation: Infrastructure-as-code modules document the deployed state by definition. A well-organized Terraform codebase with a documented module structure is a substantial fraction of the system configuration section of an SSP.
Pipeline artifacts are evidence: CI/CD pipeline outputs — SAST scan results, SCA reports, container scan results, test coverage reports — are directly reusable as ATO evidence artifacts. DevSecOps pipeline controls for government programs describes how to structure pipeline output for ATO reuse.
Automated compliance checks generate POA&M inputs: STIG compliance scanning results can be exported directly as POA&M findings. STIG compliance automation with Kubernetes covers this for container environments.
Change logs are audit trails: Commit history, PR descriptions, and deployment logs constitute an audit trail for configuration change management. These are available at no additional documentation cost if teams maintain clean commit hygiene.
Status Reporting That Gives Primes What They Need
Prime PMs report to COs, CORs, and their own program leadership. They need sub status in a format they can roll up without translation:
Weekly status report format (1 page max):
- Accomplishments this period (completed items, not in-progress)
- Planned next period (specific, testable commitments)
- Issues and risks (with proposed mitigations or ask-for-help clearly stated)
- Key metrics (if applicable: velocity, ATO control coverage, test pass rate)
Issue escalation: Issues that affect the prime's deliverable timeline must be surfaced the day they're identified — not at the weekly status meeting. Prime PMs need time to adjust their own reporting and coordination. Surprises at the weekly meeting are a delivery failure.
Ahead-of-time notification for misses: If a sprint commitment is at risk, notify the prime PM two or more days before the sprint review — not at the sprint review. Primes can adjust and communicate if given time; they can't adjust a surprise.
See how Rutagon structures delivery on prime programs →
Frequently Asked Questions
What delivery methodology works best for federal IT subcontracting?
Most federal IT programs use Scrum or SAFe variants with 2–3 week sprints. The sub's cadence needs to synchronize with the prime's program cadence rather than operating independently. Flexibility to match the prime's sprint structure is more important than the specific methodology.
What documentation does a federal IT sub typically produce?
CDRL-specified deliverables as defined in the subcontract — often including a System Design Document, Interface Control Document, Test Plans and Reports, and SSP contributions. Beyond CDRLs, subs typically produce sprint backlogs, status reports, and architecture diagrams as standard delivery artifacts.
How should federal IT subs communicate risks to the prime?
Early and in writing. Risk items should be raised as soon as they're identified — the same day if they affect the prime's deliverable timeline. Include the risk description, potential impact, and proposed mitigation options. Don't wait for the weekly status meeting to surface items that need immediate attention.
What makes federal IT subcontractor documentation fail government review?
The most common failures: wrong document format (doesn't match the CDRL DID), generic language that doesn't describe the specific system, architecture diagrams that don't match the deployed system, and missing evidence links for security control assertions.
How does infrastructure-as-code help with ATO documentation?
IaC modules document deployed system configurations by definition. A well-organized Terraform codebase with module structure descriptions, output documentation, and policy-as-code compliance checks provides a substantial portion of the configuration baseline documentation required for ATO. It also ensures documentation stays current as infrastructure changes — which manual documentation does not.