SAIW_Product_Realization_SOP.doc

Product Realization SOP, Rev. 9

DCN:

POC:

QMR

Original Approval Date:

11/5/2008

Approved by:

B. F. Dombrosky

Revision History

Date

Rev # Affected Section

Change(s)

A1.9 thru A1.13; throughout Updated Div. Director’s name; deleted ref. to ISO std.; added ‘Interested Party’ and added to Management definition; deleted old ref. (a); updated documentation examples; added ref. to all stakeholders; minor formatting changes.

CONTENTS

Section

1 Introduction

HYPERLINK \l "sec2_applicability" \o "Applicability"

Applicability

Roles and Responsibilities

References SAIW Product Realization Process

A1.

Initiate Project

A2.

Develop/Design Product

A3.

Acquire Materials

A4.

Integrate/Build Product

A5.

Perform Testing

A6.

Deliver Product

1 INTRODUCTION

This Standard Operating Procedure (SOP) has been developed in accordance with reference (a). The purpose of the SOP is to standardize the processes that the Ship & Air Integrated Warfare (SAIW) Division personnel will use to provide quality products and services to their end-user customers. By following this SOP, Division personnel will be informed regarding actions required of them and actions they can expect from others involved in the process.

This SOP remains in effect as long as it is maintained online on the SAIW Community of Interest (COI). Division forms associated with this SOP must be obtained from the COI each time they are used to ensure the latest version is being used. Blank forms should not be saved to personal computers or in a hardcopy file as their currency cannot be assured.

2 APPLICABILITY

This SOP applies to all SAIW Division projects unless otherwise specified by Division Management. Due to the varying size and nature of the projects supported by the Division, this SOP can be tailored or sections waived with documented approval from the Division Director.

3 ROLES AND RESPONSIBILITIES

Interested Party. Stakeholder or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity.

Customer. The individual or group requesting the SAIW Division perform a particular task.

Sponsor. The individual or group providing the SAIW Division with the approval and funding to perform a particular task for the customer.

Management. The individual who assigns the project lead and assists with resource allocation and acts as senior management on key project management decisions.

Project Lead. The individual selected by senior management to lead the project team. The project lead is responsible for the overall management of the project or product realization process and is the primary contact for the customer.

Project Team. The group of individuals, composed of Government personnel and contractors, selected to perform the work as outlined in this SOP.

4 REFERENCES

a) SAIW Division Quality Manual, DCN 033

5 SAIW PRODUCT REALIZATION PROCESS

The SAIW Product Realization process defines the Division’s approach to project management and product planning. It consists of six major phases: initiating the project, developing and designing the product, acquiring the necessary materials, integrating and/or building the product, testing the product, and delivering the product. Typically, the senior management of the Division will appoint a project lead, who is responsible for the planning, execution, and delivery of the product. Through the use of a “project team” or Integrated Product Team (IPT), the project is staffed, managed, and executed in accordance with the requirements of the customer or sponsor and the complexity of the product. Although the project lead has overall authority for the project plans, he or she may delegate portions of this authority to members of the project team to ensure flexibility, responsiveness, and timely decisions. The following sections provide the major details for the SAIW Product Realization Process.

A1. Initiate Project

Perform Project Planning: A1.1 thru A1.8 At the beginning of any potential project, the role of the project lead will be to create project planning documentation that will become the basis for determining the resource requirements (manpower, equipment, and space) to successfully complete the project according to customer needs, while integrating the quality requirements of the Division. In coordination with the customer, the project lead will develop the draft project planning documentation. This documentation usually outlines high-level project requirements, identifies the base number of deliverables, identifies the base number of informal and formal reviews, and identifies any special issues or concerns that need to be addressed. From the draft plan, the project lead will develop a cost estimate for management review. This review will refine the cost estimate, include the projected initial manpower and facility requirements, and form the basis for internal approval by senior management. After the management cost estimate is completed, the project lead will provide this to the customer. Depending on the customer’s available budgets and expectations, the scope of the project may be negotiated.

