LE FastCounter
General.
Include here a statement about what this SOW covers.
If applicable, provide some background information that will be
helpful to clarify the needs of the procurement.
1.1 Background Do not
discuss any work tasks in section 1
List here all documents invoked in the requirements
section of the SOW by document identifier and title. These documents
may include Standards, Specifications and other referenced documents
needed to identify and clarify the work task or deliverable product.
Any document listed in the section must be invoked and tailored
to meet the minimal needs of the planned procurement in the requirements
section.
The following provides an engineering example:
This statement of Work (SOW) defines the effort required for the design, engineering development, fabrication, and test of a prototype of the project name System for the Demonstration and Validation Phase. It includes the associated program management, human engineering, and logistic support planning requirements.
The arrangement of technical tasks and subtasks within
the requirements section will be dictated by program (project)
requirements. If a Work Breakdown Structure (WBS) is being used
in the project, tasks must be organized in accordance with the
WBS. Ensure that only minimal needs are tasked for the SOW or
requirements.
The order of technical tasks and subtasks within
this section will be determined by the program requirements. If
a WBS is being used in the program, tasks should be arranged in
accordance with that WBS.
Ensure that the scope of the program tasks meet only the minimal
needs for the phase SOW or requirements.
The developer shall design and develop a system that shall meet the requirements of the Performance Specification, in accordance with (IAW) the system engineering tasks described in section 3.1. and program management and control tasks described in section 3.3.
The configuration and status of the design and contract shall be presented to the acquirer in two ways:
The developer shall implement a systems engineering management process in accordance with a 'Systems Engineering Management Plan' (SEMP) prepared to the instructions as described in MIL-STD-499B or an identified equivalent. The SEMP will define the necessary tasks and activities to be performed and shall include requirements analysis, functional analysis and allocation, and synthesis for the design of the system. The developer's system engineering process shall transform the requirements stipulated in the performance specification into a life cycle balanced set of products and process descriptions addressing the systems design, development, fabrication, test and evaluation, operational deployment, logistical support, personnel training, and final disposal. Where practical, system end-item requirements shall be met through the use of non-development items, when such products meet project needs, meet mission operational and environmental requirements, and are cost effective over the entire cycle of the project. The developer shall generate and maintain a requirements verification and decision matrix to provide an audit trail from requirements of the System Performance Specification to design implementation and verification, including key decisions to meet the requirements.
The developer shall identify and conduct trade studies,
trade-off analyses, and cost-effectiveness analyses to ensure
that a thorough and comprehensive set of options and alternatives
is considered and analyzed for design, with consideration for
all aspects of the system life cycle and all aspects of system
life cycle cost. The level of detail of each study or analysis
shall be commensurate with the cost, schedule, performance, and
risk impacts.
The developer shall generate the system functional baseline(s) and each allocated and product baseline for the configuration items. The developer shall identify commercial-off-the-shelf (COTS) and non-developmental items (NDI), critical or long-lead items, and any acquirer provided items that are proposed as part of the design baselines.
Software development shall be an integrated part of the system engineering effort. The developer shall conduct software development IAW MIL-STD-498.
All software shall be managed IAW a 'Software Development
Plan' prepared IAW the product description (DID).
The developer shall develop, update, and maintain
a concept of operations for the system that describes how the
system would be operated. The developer shall identify effects
of the concept of operations on the performance of the system,
and the cadre who will operate the system.
The developer shall establish and document an ILS program as an integral part of its system engineering efforts. The ILS program shall address the developers proposed approach for providing total life cycle support from initial prototype design through final system disposal. The ILS program shall include the following elements:
A CALS strategy shall be employed to enable the effective generation, exchange, management, and integration of digital technical information.
The developer shall establish and maintain a system safety and environmental protection program and shall ensure that safety and environmental protection considerations are integral parts of the systems engineering efforts. The safety program shall address personnel and equipment concerns relative to the design, development, testing, use, maintenance, life cycle support and disposal of the system.
The developer shall conduct design reviews, as defined in MIL-STD-1521B suitably modified to incorporate the requirements and products of MIL-STD-498, MIL-STD-499B, DEF STAN 05-57, etc. The developer shall commend specific streamlining of these design reviews to the acquirer.
See semp39.htm for more details
The purpose of the SRR is to ensure that the system
requirements have been completely and properly identified, to
ensure that there is a mutual understanding between the developer
and the acquirer regarding these requirements, and to review the
system engineering process defined in the 'Systems Engineering
Management Plan' that the developer shall use to develop the functional,
allocated, and product baselines. At the SRR, the developer shall
also describe how its technical concept is expected to meet these
requirements, and shall identify the risks involved and how they
will be managed.
The purpose of the SDR
3.2.8.3 System design review.
3.2.8.4 Software specification review.
3.2.8.5 Preliminary design review.
3.2.8.6 Critical design review.
3.2.8.7 Test readiness review.
3.2.8.8 Functional configuration audit
3.2.8.8 Physical configuration audit
3.2.8.9 Formal qualification review
3.2.8.10 Production readiness review
The developer shall establish and maintain management operations IAW the following paragraphs. The use of Integrated Product and Process Development (IPPD) management approaches and the use of Integrated Product and Process Teams (IPPTs) is highly recommended.
The contractor shall establish and maintain a 'Project
Management System' that shall include the following areas:
Program planning and control;
Supplier control;
Configuration Management
Financial management;
Data management;
Risk management;
And other management area(s).
3.3.1 3 monthly meetings.
The developer shall conduct 3 monthly meetings with the acquirer. These meetings shall be approximately to 5 working days after the acquirer recieves the developers update to the Program Electronic Database described in section 3.2.
The meeting will provide the developer and acquirer
an oppertunity to discuss any questions or issues identified in
the electronic database or any recent changes to the program or
configuration. These should be held using video conferencing as
often as possible.
3.3.2 Risk Assessment, mitigation, and management program.
The developer shall establish and implement a risk
management program that identifies, evaluates, and mitigates program
risks from a technical, cost, and schedule perspective
3.3.3 Life cycle cost (LCC) analysis, and control.
The developer shall establish and maintain current
a system life cycle cost estimate. A baseline LCC estimate shall
be developed by the developer in conjunction with the system's
functional baseline at SDR.
Schedule development and control.
The developer shall establish and maintain current
a Program Master Schedule and a detailed schedule for development
of the system up to the establishment of the production baseline.
Performance management baseline management.
The developer shall implement cost/schedule control
procedures IAW the cost/schedule status report.
3.4 Program electronic database.
The developer shall establish and maintain current
electronic database that will document all aspects of the program,
including the system design, the developers system engineering
efforts, and the developers program management effort. The developer
shall maintain this electronic database in an accurate and timely
fashion, updating it with all pertinent changes on at least a
monthly basis, preferably more frequently when warranted by significant
changes and additions. Ideally, the electronic database would
be accessible by the acquirer in real-time. The purpose of this
database is to facilitate and streamline the transfer of information
between the developer and acquirer, and is intended to replace
extensive generation and delivery of costly and time consuming
reports and other paper products for the acquirer. It is the acquirer
intent that the databases used to satisfy this statement of work
requirement be the same databases that are used by the developer
as part of his normal internal, corporate way of doing business.
For example, if the developer provides its engineers with particular
computer-aided design tools to generate and document the system
design (specifications, drawings, etc.), then it is the acquirers
desire that the acquirer be given access to the same tool(s) to
review and assess the design, as opposed to having the developer
generate additional documentation or additional electronic tools
to accomplish the same purpose.
TB Continued.
The contractor shall develop and implement a 'Project
Management System' that clearly defines how the XYZ system
is to be managed and controlled.
Add the relevant programs here.
NOTES: Tasks required depend on the phase, for example, the Engineering and Manufacturing phase will require the development of contract specifications, finalization of system specifications, implementation of Configuration Management and project (program plans), and the performance of cost, schedule, & performance trade-offs.
Specify explicit needs, leave nothing to the imagination.
For example SOW terminology
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification
of errors using the following form to: kenr@wysywig.airtime.co.uk