Site problems Systems Engineering Relationship To Program Management The systems engineering process cannot be assigned to a single organizational element of a program office or contractor program organization (such as a systems engineering and/or integration team). Instead, the iterations and associated trade-offs, assessments, and decisions of the systems engineering process ultimately involve all of the relevant speciality engineers (including those who are called systems engineers) as well as the design engineers for all the products making up the system. Since the activities are pervasive, program management is ultimately responsible for the products of systems engineering, for managing risk, and for managing (controlling) the configuration of the products that make up the system. As a result, it can be useful to consider systems engineering as a cross-product process and the systems engineering organization as a cross-product staff function serving program management. For that reason, in some programs the program director or program manager may choose to retain the chair or leadership of activities such as the risk management or Configuration Management (CM) boards or the interface control working group (especially for external interfaces). No matter how the program is organized to manage risk and other matters, systems engineering is inextricably linked to program management. For example, in most programs, a key management tool is the product-oriented Work Breakdown Structure (WBS). The product oriented WBS starts with the physical hierarchy or product tree developed as described above as part of the iterative systems engineering process. Using the product tree shown as a point of departure (Figure A), a simple, partially populated, product-oriented WBS outline in Figure B. Figure A - Simple Satellite System Product-Tree (Physical Hierarchy) Figure B - Simple Satellite System Product-Oriented WBS