Engineering & program management services
- STi parent IDIQ
- N00178-19-D-8586
- Public STi award announcement
- January 1, 2019
- Core service categories
- Engineering services · Program-management services
SeaPort-NxG provides a Navy ordering path for engineering and program-management services. STi announced a prime award following the December 2018 award cycle. The specific task order establishes the work, delivery interfaces and acceptance requirements.
For an engineering requirement, scope definition should distinguish analysis, design or integration tasks from technical operations, test support and management activities. Deliverables, technical interfaces, schedule assumptions and quality evidence belong in the requirement discussion so the acquisition route and the intended outcome remain aligned.
Technical scope.
- Engineering support services
- Program-management support services
- Cross-discipline technical and business support aligned with the task requirement
Specify the engineering decision and its evidence.
An engineering service requirement should identify the question to be answered, the technical baseline to be examined and the evidence needed to support the resulting decision. Analysis, design review, test support, integration and technical operations can require different methods and deliverables even when they concern the same system.
The statement of work should make those differences visible. Identify interfaces, assumptions, source information, required reviews and acceptance criteria. A deliverable described only as a report may leave the technical decision undefined; a useful requirement explains what the report must establish and how its adequacy will be assessed.
Connect program controls with technical progress.
Program-management support is most useful when scope, schedule, resources and cost refer to the same authorized work. Technical completion criteria provide a more reliable basis for status than a percentage that cannot be traced to a work product or review outcome.
A change in requirements or configuration can invalidate an earlier estimate, test plan or analysis. The management process should carry that impact through the affected baseline, dependencies and decisions. Risk, existing issues and proposed changes should remain distinguishable so that each receives the right response.
Design clear handoffs across the team.
Engineering, technical services and program control share information but retain different responsibilities. Define ownership for source data, models, test results, configuration records and review actions. When multiple organizations contribute to a deliverable, integration and approval responsibilities need an explicit home.
Quality evidence should show the requirement addressed, the configuration or assumptions examined, findings and their disposition. Public vehicle information can help a contracting team begin the discussion; the actual task and contract requirements determine the delivery, reporting, ordering and acceptance arrangements.
FROM METHOD TO EVIDENCE
Work products with a purpose.
- Requirement-to-deliverable and acceptance-criteria mapping
- Engineering analysis and review records
- Integrated schedule, risk and change information
- Technical-interface and action-closure records
A CLOSER LOOK
Questions that shape the work.
How should a mixed engineering and program-support requirement be organized?
Separate the intended technical outcomes from the controls needed to manage them, then define their interfaces. Each work element needs an owner, an understood output and acceptance criteria. The acquisition team confirms the applicable scope and ordering arrangements.
Public vehicle information is presented at the IDIQ level. Individual task-order requirements and current ordering instructions govern the work.
Official vehicle reference ↗CONNECT THE REQUIREMENT TO THE RIGHT DISCIPLINE