1. Systems Engineering Management
CSUN - Prof. David Shternberg
Systems Engineering Management
MSE607B- Systems Engineering
MSE607B Chapter 6 Part I of II System Engineering Program Planning
Engineering Design Methods and Tools
The purpose of this chapter is to briefly highlight some of the recent concepts in design and to discuss system engineering objectives as they relate to current design methods.

2. CSUN - Prof. David Shternberg
Learning Objectives
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Introduce system engineering program planning
First step in system management
Material presented in this module leads into the discussion of:
The organization for system engineering in module 7
System engineering program evaluation in module 8
Learning Objectives
The objectives of this module are:
Introduce system engineering program planning – the first step in system management.
The material presented in this module leads into the discussion of the organization for system engineering in module 7, and system engineering program evaluation in module 8.

3. System Engineering Process
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Process
An iterative problem solving process based on the fundamental cycle of analyse-synthesise-evaluate
Provides a comprehensive process for transforming a simple statement of user need into a complex fielded system
Provides the information by which the process can be managed and improved
System Engineering Process
The Systems Engineering Process is an iterative problem solving process based on the fundamental cycle of analyse-synthesise-evaluate
The Systems Engineering Process provides a comprehensive process for transforming a simple statement of user need into a complex fielded system
In addition, the Systems Engineering Process provides the information by which the process can be managed and improved.

4. Management of System Engineering
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Management of System Engineering
System engineering is applicable in all phases of life cycle
Greatest benefits are derived from emphasis in early stages
Management of System Engineering
This figure illustrates how system engineering is applicable in all phases of the system life cycle. One line demonstrates the influence of system engineering on the system design, and the other the influence of the individual design disciplines (i.e. mechanical, electrical, and other engineering functions).
We can observe that the graph representing the level of influence of system engineering on the design is the highest at the early stages of system design and development. As the level of system engineering contribution decreases, the level of contribution of the individual design disciplines increases.

5. Management of System Engineering
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Management of System Engineering
Objective is to influence the design in the early phases of acquisition, effectively and efficiently
Leads to the identification of the individual design disciplinary needs proceeding from system level to subsystem levels
Goal is to ensure that requirements are properly balanced and integrated
Applicable engineering disciplines responsible for the design of the individual system elements to be properly integrated
System engineering first establishes the requirements then ensure proper integration throughout the life cycle
System engineering is applicable in all phases of life cycle
Greatest benefits are derived from emphasis in early stages
Management of System Engineering
Objective is to influence the design in the early phases of acquisition, effectively and efficiently.
It leads to the identification of the individual design disciplinary needs proceeding from system level to subsystem levels
Goal is to ensure that requirements are properly balanced and integrated
Applicable engineering disciplines responsible for the design of the individual system elements to be properly integrated
System engineering first establishes the requirements, then ensures proper integration throughout the life cycle
As indicated by the figure shown in the previous slide, system engineering has the most impact and benefits of the design if addressed during the early phase of the design and development activity.

6. Integration of Disciplines
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Integration of Disciplines
Integration of Disciplines
This figure illustrates the contribution of the various engineering disciplines in order to meet the system engineering requirements.
It is the role of system engineering personnel and program manager to ensure that the activities of the listed disciplines are properly scheduled and coordinated to satisfy all aspects of the system requirements.
Note that the timing and duration of each activity may vary during the design and development phases and during the life cycle of the system. For example, functionality and performance requirements are being addressed earlier than disposability requirements.

7. Management and Technology Applied to the System Engineering Process
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Management and Technology Applied to the System Engineering Process
Management and Technology Applied to the System Engineering Process
As shown in this figure, there are technology-related activities and there are planning and organization activities that must jointly be applied throughout the top-down life cycle process that has been discussed in the previous modules.
Although it is essential that one completely understand the “technical” process and available tools, this by itself will not guaranteed success unless the proper organizational “environment” is created where the applicable management skills can be effectively applied in fulfilling the stated goals.

8. System Engineering Program Requirements
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Program Requirements
First step in the planning process
Involves definition of program, or project, requirements
Every program is different
It is essential that system engineering requirements be tailored accordingly
Concepts and methods described throughout this module are applicable to all programs
Only the nature and depth of application may vary
System Engineering Program Requirements
As shown in the previous figure, the first step in the planning process involves the definition of program, or project, requirements.
Although this may appear rather basic, every program is different and it is essential that system engineering requirements be tailored accordingly.
The concepts and methods described throughout this module are applicable to all programs. Only the nature and depth of application may vary from one program to the next.

