introduction to technical management processes

8/7/2019 Introduction to Technical Management Processes

1/16

Introduction to Technical Management Processes Page 1 of 14

This topic provides an overview of Systems Engineering TechnicalManagement 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


2/16


Content of Lesson

A key part of Systems Engineering is planning, assessing, analyzing and controlling various technicalactivities 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:

Technical Planning Requirements Management

Interface Management

Risk Management

Configuration Management

Technical Data Management

Technical Assessment

Decision Analysis

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

Select NEXT to continue.


3/16


Technical Management Processes

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

Planning, Control and Assessment P rocesses 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

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 ofdeficiencies and determining corrective actions


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 P rocess

One of the Systems Engineering Technical Processes, Stakeholder Requirements Definition generates TechnicalRequirements 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 ofthe 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 realizedproduct', whether achieved by Implementation or Integration, conforms to its Stakeholder Requirements.


4/16


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

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


D

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

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 EndProducts. Technical Processes consist of: Stakeholder Requirements Definition, Requirements Analysis,

Architecture Design, Implementation, Integration, Verification, Validation and Transition.

recursivelyTechnical 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


5/16

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, RequirementsAnalysis 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.


6/16


Knowledge Review

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

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


7/16


Technical Control Q&A

Proper application of Technical Control

processes involves a number of considerations.

Select each of the questions below to learnmore about these.

What is technical control?

What should be controlled?

What is involved with control?


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 w ith 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 directingchanges 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.


8/16


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 theresults of the various Technical Management

Processes being performed.


D

D-Link Text:

Long Description:







9/16


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


D

D-Link Text:

Long Description:







10/16


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 technicalgoals, as well as support program management

objectives.

Programs typically exist within the oversight of

one or more 'Technical Authorities'. These

Technical Authorities provide technicalmanagement directions and resources to the

program, based on outcomes of the technical

effort, and support the Program Manager.


D

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 labeledTechnical Assessment, with a box below labeled Decision Analysis, and a final box labeled Technical

Management.


Popup Text:

Technical Authorities

Technical Authority is the organization(s) having responsibility to establish, approve and judge conformance ofproducts 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 theProgram 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.


11/16


Programmatic Linkages

This final graphic incorporates illustrative

programmatic linkages of Technical

Management Processes, which cannot be used

in isolation but must ultimately supportprogram 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 processesthroughout the acqusition life cycle helps to

ensure cost, schedule and performance criteria

are met within acceptable risk levels.


D

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 labeledTechnical Assessment, with a box below labeled Decision Analysis, and a final box labeled Technical

Management.



12/16


Knowledge Review

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

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'?


13/16


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 severalkey 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 particularTechnical 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 expectedoutcomes of each, along with when it has beensuccessfully applied.

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 theright of the flow are Technical Risk Management Procedures, Approved Risk Statements, Risk Mitigation Plans

and Risk Status Reports.



14/16


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 ofthe 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 andillustrative tasks that are needed for a robust,

effective process. They are a template of 'best

practices' that can be tailored and used toperform or oversee Systems Engineering

activities.

Many people played key roles in developingthese course materials. Additionally, someportions 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 gratefullyacknowledged.

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 theright of the flow is Technical Risk Management Procedures, Approved Risk Statements, Risk Mitigation Plans

and Risk Status Reports.


Popup Text:

people

Among others, these primarily included: Dr. Jerry Lake, editor of ISO/IEC 19760 and editorial team memberon 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) Presidentof 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 EngineeringPlans 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.


15/16

NASA Syst em s Engin eer in g Hand book

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 InformationTechnology Association, a Sector of the Electronic Industries Alliance. All Rights Reserved. Reprinted by

Permission.


16/16


Summary

Technical Management Processes provide for

the capture and management of outcomes from

technical efforts including:

Recognition of potential obstacles to

completing technical efforts Redirection of technical work to overcome

obstacles

Response to changing circumstances

Correction of variances and out-of-

compliance conditions 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 ofContents.

introduction to technical management processes

Documents