Refine Requirements: A1.9 thru A1.13 Depending on the complexity of the project, several technical milestones may be included in the project planning documentation. These milestones may include the creation of technical documentation to satisfy the production, testing, or support requirements of the project. Technical and administrative documentation may also be created for the exit or entrance criteria of the current or additional phases of the project. In accordance with the project planning documents, informal or formal reviews will be performed to validate the status and maturity of the project against the customer requirements. The project lead and project team will create a Statement of Work (SOW) or similar documentation for the project reflecting the requirements and integrating the applicable areas of the Division’s quality program to ensure the refined requirements for the intended delivered product meet the agreed-to specifications and expectations of the customer and all stakeholders.

Manage Tasking and Funding: A1.14 thru A1.17 The project lead will deliver the SOW to the customer along with the funding routing information required to begin the project. Once the funding document is received, it will be routed to the appropriate managers for endorsement and processing. Upon acceptance of the funding by the Division, a kick-off meeting may be held to discuss the requirements, schedule, and the roles and responsibilities of the project team.

A1 Output: Project planning documentation, cost estimate, SOW or similar document, meeting minutes, funding documentation A2. Develop/Design Product

Develop Preliminary Design: A2.1 thru A2.6 The project lead will coordinate with the appropriate personnel to develop preliminary engineering plans for the project. The plans will incorporate activities to be accomplished during the project duration. They will also include the technical method by which the product development will be accomplished and the resources required to develop/design the product. The preliminary engineering plans will establish the technical reviews to be conducted during the product development effort. The plans will create a list of technical artifacts that will be created for internal product development as well as technical documentation that will serve as product deliverables to the customer. The preliminary engineering plans will be approved by the project lead.

A Work Breakdown Structure (WBS) or documents containing information that defines the scope of the project will be developed.

The project lead will be responsible for determining the method by which the design activities will be conducted. These methods may include or adopt:

· Division SOPs

· Customer’s method of product development

· Military or commercial standards for technical development

· Support contractor’s process documentation The project lead will determine the technical resources required for product development. These resources may be physical in nature, such as personnel, equipment, and facility resources. Others may include intangible resources, including technical knowledge, personnel skills, personnel hours, and requisite external resources (e.g., certification and accreditation agencies, in-service engineering agents, and other design and development agencies). Upon identification of the necessary resources, the project lead will determine whether the resources are currently available. If they are not available, the project lead will determine how and when the resources may be acquired to complete the product.

The project lead will determine what technical reviews and checkpoints are required during product development. The reviews required and the schedule of the reviews may be dictated by the customer and/or documented in the SOW. These may include reviews for both internal and external stakeholders.

Technical artifacts will consist of a variety of project-specific documentation. Artifacts that will be delivered as part of the engineering documentation will be identified and entered into the project’s document control process. Project artifacts not delivered to the external stakeholders may be entered into document control process as determined by the project lead.

Upon initiation of the development phase of the project, the project lead will be responsible for the functional allocation of the system requirements. The project lead, while accountable for the allocation, will enlist other engineering resources, as appropriate. The functional allocation is captured in a functional block diagram or similar documentation, which will serve as a high-level view of the system’s generic interfaces and components. This diagram can be used to trace detailed design parameters back to the project’s requirements. The diagram may be delivered as part of the technical artifacts. If the project inception is after the customer has performed functional allocation, the applicable functions or physical solution will be stated and incorporated into the design. The project lead will be responsible for ensuring functional requirements are not invalidated through the engineering development process.

The purpose of the functional allocation activity is to ensure there is a logical transition of customer requirements to material solution. Functional allocation can be performed by the engineering team or by the customer. If functional allocation is to be developed by the engineering team, the project lead will be responsible for capturing the system’s functions in technical documentation, such as functional requirements or functional block diagrams. If upon project inception the customer has already performed functional allocation, the project lead will request the appropriate data needed for system development from the customer. This data may be in the form of a decomposed set of requirements, a material product to integrate, or a set of Interface Control Drawings (ICDs).

