Engineering Systems Engineering

Management
Management

MSE607B
Chapter 6 Part I of II
System Engineering Program Planning
 Learning Objectives
 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

2
 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

3
 Management of System Engineering

System engineering is applicable in all phases of life cycle

Greatest benefits are derived from emphasis in early
stages

4
 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
5
Integration of Disciplines

6
Management and Technology Applied
to the System Engineering Process

7
 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

8
System Engineering Planning

9
 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
10
 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

11
 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

12
 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

13
 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

14
 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

15
 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

16
 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

17
System Engineering Tasks

18
 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

19
 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

20
System Engineering Organization
and Interfaces

21
 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
 There must be a balance between the
complexity of any element and the
complexity of any associated interface

22
 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

23
 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,

24
 Partial Work Breakdown Structure
Development
01-00-00
Level 1 System XYZ

01-01-00 01-02-00 01-03-00 01-04-00

Level 2 Activity A Activity B Activity C Activity d

01-02-01 01-02-02 01-02-03 01-02-04

Level 3 Function 1 Function 2 Function 3 Function 4

Contract Work Breakdown Structure (CWBS) Contract Work Breakdown Structure (CWBS)
Preliminary System Design Phase Detail Design and Development Phase

25
 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

26
 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.

27
 Sample WBS

Level 1 Level 2 Level 3

3A1100 Project Management

3A1200 System Engineering
2A1000 3A1300 Configuration Management
System/Program 3A1400 Contract Management
Management 3A1500 Data Management
3A1600 Integrated Logistics Support
3A1700 Supplier Management
2B1000 3B1100 Basic Research
Research and 3B1200 Applied Research
Development 3B1300 Technology Development
3C1100 Airframe
3C1200 Propulsion
System XYZ 3C1300 Communications
3C1400 Navigation/Guidance
2C1000 3C1500 Fire Control
Prime Mission 3C1600 Countermeasures
Equipment 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
2D1000 3D1300 Peculiar Support Equipment - Depot Level
Support
3D1400 Common Support Equipment - Organizational Level
Equipment
3D1500 Common Support Equipment - Intermediate Level
3D1600 Common Support Equipment - Depot Level
Specification/Documentation Tree
Specification/Documentation Tree
(cont.)

30
Specification/Documentation Tree
(cont.)

31
 Specification/Documentation Tree
(cont.)

 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

32
 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

33
 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
34
 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

35
 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

36
Program Schedule –
Sample Bar Chart

37
 Program Schedule –
Sample Milestone Chart

38
 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

39
 Homework Assignment
 Chapter 6 Part I – Textbook page 334
• Answer questions 1, 3, 9.

 Continue to read Chapter 6 - Engineering

Program Planning
• Pages 292-334

40
Questions? Comments?

41