Introduction to Technical Management Processes Page 1 of 14

Introduction to Technical Management Processes

This topic provides an overview of Systems Engineering Technical

Management Processes. These processes are used for planning,
controlling, assessing and analyzing Systems Engineering Technical
Processes.

Get the printer friendly version of the topic here.

Introduction to Technical Management Processes Page 2 of 14

Content of Lesson
A key part of Systems Engineering is planning, assessing, analyzing and controlling various technical
activities to help ensure that an integrated and total life cycle-balanced set of system, people and process
solutions is created that satisfies customer needs.

Technical Management Processes are the means to that end. These processes are:

z Technical Planning
z Requirements Management
z Interface Management
z Risk Management
z Configuration Management
z Technical Data Management
z Technical Assessment
z Decision Analysis

This lesson summarizes each of these Technical Management Processes and how they are interrelated.

Select NEXT to continue.

Introduction to Technical Management Processes Page 3 of 14

Technical Management Processes

There are several ways to categorize Technical Management Processes. One way is to divide them into
two process sets used as:

z Planning, Control and Assessment Processes

{ These Technical Management Processes are used to manage the technical development of the
system, including its various supporting or enabling products.
{ This involves:
„ Planning the overall Systems Engineering effort
„ Controlling requirements, interfaces, risks, configurations and technical data
„ Assessing, monitoring and reviewing planned progress
z Decision Analysis Process
{ The basis for evaluating and selecting technical alternatives when decisions need to be made.
{ Some examples include:
„ During the Stakeholder Requirements Definition Process, balancing requirements in
terms of cost, schedule, performance and risk
„ Conducting analyses to help choose among alternatives to achieve a balanced,
supportable, robust and cost-effective design as part of the Architecture Design Process
„ As part of the Verification Process and the Validation Process, determining the cause of
deficiencies and determining corrective actions

Select NEXT to continue.

Popup Text:

process
A process is a sequence of steps performed for a given purpose. A process converts an input (such as
requirements) to a desired output (such as defined work products) through a set of structured activities. To
execute a process, it takes resources such as trained people, funds, facilities, equipment, tools and methods.
Processes are constrained by various management, legal and regulatory directives and requirements.

Stakeholder Requirements Definition Process

One of the Systems Engineering Technical Processes, Stakeholder Requirements Definition generates Technical
Requirements derived from Stakeholder Requirements and other Interested Party Requirements.

Architecture Design Process

One of the Systems Engineering Technical Processes, Architecture Design is used to transform the outputs of
the Requirements Analysis Process into a set of design solutions and physical architectures that are described
by specifications and other design configuration descriptions.

Verification Process
One of the Systems Engineering Technical Processes, Verification is used to confirm that the 'as realized
product', whether achieved by Implementation or Integration, conforms to its design-to or build-to
specifications.

Validation Process
One of the Systems Engineering Technical Processes, Validation is used to confirm that the 'as realized
product', whether achieved by Implementation or Integration, conforms to its Stakeholder Requirements.
Introduction to Technical Management Processes Page 4 of 14

Technical Control
This diagram illustrates the various Technical
Management Processes arranged in the context
of their uses in planning, controlling, assessing
and analyzing Systems Engineering Technical
Processes.

These processes are shown in a linear sequence

here for display purposes. However, on a
typical complex DoD program, these various
Technical Management Processes are applied
recursively and iteratively over time in
conjunction with the various Technical
Processes being used to design and realize
products.

Five of the Technical Management Processes

can be grouped together in what is typically
referred to as Technical Control.

Select NEXT to continue.

D-Link Text:

Long Description:

A text flowchart detailing the Technical Management Processes. The top box is Technical Planning, with a box
below labeled Requirements Management, with a box below labeled Interface Management, with a box below
labeled Risk Management, with a box below labeled Configuration Management, with a box below labeled
Technical Data Management, with a box below labeled Technical Assessment, and a final box labeled Decision
Analysis.

Close window to continue.

Popup Text:

Technical Processes
Technical Processes are used to design and realize the system products, including the operational/mission
products and supporting or enabling products required to produce, support, operate or dispose of system End
Products. Technical Processes consist of: Stakeholder Requirements Definition, Requirements Analysis,
Architecture Design, Implementation, Integration, Verification, Validation and Transition.

recursively
Technical Management Processes are recursive in that they are applied repeatedly at a given layer in the
system hierarchy. For instance, as a system is elaborated into End Products and Enabling Products and into
systems and subsystems, the complete range of Systems Engineering Technical Management Processes is
applied to manage the Technical Processes being used for each of them.

iteratively
When a process is applied iteratively, it is repeated multiple times when a problem is discovered. For instance,
if in the application of Requirements Analysis and Architecture Design, problems are discovered traceable to
flaws in the original stakeholder requirements, then Stakeholder Requirements Definition, Requirements
Analysis and Architecture Design Solution Technical Processes, along with the repertoire of Technical
Management Processes needed to control them, will be repeated as needed to resolve discovered problems
before proceeding to the next stage, the Implementation Process.
Introduction to Technical Management Processes Page 5 of 14

Knowledge Review
Please select a correct answer.

Some Technical Management Processes can be grouped together into 'Technical Control Processes'.
Complete the following listing of Technical Control Processes in the best order.

Requirements Management, _______, _______, _______, Technical Data Management

A. Technical Planning, Decision Analysis, Technical Assessment
B. Interface Management, Risk Management, Configuration Management
C. Requirements Analysis, Architecture Design, Implementation
D. Integration, Verification, Validation

Submit
Introduction to Technical Management Processes Page 6 of 14

Technical Control Q&A

Proper application of Technical Control
processes involves a number of considerations.

Select each of the questions below to learn

more about these.

What is technical control?

What should be controlled?

What is involved with control?

Select NEXT to continue.

Popup Text:

What is technical control?

Manage the technical effort to keep it out of trouble. If it gets in trouble, take corrective action via
adjustments and re-planning to bring it back under control in a timely, cost-effective manner. Focus is on
assuring that Systems Engineering Technical Processes are providing the correct outcomes.

What should be controlled?

Control system design and other process inputs, work products, and other outcomes such as requirements,
interfaces, risks, configurations and data and changes to these that would affect cost and schedule.

What is involved with control?

Key actions are decision-making and re-directing activities. This includes ensuring: that Technical Process
outcomes are managed; that identified problems are resolved; that timely adjustments are made by directing
changes to other process activities or by re-planning; and that information on project progress and status and
deliverables are disseminated to the right persons or parties, as required.
Introduction to Technical Management Processes Page 7 of 14

Process Group Inputs and Outputs

This graphic adds representative major inputs
and outputs of the process groups. These inputs
and outputs illustrate the key relationships
among these Technical Management Processes.

These inputs and outputs are generated as the

results of the various Technical Management
Processes being performed.

Select NEXT to continue.

D-Link Text:

Long Description:

A text flowchart detailing the Technical Management Processes. The top box is Technical Planning, with a box
below labeled Requirements Management, with a box below labeled Interface Management, with a box below
labeled Risk Management, with a box below labeled Configuration Management, with a box below labeled
Technical Data Management, with a box below labeled Technical Assessment, and a final box labeled Decision
Analysis.

Close window to continue.

Introduction to Technical Management Processes Page 8 of 14

Process Relationships
This graphic shows the relationships among the
five Technical Control Processes. Depicted are
the major input and output flows among these
five processes.

The dot is a graphic display convention used

here to indicate potential process interface with
one or more other processes. These are added
for clarity and to remove ambiguity with respect
to flows when multiple inputs and outputs
intersect on the graphic.

It is obvious that there is a large amount of

interaction among the Technical Control
Processes. That is to be expected: many
Systems Engineering factors and relationships
exist with multiple, complex interrelationships
among them.

Select NEXT to continue.

D-Link Text:

Long Description:

A text flowchart detailing the Technical Management Processes. The top box is Technical Planning, with a box
below labeled Requirements Management, with a box below labeled Interface Management, with a box below
labeled Risk Management, with a box below labeled Configuration Management, with a box below labeled
Technical Data Management, with a box below labeled Technical Assessment, and a final box labeled Decision
Analysis.

Close window to continue.

Introduction to Technical Management Processes Page 9 of 14

Process Constraints
The additions to this graphic are to indicate the
context within which Technical Management
Processes are constrained.

The processes are conducted within a program

to meet both Systems Engineering technical
goals, as well as support program management
objectives.

Programs typically exist within the oversight of

one or more 'Technical Authorities'. These
Technical Authorities provide technical
management directions and resources to the
program, based on outcomes of the technical
effort, and support the Program Manager.

Select NEXT to continue.

D-Link Text:

Long Description:

A text flowchart detailing the Technical Management Process. The top box is labeled Program Management,
with a box below labeled Technical Planning, with a box below labeled Requirements Management, with a box
below labeled Interface Management, with a box below labeled Risk Management, with a box below labeled
Configuration Management, with a box below labeled Technical Data Management, with a box below labeled
Technical Assessment, with a box below labeled Decision Analysis, and a final box labeled Technical
Management.

Close window to continue.

Popup Text:

Technical Authorities
Technical Authority is the organization(s) having responsibility to establish, approve and judge conformance of
products and technical processes to technical requirements and statutory, regulatory and policy dictates
during all phases of product development, acquisition and sustainment.

Technical Authority is generally most effective in ensuring technical rigor when it resides outside of the
Program Manager's direct chain of command. An example of this would be the lead engineers in PEOs, who are
responsible to the head of engineering or Lead/Chief Engineer for the implementing Command. Technical
Authority procedures vary organizationally and are dependent on Service policies.
Introduction to Technical Management Processes Page 10 of 14

Programmatic Linkages
This final graphic incorporates illustrative
programmatic linkages of Technical
Management Processes, which cannot be used
in isolation but must ultimately support
program and project needs.

Within the context of the acquisition life cycle,

outputs of Technical and Program Control
activities are used specifically to address
various key exit criteria by life cycle phase.

Proper application of these processes

throughout the acqusition life cycle helps to
ensure cost, schedule and performance criteria
are met within acceptable risk levels.

Select NEXT to continue.

D-Link Text:

Long Description:

A text flowchart detailing the Technical Management Process. The top box is labeled Program Management,
with a box below labeled Technical Planning, with a box below labeled Requirements Management, with a box
below labeled Interface Management, with a box below labeled Risk Management, with a box below labeled
Configuration Management, with a box below labeled Technical Data Management, with a box below labeled
Technical Assessment, with a box below labeled Decision Analysis, and a final box labeled Technical
Management.

Close window to continue.

Introduction to Technical Management Processes Page 11 of 14

Knowledge Review
Please select all that apply by clicking on the check box.

In the context of the application of Technical Management Processes, what is involved with 'control'?
A. Ensuring that Technical Process outcomes are managed
B. Appropriate dissemination of project progress and status information
C. Necessary adjustments and re-planning made in a timely manner
D. Identified problems resolved appropriately

Submit
Introduction to Technical Management Processes Page 12 of 14

Process Presentation Convention

In order to provide consistent explanations of
the various Technical Management Processes, a
standard convention for describing them is used
throughout the topics that comprise this lesson.

This convention includes a graphic with several

key parts. These parts illustrate the major
inputs and outputs, the preceding processes
providing inputs, the destination processes
using or receiving the outputs, and the various
key steps involved in implementing a particular
Technical Management Process. One example
(from Risk Management) is shown here.

Each of the activities comprising a given

process is then described in more detail. These
details include the illustrative tasks making up
the phases of the process and the expected
outcomes of each, along with when it has been
successfully applied.

Select Next to continue.

D-Link Text:

Long Description:

Technical Processes chart. Flow begins From Other Technical Processes, From Technical Processes and From
Technical Planning Assessment Processes. Flow continues with Risk Management Planning to Risk
Identification to Risk Analysis to Risk Mitigation Planning to Risk Tracking to Risk Mitigation Implementation.
To the left of this flow is Program Risk Management Plan, Risk Status Measures and Risk Concerns. To the
right of the flow are Technical Risk Management Procedures, Approved Risk Statements, Risk Mitigation Plans
and Risk Status Reports.

Close window to continue.

Introduction to Technical Management Processes Page 13 of 14

Tasks and Outcomes

Each Technical Management Process always
starts with a 'Prepare for...' or 'Plan for...'
activity that describes the tasks needed to lay
the foundation for the successful application of
the particular process being described.

The task listings and outcomes that comprise

each Technical Management Process activity are
not mandated by specific DoD policies. They do
represent a consensus by recognized experts in
Systems Engineering of those activities and
illustrative tasks that are needed for a robust,
effective process. They are a template of 'best
practices' that can be tailored and used to
perform or oversee Systems Engineering
activities.

Many people played key roles in developing

these course materials. Additionally, some
portions of this course use materials from
ANSI/EIA-632, Processes for Engineering a
System as well as the NASA Systems
Engineering Handbook. The assistance of the
EIA and NASA in this regard is gratefully
acknowledged.

Select NEXT to continue. D

D-Link Text:

Long Description:

Technical Processes chart. Flow begins From Other Technical Processes, From Technical Processes and From
Technical Planning Assessment Processes. Flow continues with Risk Management Planning to Risk
Identification to Risk Analysis to Risk Mitigation Planning to Risk Tracking to Risk Mitigation Implementation.
To the left of this flow is Program Risk Management Plan, Risk Status Measures and Risk Concerns. To the
right of the flow is Technical Risk Management Procedures, Approved Risk Statements, Risk Mitigation Plans
and Risk Status Reports.

Close window to continue.

Popup Text:

people
Among others, these primarily included: Dr. Jerry Lake, editor of ISO/IEC 19760 and editorial team member
on several national and international Systems Engineering standards such as EIA 632, IEEE 1220 and ISO/IEC
15288; Dr. John Snoderly, DAU Program Director for Systems Engineering and former (2002-2004) President
of the International Council of Systems Engineers (INCOSE); Mr Bob Skalamera, former Director OSD AT&L
Defense Systems, Enterprise Development; COL Warren Anderson, former Deputy for Systems Engineering
Plans and Policy, OUSD (AT&L) Defense Systems; Dr. Dave Brown DAU SYS-101 Course Manager (top-down
design) and Mr Bill Zimmerman DAU SYS-101 Course Manager (bottom-up product realization); DAU
Instructional System Designer Dr. Joel Zamkoff and James McDaniel; various course developers including
private consultants Dr. Sherwin Jacobson, John Olmstead and Michael Findley; DAU Systems Engineering
faculty course reviewers and an anonymous Cosmetic Engineer.
NASA Systems Engineering Handbook
After much study and coordination, the NASA and the DoD, working in collaboration, developed and
implemented essentially the same sets of Systems Engineering processes.

acknowledged
The following EIA diagrams are used this course: Figures: 6.1.1, 6.1.2.1, 6.2, 6.2.1a, and G.1 from ANSI/EIA-
632, Processes for Engineering a System, Copyright © (1999) Government Electronics and Information
Technology Association, a Sector of the Electronic Industries Alliance. All Rights Reserved. Reprinted by
Permission.
Introduction to Technical Management Processes Page 14 of 14

Summary
Technical Management Processes provide for
the capture and management of outcomes from
technical efforts including:

z Recognition of potential obstacles to

completing technical efforts
z Redirection of technical work to overcome
obstacles
z Response to changing circumstances
z Correction of variances and out-of-
compliance conditions
z Dissemination of project progress and
status information

They are conducted within a program to

support Systems Engineering technical goals, as
well as program management objectives.

You have reached the end of this topic. To

proceed, select the next topic in the Table of
Contents.