With the conclusion of the functional allocation, the engineering team may conduct market research to determine whether a preexisting product will satisfy the system requirements. The selection of an existing product is the most desired outcome for system integration as this may minimize developmental risk to the project and in most cases be more affordable.

In order to conduct market research, requirements for the product must be defined. These requirements should trace back to the system-level requirements but may be composed of derived requirements. Upon definition of requirements, the project team will determine which requirements can be allocated to preexisting products. The engineering team may then create a set of quantifiable items, such as cost, size, weight and power, critical system interface type, interface quantity, reliability, etc needed to satisfy each requirement.

The project team may conduct research to determine the type of products currently in the market. The engineering team will assess the product against the set of predefined attributes. If the product does not meet the attributes, the deficiency should be noted. The project team continues to repeat the process until there is at least one product that meets all of the attributes. If there is more than one product that is identified, the engineer may choose to add weighting criteria to the products. These weighting criteria serve as a priority-based approach to selecting a product that excels in the most important system attributes. Upon weighting, the best candidate product will be recommended for implementation into the design.

If during the market research no candidate product meets the system attributes, the project lead will determine the best approach to meeting the system requirements. This may be in the form of modifying a preexisting product, developing a new product, or changing the requirements (with concurrence of the customer) to match what is currently available.

In some cases market research may be omitted if the customer specifies a certain product. In this instance, market research is not needed since the customer has determined that the product meets the system requirements. However, as part of the functional allocation process, the engineering team will ensure the product supports system requirements.

During engineering design, technical documentation or prototypes may be developed to support the project and customer needs. Additionally, technical documentation may be generated to support a variety of activities in the project, such as production, training, procurement, and logistics. Technical documentation for a project may include system and subsystem requirements, cable block diagrams, mechanical mounting drawings, mechanical fabrication drawings, cable run sheets, and cable installation diagrams.

Generation of this documentation may include a variety of subactivities specific to the type of documentation, such as mechanical design, electrical design, interface definition, and product research. Many of the subactivities may be need to be compiled into a single document. Upon completion of this documentation, it will be entered into the project’s document control process.

If changes occur in the design, documentation will be generated to implement the change. The change documentation will textually or graphically depict the necessary modifications. The change documentation will be reviewed and approved according to the project’s document control process.

Material will be generated and/or gathered to assist in determining if the design is ready to move forward. The project lead will identify what material will be required during the related review. Examples of material for the assessment may include, but are not limited to, the following:

· Cable block diagrams

· Mechanical layouts

· System architecture drawings Develop Detailed Design: A2.7 thru A2.11 The technical review will address the current status of the system design. It will be used to convey the progress of the design to all of the project’s stakeholders.

The technical review will be attended by members of the engineering team and the project stakeholders as appropriate. The project lead will conduct the technical review. Minutes and action items may be recorded and distributed to the stakeholders at the conclusion of the technical review.

Since the technical review serves as an assessment of the progress of the design, attendees will provide feedback as appropriate on the system design. The engineering team will evaluate and respond to all questions from the stakeholders. After all questions have been addressed to the satisfaction of the stakeholders, the project can proceed. The decision will be documented as determined by the project lead.

The engineering team will begin to identify hardware for use within the system. Hardware or components will be assigned to handle specific functions to meet the system requirements. The component may be specified by the sponsor. However, the engineering team may also perform an analysis to determine component specifications are needed to satisfy the system’s requirements. In some cases, a trade analysis may be developed to aid in component selection if more than one component meets the specifications. Upon selection of system components, the part numbers and quantity will be specified as part of a system equipment list . This activity will continue until all system requirements are satisfied by one or multiple components.