9. System Engineering Planning
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Planning
System Engineering Planning
This figure describes the system engineering planning process. Planning is initiated with the definition of program requirements and the subsequent development of a Program Management Plan (PMP). This, in turn, leads to the identification of system engineering requirements and the preparation of a detailed System Engineering Management Plan (SEMP).
The System Engineering Management Plan is developed during the conceptual design and advanced planning phase. As shown in this figure, the first step in the planning process involves the definition of program requirements.

10. The Need for Early System Planning
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
The Need for Early System Planning
System engineering is continuous
Commencing with the definition of a need and extending
Through the development of the System Engineering Management Plan (SEMP)
As system-level requirements are defined, the planning process leads to the identification of activities to be accomplished to fulfill those requirements
Design and management decisions at this stage in the system life cycle have great impact on program activities later on
Need a complete and well-integrated planning effort
Implemented from the beginning
The Need for Early System Planning
System engineering is continuous, commencing with the definition of a need and extending through the development of the System Engineering Management Plan.
As system-level requirements are defined, the planning process leads to the identification of those activities that must be accomplished in order to provide a system configuration that will fulfill those requirements.
Design and management decisions at this stage in the system life cycle have a great impact on program activities later on. Thus, it is imperative that a complete and well-integrated planning effort be implemented from the beginning.

11. Determination of Program Requirements
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Determination of Program Requirements
Program Requirements
Refer to the management approach and steps to be followed in the procurement and/or acquisition of the system in response to a stated need
Identification of the resources required
Program structure should be established that will enable cost effective:
Design and development
Production and/or construction
Delivery of the system to the consumer
Determination of Program Requirements
Program requirements refer to the management approach and the steps to be followed in the procurement and/or acquisition of the system in response to a stated need, along with the identification of the resources required to fulfill this objective.
A program structure should be established that will enable the design and development, production and/or construction, and delivery of the system to the consumer in a cost-effective manner.