As the design process matures or becomes more detailed, the likelihood of changes increases. If changes occur in the design, documentation will be generated to implement the change. The change documentation will textually or graphically depict the modifications. The change documentation will be reviewed and approved according to the Project’s document control process.

Engineering analysis will include activities required to transition a preliminary system design into a design that is suitable for production. The project lead will be responsible for systematically maturing the system design. The project lead will identify the tasks required for system development. Examples of these tasks are:

· Detailed cable block diagrams

· Cable run sheets

· Mechanical fabrication drawings As necessary for the project, this phase will also capture technical analyses required to generate a design to both meet the system requirements and support production of the system. Identifying and documenting the analyses required will be performed by the project lead. The analyses may be disseminated to the project stakeholders, as needed. The project lead will assess the level of detail for the analyses as required by the project and capture the artifacts in the design documentation.

As the design process matures, so does the likelihood of additional technical reviews. Material may be generated and/or gathered to assess the readiness of the design to move forward. The project lead will identify what material will be required during the related review. Examples of material for the assessment may include, but are not limited to, the following:

· Cable block diagrams

· Mechanical layouts

· System architecture drawings Develop and Update Technical Documentation: A2.12 thru A2.16 The technical review will address the current status of the system design. It will be used to convey the progress of the design to the project’s stakeholders.

The technical review will be attended by members of the engineering team and the project stakeholders, as appropriate. The project lead will conduct the technical review. Minutes and action items may be recorded and distributed to the stakeholders at the conclusion of the technical review.

Since the technical review serves as an assessment of the progress of the design, attendees may provide feedback on the system design. The engineering team will evaluate and respond to questions from the stakeholders. After all questions have been addressed to the satisfaction of the stakeholders, the project will proceed. This decision will be documented in the appropriate manner by the project lead.

The documentation developed in support of the engineering plan will be updated and prepared for production activities to begin. Finalizing the documentation may involve creating a baseline . Various resources may be used as guidance to finalize documents. Some examples are:

· MIL-STD-31000A, Technical Data Packages

· ASME Y14.1, Decimal Inch Drawing, Sheet Size and Format

· ASME Y14.100, Engineering Drawing Practices

· ASME Y14.24, Types and Applications of Engineering Drawings

· ASME Y14.34, Associated Lists

· ASME Y14.35, Revision of Engineering Drawings and Associated Documents

· ANSI EIA 649, National Consensus Standard for Configuration Management

Some examples of typical production-level documents are:

· Fabrication/assembly drawings

· Arrangement drawings

· Elevation drawings

· Schematic drawings

· Printed wiring board drawings

· Circuit card assembly drawings

· Cable block diagrams

· Cable run sheets

· Support system (power, HVAC, space & weight, etc.) interface drawings

· Production test plans/procedures

· Procurement specifications

· Listings of qualified suppliers

· Material issue/control process document

· Requirements traceability matrix

· Work instructions

Material may be generated and/or gathered to assess the readiness of the design to move forward. Examples of some of the review materials that may be generated and/or gathered are listed below:

· Requirements traceability study

· Design maturity analysis

· Configuration management analysis

· Facilities study

· Personnel resources/roles and responsibilities analysis

· Service contracts

· Specialized tools analysis

· Specialized skills/manufacturing process analysis

· Quality management plan

· Reporting methods

· Design/production risk analysis

· System baseline established Success criteria for this assessment may include affirmative answers to the following exit questions:

· Has the system product baseline been established and documented to enable production to proceed with proper configuration management?

· Are the risks manageable?

· Is the schedule executable (technical/cost risks)?

· Is the effort properly staffed?

· Is the detailed design producible within production budget?

The project lead will provide the customer with the status and/or progress of the project as required. Any adjustments to the project schedule, cost, or performance will be negotiated with the customer, and any required decisions and/or changes will be documented.

A2 Output: Requirements, systems engineering plan, technical documentation, preliminary design review, critical design review, and engineering change documentation A3. Acquire Materials

Perform Procurement Planning and Execution: A3.1 thru A3.2 The Division has four basic paths for obtaining material. The path taken will be determined by the project lead based upon urgency, quantity, and/or availability:

1. Obtaining the Material through the Navy Supply System. When this path is used, the project lead will work with the contract support personnel using their process to develop the requisite package. During the execution of the procurement, the project lead will be provided status updates.

2. Obtaining Material with a Government Purchase Card. When this path is used, the project lead will work with the project team and the contract support personnel using their process to develop the requisite package. The government purchase card holder will execute the procurement with the assistance of the contract support personnel.

3. Obtaining the Material through the Contract Support Team. When this path is used, the project lead will work with the contract support personnel using their process to develop the requisite package. During the execution of the procurement, the project lead will be provided status updates.

4. Obtaining the Material through the Government Contract Office. When this path is used, the project lead will work with the Government Contract Office representative and the contract support personnel using the Government Contract Office process to develop the requisite package. The Government Contract Office will execute the procurement. The contract support personnel will provide support and report the status of the procurement to the project lead.

The one exception to the four methods listed above is material associated with communications security (COMSEC). COMSEC material for a new project must be validated in writing by the Chief of Naval Operations (CNO) prior to procurement. Once validated by the CNO, COMSEC must be procured through the Electronic Key Management System (EKMS) Manager using the assigned account number for proper accounting. SAIW COMSEC Custodians designated by the Division Director are the liaison between the Webster Field Electronic Key Management System Manager and SAIW, and they will handle and assist with all SAIW COMSEC material procurements.

Prior to acquisition of Information Technology (IT) material, the project must follow the applicable NAVAIR process.

Perform Material Acceptance: A3.3 When material is received for a project (from vendors or customers) there are two paths that fulfill material acceptance.

The first path is part of the receipt process that includes physical inspection for damages, accuracy of the received item(s) to the order, and, if applicable, a standalone performance test of the product. If the receipt process is satisfactory, the item(s) are turned over to the project team and the applicable project documentation is completed for acceptance. Project documentation typically includes scheduled reports to the customer to provide updates of material changes that may have occurred. The received items are incorporated into the system build.

The second path pertains to COMSEC material only. All COMSEC material will be received through the Webster Field EKMS Manager, handled by appropriately cleared and authorized COMSEC users, and stored in a secured container/shelter or vault. All COMSEC material will have its own accounting by the Local Element Communications Security Custodian Guidance for Communications Security. Material handling is outlined in the EKMS1A document.

Should the material fail to meet receipt inspection or be damaged during use, the material or equipment will be processed with a Discrepant Material Report (DMR) and reported to the customer through appropriate channels.

Manage Customer Property: A3.5 The method by which the Division manages customer property is similar to that noted in A3.3. In most cases, the project lead will identify customer-supplied products or equipment on project material or equipment lists. Records of the receipt inspection will be provided to the project lead for the purpose of providing feedback to the customer. Where supplied material or equipment arrives prior to use within the project, the material or equipment will be stored appropriately for the type, size, and condition of the material or equipment. Customer property will be segregated by project and reflect current status.

Perform Preservation of Product: A3.6 Material, once received, will be handled and stored in an appropriate manner and in accordance with supplier’s recommendations if available. If not available, DOD standards, such as MIL-STD-2073-1E will be used as guidance.

A3 Output: DMR and inspection results documentation A4. Integrate/Build Product

Integration is performed to transform the design solution definition into the desired end product through assembly and integration of lower level and validated end products in a form that satisfies the design requirements (e.g., drawings, specifications). General inputs for this phase may include technical documentation, such as drawings, the finalized design of the system, master equipment lists, and test plan/procedures.

Perform Production/Development and Integration: A4.1 thru A4.3 The project lead is responsible for tracking and reporting cost, schedule, and performance status of the project to the extent required by the project or customer.