12. Determination of Program Requirements (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Determination of Program Requirements (cont.)
Includes identification of :
Program functions and detailed tasks
Development of an organizational structure
Development of a work breakdown structure (WBS)
Preparation of program schedules and cost projections
Implementation of program evaluation and control capability
Program plan provides the necessary day-to-day management guidance
Program requirements includes the identification of program functions and detailed tasks, the development of an organizational structure, the development of a work breakdown structure (WBS), the preparation of program schedules and cost projections, the implementation of a program evaluation and control capability, and so on.
This information, presented in the form of a program plan, provides the necessary day-to-day management guidance required in the realization of any technical objective.

13. System Engineering Management Plan (SEMP)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Management Plan (SEMP)
Developed based on the Program Management Plan (PMP)
Covers all management functions associated with system engineering activities
Constitutes chief engineer’s plan for identifying and integrating all engineering activities.
Preparation is the responsibility of the “system manager”
May be accomplished by the customer or by a major contractor
System Engineering Management Plan (SEMP)
System engineering management plan (SEMP) is developed based on the program management plan and covers all management functions associated with the performance of system engineering activities for a given program.
The SEMP constitutes the chief engineer’s plan for identifying and integrating all major engineering activities.
Preparation of the SEMP is the responsibility of the “system manager” and may be accomplished by the customer or by a major contractor, depending on the program.

14. System Engineering Management Plan (SEMP) (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Management Plan (SEMP) (cont.)
Must be developed directly from the top-level Program Management Plan (PMP).
Responsibility must be clearly defined and supported by the program manager.
Must be the key top-level design engineering plan
Content tailored to the system requirements, program size and complexity, and nature of the procurement and acquisition process
In order for the SEMP to be meaningful and accomplish its objectives, it must be developed directly from the top-level Program Management Plan (PMP). The responsibility for the SEMP, and for the accomplishments of the functions described within, must be clearly defined and supported by the program manager.
The SEMP must be appropriately identified as the key top-level design engineering plan in the overall program documentation tree structure.
In terms of content, the SEMP must be tailored to the system requirements, the program size and complexity, and the nature of the procurement and acquisition process.
The following slides will describe selected topics in the SEMP that deserve additional coverage.

15. Statement of Work (SOW)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Statement of Work (SOW)
A narrative description of the work required for a given project
General guidelines:
Short and to the point
Written in a clear and precise manner
Avoid ambiguity and the possibility of misinterpretation
Describe requirements in sufficient detail
Consider practical application and possible legal interpretations
Avoid unnecessary repetition and incorporation of extraneous material and requirements
Can result in unnecessary costs
Do not repeat detailed specifications and requirements already covered in referenced documentation
Statement of Work (SOW)
The statement of work (SOW) is a narrative description of the work required for a given project.
In preparing the SOW, the following general guidelines are considered appropriate:
The SOW should be relatively short and to the point, and must be written in a clear and precise manner.
Every effort must be made to avoid ambiguity and the possibility of misinterpretation.
Describe the requirements in sufficient detail to ensure clarity, considering both practical application and possible legal interpretations.
Avoid unnecessary repetition and the incorporation of extraneous material and requirements. This can result in unnecessary costs.
Do not repeat detailed specifications and requirements that are already covered in the applicable referenced documentation.

16. Definition of System Engineering Functions
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Definition of System Engineering Functions
Cover a broad spectrum of activity
Fulfillment of objectives require involvement in almost every facet of program activity
Overall basic goals for system engineering:
Requirements developed through iterative requirements analysis
System design alternatives properly evaluated against meaningful, quantifiable criteria
Definition of System Engineering Functions
System engineering covers a broad spectrum of activity. The fulfillment of system engineering objectives require some involvement, either directly or indirectly, in almost every facet of program activity.
As a start, a review of some of the overall basic goals for system engineering is appropriate. The objectives of system engineering are the following:
Ensure that the requirements for system design and development, test and evaluation, production, operation, and support are developed in a timely manner through a top-down, iterative requirements analysis
Ensure that system design alternatives are properly evaluated against meaningful, quantifiable criteria that relate to all the desired characteristics.

17. Definition of System Engineering Functions (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Definition of System Engineering Functions (cont.)
Overall basic goals for system engineering:
All applicable design disciplines and specialty areas appropriately integrated into the total engineering effort
Overall system development effort progresses in a logical manner
Established configuration baselines, formal design review, proper documentation supporting design decisions, and necessary provisions for corrective action
Various system elements/components are compatible with each other
Combined to provide an entity that will perform its required functions
Ensure that all applicable design disciplines and related specialty areas are appropriately integrated into the total engineering effort in a timely and effective manner.
Ensure that the overall system development effort progresses in a logical manner with established configuration baselines, formal design review, the proper documentation supporting design decisions, and the necessary provisions for corrective action as required.
Ensure that the various elements (or components) of the system are compatible with each other and are combined to provide an entity that will perform its required functions in an effective and efficient manner.

18. System Engineering Tasks
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Tasks
System Engineering Tasks
Although each individual program is different and activities must be tailored accordingly, the tasks presented in this figure and discussed in the following slide are considered applicable in most instances.

19. Definition of System Engineering Tasks
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Definition of System Engineering Tasks
Critical tasks
Perform a needs analysis and conduct feasibility studies
Define system operational requirements, maintenance concept, and TPMs
Prepare the system Type “A” specification
Prepare Test and Evaluation Master Plan
Prepare the System Engineering Management Plan
Accomplish functional analysis and allocation of requirements
Definition of System Engineering Tasks
The following is the list system engineering tasks shown in the previous figure that are considered an example of what might be appropriate for a typical program, although the specific requirements may vary from one program to the next.
We identify the tasks that are critical relative to meeting the five major system engineering objectives stated earlier in this module. Most of these tasks were also discussed in module 2.
Perform a needs analysis and conduct feasibility studies
Define system operational requirements, the system maintenance concept, and the technical performance measures (TPMs)
Prepare the system Type “A” specification
Prepare Test and Evaluation Master Plan

20. Definition of System Engineering Tasks (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Definition of System Engineering Tasks (cont.)
Critical tasks
Accomplish system synthesis, analysis, and design integration functions on a continuing basis throughout the overall design and development process
Plan, coordinate, and conduct formal design reviews meetings
Monitor and review system test and evaluation activities
Plan, coordinate, implement, and control design changes
Initiate and maintain production and supplier liaison, and customer service activities
Prepare the System Engineering Management Plan
Accomplish functional analysis and the allocation of requirements
Accomplish system synthesis, analysis, and design integration functions on a continuing basis throughout the overall design and development process
Plan, coordinate, and conduct formal design reviews meetings
Monitor and review system test and evaluation activities
Plan, coordinate, implement, and control design changes as they evolve from engineering change proposals (ECPs) initiated from either day-to-day review activity or as a result of formal design reviews
Initiate and maintain production/construction liaison, supplier liaison, and customer service activities.

21. System Engineering Organization and Interfaces
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Organization and Interfaces
System Engineering Organization and Interfaces
This figure represents an abbreviated illustration to show how a system engineering department/group might fit within and relate to other major functions within the overall organization for a large contractor.
Effective communication links, represented by the dotted lines in the figure, must be in place and functioning from the beginning.
Although the organizational “makeup” within the system engineering block in the figure may look great on paper, it will not work unless the many noted interfaces are operational on a day-to-day basis.

22. System Engineering Interfaces
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Interfaces
Interface
A statement of the functional requirements and constraints that exist at a common boundary between
Two functions (functional interface)
Two configuration items (physical interface)
Interface definition and management is essential
Breaking down the system into subsystems, modules and components to reduce complexity may result in interface complexity
System Engineering Interfaces
An interface is a statement of the functional requirements and constraints that exist at a common boundary between two functions (functional interface) or two configuration items (physical interface).
Interface definition and management is essential in systems engineering because breaking down the system into subsystems, modules and components to reduce complexity may introduce interface complexity.
Consequently, there must be a balance in systems engineering between the complexity of any element and the complexity of any associated interface.
There must be a balance between the complexity of any element and the complexity of any associated interface

23. System Engineering Organization
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Organization
Must lead and ensure tasks are completed in an effective, efficient, and timely manner using system-level technical expertise and leadership
Must work with, influence, and inspire many other groups within the project
Must have the respect and cooperation of the other required functions
System Engineering organization
The system engineering organization through its system-level technical expertise and its leadership abilities, must take the lead and ensure that the necessary tasks are completed in an effective, efficient, and timely manner.
The system engineering organization must be able to work with, influence, and inspire many other groups within the project if the specified tasks are to be successfully completed.
The system engineering organization must have the respect and cooperation of the other required functions in order for the proper integration to occur.

24. System Engineering Organization (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
System Engineering Organization (cont.)
May be contained within the customer’s organization, with various responding subgroups within the contractor’s organization
In a contractor’s organization basic structure may constitute:
A functional approach
A project/product line approach
A matrix approach, or
Various combinations thereof.
Advantages and disadvantages associated with each of these approaches
Essential to recognize if the organization is to work effectively
Need to consider external interactions involving subcontractors and suppliers,
The primary system engineering organization may be contained within the customer’s organization, with various responding subgroups within the contractor’s organization.
In a contractor’s organization, the basic structure may constitute a functional approach, a project/product line approach, a matrix approach, or various combinations thereof.
There are advantages and disadvantages associated with each of these approaches, which are essential to recognize if the system engineering organization is to work effectively within the structure provided.
There are also the external interactions involving subcontractors and suppliers, which, in turn, may be critical for the accomplishment of the work required.

25. Partial Work Breakdown Structure Development
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Partial Work Breakdown Structure Development
System XYZ
Activity A
Activity B
Activity C
Activity d
Function 1
Function 2
Function 3
Function 4
Contract Work Breakdown Structure (CWBS)
Detail Design and Development Phase
Preliminary System Design Phase
Level 3
Level 2
Level 1
Partial Work Breakdown Structure Development
The figure shows a typical work breakdown structure for system development projects. A Work Breakdown Structure is a results-oriented family tree that captures all the work of a project in an organized way.
Additional level 2 elements not shown here might include development environment support, logistics and training, and installation and startup.
A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to functional area cost accounts that are made up of individual work packages. Whether you need three levels or seven, work packages should add up through each WBS level to form the project total.

26. Development of a Work Breakdown Structure (WBS)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Development of a Work Breakdown Structure (WBS)
Large projects organized and comprehended by breaking them into smaller pieces
A collection of defined "work packages" that may include a number of tasks
A $1,000,000,000 project is simply a lot of $50,000 projects joined together
Used to provide the framework for organizing and managing the work
Development of a Work Breakdown Structure (WBS)
Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks.  A $1,000,000,000 project is simply a lot of $50,000 projects joined together.
The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work.

27. Development of a Work Breakdown Structure (WBS) (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Development of a Work Breakdown Structure (WBS) (cont.)
Our brains can normally comprehend around 7-9 items simultaneously
WBS helps break thousands of tasks into chunks that
Preparing and understanding a WBS is a big step towards managing and mastering its complexity
Used at project start for:
Defining scope
Organizing schedules
Estimating costs
Lives throughout the project in project schedule and used for reporting costs
May be used to identify/track work packages, organize data for reporting, etc.
The psychologists say our brains can normally comprehend around 7-9 items simultaneously.  A project with thousands or even dozens of tasks goes way over our ability to grasp all at once.  The solution is to divide and conquer.  The WBS helps break thousands of tasks into chunks that we can understand and assimilate.  
Preparing and understanding a WBS for your project is a big step towards managing and mastering its inherent complexity. 
The WBS is commonly used at the beginning of a project for defining project scope, organizing Gantt schedules and estimating costs. 
It lives on, throughout the project, in the project schedule and often is the main path for reporting project costs.  On larger projects, the WBS may be used throughout the project to identify and track work packages, to organize data for reporting, for tracking deliverables, etc.

28. CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Sample WBS
3A1100 Project Management
3A1200 System Engineering
3A1300 Configuration Management
3A1400 Contract Management
3A1500 Data Management
3A1600 Integrated Logistics Support
3A1700 Supplier Management
2A1000
System/Program
Management
2B1000
Research and Development
3B1100 Basic Research
3B1200 Applied Research
3B1300 Technology Development
3C1100 Airframe
3C1200 Propulsion
3C1300 Communications
3C1400 Navigation/Guidance
3C1500 Fire Control
3C1600 Countermeasures
3C1700 Reconnaissance Equipment
3C1800 Flight Controls
3C1900 Auxiliary Electronics
3C2000 Armament/Weapons Equipment
3C2100 Hydraulic Equipment
3D1100 Peculiar Support Equipment - Organizational Level
3D1200 Peculiar Support Equipment - Intermediate Level
3D1300 Peculiar Support Equipment - Depot Level
3D1400 Common Support Equipment - Organizational Level
3D1500 Common Support Equipment - Intermediate Level
3D1600 Common Support Equipment - Depot Level
2C1000
Prime Mission
Equipment
2D1000
Support
System XYZ
Level 3
Level 2
Level 1
Sample WBS
Work breakdown structure is often portrayed graphically as a hierarchical tree. However, it can also be a tabular list of "element" categories and tasks or the indented task list that appears in a Gantt chart schedule, as shown in this figure.

29. CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Specification/Documentation Tree
Specification/Documentation Tree
The “tree” in this figure is developed from the top down, commencing with the preparation of the system specification. Subsequently, additional specifications are applied.
As one progresses, the application of specifications must be consistent with the work requirements described by the work breakdown structure.
Even though the design requirements may dictate the use of an available off-the-shelf item, the application of that item in this system may be quite different from comparable application in other systems.

30. Specification/Documentation Tree (cont.)
CSUN - Prof. David Shternberg
Specification/Documentation Tree (cont.)
MSE607B- Systems Engineering
Thus, the major components of the system should be described through a series of program-related specifications, as shown in this figure. For example, development specifications, product specifications, product specifications, and process specifications.
The System Specification is produced by the Conceptual Design process of the systems engineering lifecycle and forms the basis of the Functional Baseline. The System Specification describes the system's functional architecture. The System Specification is perhaps the most important of all systems engineering documents as it is the source of reference for all future work and documentation. The later these problems are discovered, the more expensive and less likely the rectification.

31. Specification/Documentation Tree (cont.)
CSUN - Prof. David Shternberg
Specification/Documentation Tree (cont.)
MSE607B- Systems Engineering
The Development Specification is produced by the Preliminary Design activities in the systems engineering lifecycle. The Development Specification forms the basis of the Allocated Baseline and describes the physical architecture of the system.
The Product Specification is developed during the Detailed Design and Development activities of the systems engineering lifecycle.

32. Specification/Documentation Tree (cont.)
CSUN - Prof. David Shternberg
Specification/Documentation Tree (cont.)
MSE607B- Systems Engineering
Provides a hierarchical description of the various specifications for a systems development as part of a systems engineering process
Developed from the top down, commencing with the preparation of the system specification
Subsequently, additional specifications are applied
Top down development of design requirements is critical
Meet the system engineering objectives
A Specification Tree, also known as Documentation Tree, provides a hierarchical description of the various specifications for a systems development as part of a systems engineering process.
The “tree” in is developed from the top down, commencing with the preparation of the system specification. Subsequently, additional specifications are applied.
The development of design requirements from the top down is critical in meeting the system engineering objectives stated earlier.

33. Specification/Documentation Tree (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Specification/Documentation Tree (cont.)
Extreme care must be exercised in the initial identification and application of specifications and standards
Costly results if proper level of attention is not directed from the beginning
Critical task is tailoring specifications to particular system application
Extreme care must be exercised in the initial identification and application of specifications and standards.
Although the specification tree application function is sometimes viewed as being relatively minor, the results can be rather costly if proper level of attention is not directed to this area from the beginning.
The critical task here is the tailoring of specifications to the particular system application.

34. Technical Performance Measurement (TPM)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Technical Performance Measurement (TPM)
Key indicator of progress, parameter or a metric that can be used to monitor the progress or performance of selected requirements
Monitored to ensure that it remains within tolerances as an indication of the progress of the design
One of the most commonly used systems engineering tools.
Identified at a very early stage in the systems engineering process
During Conceptual Design
Progress is continually monitored throughout the Acquisition Phase as a major risk-mitigation measure
Technical Performance Measurement (TPM)
A technical performance measure (TPM) is a key indicator of progress, parameter or a metric that can be used to monitor the progress or performance of selected requirements.
A technical performance measure is monitored to ensure that it remains within tolerances as an indication of the progress of the design.
A technical performance measure is one of the most commonly used systems engineering tools.
Technical performance measures are identified at a very early stage in the systems engineering process (during Conceptual Design) and their progress is continually monitored throughout the Acquisition Phase as a major risk-mitigation measure.

35. Development of Program Schedules
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Development of Program Schedules
Individual program tasks are presented in terms of a time line
A beginning time and an ending time
Developed to reflect work requirements throughout all phases of a program
Commences with identification of major program milestones at the top level
Proceeds downward through lower levels of detail
Development of Program Schedules
In line with the Statement of Work and the Work Breakdown Structure, individual program tasks are presented in terms of a time line. That is, a beginning time and an ending time.
Schedules are developed to reflect the work requirements throughout all phases of a program.
Schedule planning commences with the identification of major program milestones at the top level and proceeds downward through lower levels of detail.

36. Development of Program Schedules (cont.)
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Development of Program Schedules (cont.)
A system engineering master schedule (SEMS) is prepared:
Laying out major program activities on basis of elapsed time
Serves as a reference for a family of subordinate schedules
Progress against a given schedule is measured at the bottom level
Task status information is related to appropriate cost account
Techniques:
Bar chart
Milestone chart
Combined milestone/bar chart
A system engineering master schedule (SEMS) is initially prepared, laying out the major program activities on the basis of elapsed time. This serves as a frame of reference for a family of subordinate schedules, developed to cover subdivisions of work as presented by the WBS.
Progress against a given schedule is measured at the bottom level, and task status information is related to the appropriate cost account identified by the WBS element and the responsible organization.
Program task scheduling may be accomplished using one or a combination of techniques. Some of the more common methods are:
Bar chart
Milestone chart
Combined milestone/bar chart

37. Program Schedule – Sample Bar Chart
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Program Schedule – Sample Bar Chart
Program Schedule - Sample Bar Chart
A simple bar chart presents program activities in terms of sequences and the time span of efforts.
This figure illustrates a partial bar chart. As you can see, specific milestones and the assignment of resources are not covered.

38. Program Schedule – Sample Milestone Chart
CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Program Schedule – Sample Milestone Chart
Program Schedule – Sample Milestone Chart
A milestone chart is a representation of specific program events and required start and completion times by calendar date is included.
Deliverable items required under contract are noted. This figure shows a sample milestone chart.

39. CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Summary
Topics
System engineering program requirements
System engineering management plan (SEMP)
Determination of “outsourcing” requirements
Integration of design specialty plans
Interfaces with other program activities
Management methods/tools
Risk management plan
Global applications/relationships
Summary
This module addressed the system engineering program planning associated with the system design and development activities.
We identified and explained the following topics related to program planning:
System engineering program requirements
System engineering management plan, also known as (SEMP)
Determination of “outsourcing” requirements
Integration of design specialty plans
Interfaces with other program activities
Management methods and/or tools
Risk management plan, and
Global applications and/or relationships

40. CSUN - Prof. David Shternberg
MSE607B- Systems Engineering
Homework Assignment
Chapter 6 Part I – Textbook page 334
Answer questions 1, 3, 9.
Continue to read Chapter 6 - Engineering Program Planning
Pages

41. Questions? Comments?