The project team will gather the components, technical documentation, hardware, and software necessary for product assembly/code development. Assembly/code development will be performed in accordance with provided technical documentation.

All parts, whether they were fabricated or procured, will be inspected during this phase to ensure they conform to product requirements. Any parts assembled into subassemblies or already installed as subassemblies will be inspected for conformance to product requirements. The project lead and project team will use the technical documentation to install and/or integrate the product. Problems identified during the integration phase will be noted for analysis and resolution.

When a product cannot be directly inspected, the project lead has the responsibility to control resources, processes, and the end product.

Documentation pertaining to the system build and configuration will be updated as necessary during integration. This may include the requirements traceability matrix, configuration management plan, risk management plan, WBS, Master Equipment List (MEL), Master Parts List (MPL), work instructions, Master Metal List (MML), engineering drawings, and in-process/progress review reports.

Finalize Technical Documentation: A4.4 thru A4.6 The engineering team will review and approve/disapprove any design changes identified during the integration and build phase. The engineering documentation will be updated to reflect design changes based on the approval of the engineering team. Updating the documentation may involve updating the baseline.

Various resources may be used as guidance to finalize documents. Some examples are:

· MIL-STD-31000A, Technical Data Packages

· ASME Y14.1, Decimal Inch Drawing, Sheet Size and Format

· ASME Y14.100, Engineering Drawing Practices

· ASME Y14.24, Types and Applications of Engineering Drawings

· ASME Y14.34, Associated Lists

· ASME Y14.35, Revision of Engineering Drawings and Associated Documents

· ANSI EIA 649, National Consensus Standard for Configuration Management The engineering team may identify a need to develop or update technical manuals as a result of or in response to, but not limited to, lessons learned during production. Technical manuals may also need to be updated through validation that occurred during production or through the late introduction of new requirements.

The identified changes to a technical manual or the development of additional technical manuals may be accomplished through the use of a documentation control process.

The project lead will provide the customer with the status and/or progress of the project, as appropriate. Adjustments to the project schedule, cost, or performance will be negotiated with the customer and required decisions and/or changes will be documented.

A4 Output: Inspection artifacts, updated engineering documentation, technical data package, MEL, MPL, MML, and receipt documentation A5. Perform Testing

Perform Pre-test Activities: A5.1 thru A5.3 Prior to testing activities, the project team generates appropriate test plans and/or procedures. The plans and/or procedures define the testing to be performed, test steps, testing resources, test schedule, coordination of resources (for test frequencies, shipping test assets, acquiring test equipment, etc.), and test data to be collected. The test plans and/or procedures are reviewed by the engineering team for correctness and completeness prior to testing. They may require external review by certification agencies, accreditation groups, or stakeholders. The project lead will ensure these external reviews are coordinated and conducted as required.

Documentation will be generated and/or gathered to determine if the project is ready for the testing phase. Example material for the assessment may include, but is not limited to, test procedures status, testing schedule, requirements traceability matrix, test matrix, and identified test-related risks.

The technical review will address the current status of the test plan. It will be used to convey the progress of the test plan to the project’s stakeholders. The project lead will conduct the technical review, which will be attended by members of the engineering team and the project stakeholders as appropriate. Minutes and action items may be recorded and distributed to the stakeholders at the conclusion of the technical review.

Since the technical review shows the progress of the test plan, attendees may provide feedback on the plan. The engineering team will evaluate and respond to questions from the stakeholders. After all questions have been addressed to the satisfaction of the stakeholders, the project will proceed. The decision will be documented in the appropriate manner by the project lead.

Perform Product Testing: A5.4 thru A5.5 Product testing occurs after all pre-test activities have been successfully performed. Product testing is performed to ensure the product meets the operational requirements and design specifications. The testing occurs in accordance with the test plans and procedures that were developed during the pre-test activities and all results are captured by the test team. Testing may occur on a piece of hardware, software, subsystem, or a system. The types of hardware testing that are performed may include, but are not limited to, environmental testing (shock testing, vibration testing, humidity testing, etc.), functional testing, developmental testing (DT), integration testing, acceptance testing, system testing, operational testing (OT), and user acceptance testing. The types of software testing that are performed may include, but are not limited to, unit testing, compatibility testing, and regression testing.

After the test event is completed and results are recorded, the results are analyzed and any deficiencies are noted by the test team in the Test Report. The deficiencies may be prioritized based upon the severity of the deficiency and its impact on the product to meet the defined requirements and design specifications.

Document Test Results: A5.6 thru A5.9 Design changes identified during the testing phase are analyzed by the engineering team and are then reviewed for approval/disapproval by the project lead and/or customer depending on impact of the change to the project. The engineering documentation will be updated to reflect design changes based on the approval. Updating the documentation may involve updating the baseline.

Various resources may be used as guidance to finalize documents. Some examples are:

· MIL-STD-31000A, Technical Data Packages

· ASME Y14.1, Decimal Inch Drawing, Sheet Size and Format

· ASME Y14.100, Engineering Drawing Practices

· ASME Y14.24, Types and Applications of Engineering Drawings

· ASME Y14.34, Associated Lists

· ASME Y14.35, Revision of Engineering Drawings and Associated Documents

· ANSI EIA 649, National Consensus Standard for Configuration Management

A test report may be generated for each test event. The test report identifies the product tested and generally includes test conditions, test equipment used, test procedures used, assumptions, deviations or anomalies noted during testing, test results, and an analysis of those results. Test reports may be submitted to the customer as a deliverable if required by the project.

The project lead will review the test report. Questions or discrepancies found will be addressed by the project lead and/or engineering team. Due to the type of information contained within these reports, the data collected may be used to measure and document the successful development of the hardware or software/system (product) against various customer requirements (design parameters). A summary of this information may be provided to senior management for trend analysis or assessment.

The project lead will provide the customer with a status and/or progress of the project as required. Any adjustments to the project schedule, cost, or performance will be negotiated with the customer, and any required decisions and/or changes will be documented.

A5 Output: Test documentation, test reports A6. Deliver Product

Deliver Product: A6.1 thru A6.2 The project lead will coordinate with the necessary persons to develop the appropriate documents, instructions, or guidance to ensure the product is prepared, protected, shipped, and received by the customer in accordance with the original SOW or comparable documentation. The project lead and the contractor support personnel will use this documentation to ensure the product is delivered in compliance with the customer expectations. The project lead will authorize the final transfer to the customer.

Perform Project Closeout: A6.3thru A6.6 To close out the project, the project lead and the appropriate members of the team will review deliverables and financial reports to ensure all defined products and services were delivered or provided to the customer.

The project lead will coordinate with the necessary persons to ensure the product meets the requirements and is appropriately transferred to and received by the designated activity. The project lead will obtain the receiver’s signature on the required documentation. The project lead will review the signed transfer to ensure custodial requirements have been met.

Once the project lead has determined that all products, services, and financial obligations have been completed, a final report will be delivered to the customer.

The project lead will request feedback from the customer on the performance of the work and quality of the product or service in accordance with the Customer Feedback SOP.

A6 Output: The final product or service that is delivered, delivery acceptance documentation Product Realization

Rev. 9

SAIW

STANDARD

OPERATING PROCECURE

SAIW Product Realization Process

Initiate

Project

A1

Develop / Design Product

A2

Acquire Materials

A3

Integrate / Build Product

A4

Perform Testing

A5

Deliver Product

A6

Start

Stop

A1 Initiate Project

Identify

Need for Systems Engineering

Services

A1.1

Identify Potential Deliverables

A1.2

Provide Level & Number of Reviews

A1.3

Generate

Cost Estimate & Schedule

A1.4

Review Cost Estimate & Schedule (Division)

A1.5

Initiate Travel Orders (TO)/ Visitor Requests (VR)

A1.6

Establish High-Level Requirements

A1.9

Prepare Detailed Specs./Reqs.

A1.10

Perform

Technical Review of Requirements (SME/Peer)

A1.11

Perform Admin./�Mgmt. Review of Requirements (Stakeholder)

A1.12

Generate SOW

A1.13

Request Funding Doc.

A1.14

Receive Funding Doc.

A1.15

Forward Funding Doc. for Processing

A1.16

Kickoff Project

A1.17

Provide Cost Estimate to Customer

A1.7

Conduct Negotiation

A1.8

A2 Develop/Design Product

Develop Preliminary Plans (I)

A2.1

Perform Functional Allocation

A2.2

Perform Market Research

A2.3

Generate

Product Specs/ Develop Deliverables

A2.4

Develop Engineering Change Orders (1st) (Design Team)

A2.5

Gen./Review

Material for 1st Tech. Review

A2.6

Conduct 1st Tech. Review

A2.7

Allocate Hardware/Materials

A2.8

Develop Engineering Change Orders (2nd) (Design Team)

A2.9

Conduct Engineering Analysis

A2.10

Gen/Review

Material for 2nd Tech Review

A2.11

Conduct 2nd Tech. Review

A2.12

Finalize Documentation

A2.13

Gen./Review

Material for 3rd Tech. Review

A2.14

Conduct 3rd Tech. Review

A2.15

Coordinate Schedule w/ Customer (1st)

A2.16

A3 Acquire Material

Perform Procurement Planning

A3.1

Perform Procurement Execution

A3.2

Perform Material Acceptance

A3.3

Schedule Updates

A3.4

Manage GFE / Customer Property

A3.5

Perform Preservation of Product

A3.6

A4 Integrate / Build Product

Execute Cost & Schedule Controls

A4.1

Develop Code/ Assemble Product

A4.2

Integrate/ Install Product

A4.3

Update (1st) Engineering Documentation

A4.4

Develop/ Update Tech Manuals

A4.5

Coordinate Schedule w/ Customer (3rd)

A4.6

A5 Perform Testing

Perform Pre-Test Activities

A5.1

Gen/Review Material to Assess Readiness for Testing

A5.2

Conduct Technical Review

A5.3

Perform Product Testing

A5.4

Verify Test Results

A5.5

Update (2nd) Engineering Documentation

A5.6

Generate Test Report

A5.7

Review Test Report

A5.8

Coordinate Schedule w/ Customer (4th)

A5.9

A6 Deliver Product

Conduct Check-off

A6.1

Deliver System/ Product

A6.2

Perform Document Mgmt.

A6.3

Close Out Documentation

A6.4

Obtain �User Acceptance

A6.5

Close Out Project

A6.6

� The format and contents of the Preliminary Engineering Plan will be determined by the Project Lead to suit the required project.

� Technical Artifacts are items which contain technical data associated with the project design effort and may be needed for product or technical documentation development.

� Technical Documentation is the formatted, controlled documents that contain product-related data or technical information for project traceability.

� Technical Reviews are the method used to review requirements, design, drawings, source code, or other artifacts to discover defects, determine product maturity or gain acceptance by the project group. These reviews may take the form of formal or less formal working processes.

� System equipment lists may take the form of Schedule A lists, builds of materials, master parts lists, master metal lists, or master equipment lists.

� As the Technical Documentation reaches a predefined milestone in its development, a decision occurs in the level of formality that is appropriate for managing changes to the deliverable or the impact on the deliverables of other team members.

The master version of this document is controlled within the defined Division repository. All other copies, including electronic copies, are uncontrolled and will be used for reference only.

ii The master version of this document is controlled within the defined Division repository. All other copies, including electronic copies, are uncontrolled and will be used for reference only.