lOMoAR cPSD| 24222476 lOMoAR cPSD| 24222476

1
UNIT – II - Systems Engineering Processes

Formulation of issues with a case study, Value system design, Functional

analysis, Business Process Reengineering, Quality function deployment, System
synthesis, Approaches for generation of alternatives.

Systems Engineering Management Is…

systems engineering management is accomplished by integrating three major activities:

• Development phasing that controls the design process and provides baselines that
coordinate design efforts,
• A systems engineering process that provides a structure for solving design
problems and tracking requirements flow through the design effort, and
• Life cycle integration that involves customers in the design process and ensures that the
system developed is viable throughout its life.

Each one of these activities is necessary to achieve proper management of a development

effort. Phasing has two major purposes: it controls the design effort and is the major
connection between the technical management effort and the overall acquisition effort. It
controls the design effort by developing design baselines that govern each level of
development. It interfaces with acquisition management by providing key events in the
development process, where design viability can be assessed. The viability of the
baselines developed is a major input for acquisition management Mile- stone (MS)
decisions. As a result, the timing and coordination between technical development
phasing and the acquisition schedule is critical to maintain a healthy acquisition program.

The systems engineering process is the heart of systems engineering management. Its
purpose is to provide a structured but flexible process that transforms requirements into
specifications, architectures, and configuration baselines.
The discipline of this process provides the control and trace- ability to develop solutions
that meet customer needs. The systems engineering process may be repeated one or more
times during any phase of the development process.
 lOMoAR cPSD| 24222476

Development
Phasing

Life Cycle
Baselines Planning
Systems
Engineering
Management

Systems
Life Cycle
Engineering Integrated Integration
Process Teaming

Figure 1-1. Three Activities of Systems Engineering Management

Life cycle integration is necessary to ensure that the design solution is viable throughout
the life of the system. It includes the planning associated with product and process
development, as well as the integration of multiple functional concerns into the design and
engineering process. In this manner, product cycle-times can be reduced, and the need
for redesign and rework substantially reduced.

1.3 DEVELOPMENT PHASING

Development usually progresses through distinct levels or stages:

 Concept level, which produces a system concept description (usually described in a

concept study);

• System level, which produces a system description in performance requirement terms;

and

• Subsystem/Component level, which produces first a set of subsystem and component

product performance descriptions, then a set of corresponding detailed descriptions
of the products’ characteristics, essential for their production.
 lOMoAR cPSD| 24222476

The systems engineering process is applied to each level of system development, one level
at a time, to produce these descriptions commonly called configuration baselines. This
results in a series of configuration baselines, one at each development level. These
baselines become more detailed with each level.

In the Department of Defense (DoD) the configu- ration baselines are called the
functional baseline for the system-level description, the allocated baseline for the
subsystem/ component performance descriptions, and the product baseline for the sub-
system/component detail descriptions. Figure 1-2 shows the basic relationships between
the baselines. The triangles represent baseline control decision points, and are usually
referred to as technical re- views or audits.

Levels of Development Considerations

Significant development at any given level in the system hierarchy should not occur until
the con- figuration baselines at the higher levels are con- sidered complete, stable, and
controlled. Reviews and audits are used to ensure that the baselines are ready for the next
level of development. As will be shown in the next chapter, this review and audit process
also provides the necessary assessment of system maturity, which supports the DoD
Milestone decision process.

THE SYSTEMS ENGINEERING PROCESS

The systems engineering process is a top-down comprehensive, iterative and recursive

problem

Concept Studies

DESIGN DEFINITION
System Definiiton
(Functional Baseline)

DESIGN DEFINITION
Preliminary Design
(Allocated Baseline)

DESIGN DEFINITION Detail Design

(Product Baseline)

Figure 1-2. Development Phasing

 lOMoAR cPSD| 24222476

solving process, applied sequentially through all stages of development, that is used to:

• Transform needs and requirements into a set of system product and process descriptions
(add- ing value and more detail with each level of development),

• Generate information for decision makers, and

• Provide input for the next level of development. As illustrated by Figure 1-3, the
fundamental systems engineering activities are Requirements Analysis, Functional
Analysis and Allocation, and Design Synthesis—all balanced by techniques and tools
collectively called System Analysis and Control. Systems engineering controls are used to
track decisions and requirements, maintain technical baselines, manage interfaces,
manage risks, track cost and schedule, track technical performance, verify requirements
are met, and review/audit the progress.
 lOMoAR cPSD| 24222476

During the systems engineering process architectures are generated to better describe and
under- stand the system. The word “architecture” is used in various contexts in the general
field of engineering. It is used as a general description of how the subsystems join together
to form the system. It can also be a detailed description of an aspect of a system: for
example, the Operational, System, and Technical Architectures used in Command, Con-
trol, Communications, Computers, Intelligence, Surveillance, and Reconnaissance
(C4ISR), and software intensive developments. However, Sys- tems Engineering
Management as developed in DoD recognizes three universally usable architectures that
describe important aspects of the system: functional, physical, and system architectures.
This book will focus on these architectures as necessary components of the systems
engineering process.

The Functional Architecture identifies and structures the allocated functional and
performance requirements. The Physical Architecture depicts the

P
R
O
C
E
S Requirements System Analysis
S Analysis and Control
(Balance)
I Requirements
N Loop
P
U Functional Analysis
T and Allocation

Design
Loop
Verification
Design Synthesis

PROCESS OUTPUT
Figure 1-3. The Systems Engineering Process
 lOMoAR cPSD| 24222476

system product by showing how it is broken down into subsystems and components. The
System Architecture identifies all the products (including enabling products) that are
necessary to support the system and, by implication, the processes necessary for
development, production/construc- tion, deployment, operations, support, disposal,
training, and verification.

Life Cycle Integration

Life cycle integration is achieved through integrated development—that is, concurrent

consideration of all life cycle needs during the development process. DoD policy requires
integrated development, called Integrated Product and Prod- uct Development (IPPD) in
DoD, to be practiced at all levels in the acquisition chain of command as will be explained
in the chapter on IPPD. Con- current consideration of all life cycle needs canbe greatly
enhanced through the use of interdisciplinary teams. These teams are often referred to as
Integrated Product Teams (IPTs).

The objective of an Integrated Product Team is to:

• Produce a design solution that satisfies initially defined requirements, and

• Communicate that design solution clearly, effectively, and in a timely manner.

Multi-functional, integrated teams:

• Place balanced emphasis on product and process development, and

• Require early involvement of all disciplines appropriate to the team task.

Design-level IPT members are chosen to meet the team objectives and generally have
distinctive competence in:

• Technical management (systems engineering),

• Life cycle functional areas (eight primary functions),

 Technical specialty areas, such as safety, risk management, quality, etc., or

• When appropriate, business areas such as finance, cost/budget analysis, and

contracting.

Life Cycle Functions

Life cycle functions are the characteristic actions associated with the system life cycle. As
illustrated by Figure 1-4, they are development, production and construction,deployment
(fielding), operation, support, disposal, training, and verification. These activities cover
the “cradle to grave” life cycle process and are associated with major functional groups
that provide essential support to the life cycle process. These key life
 lOMoAR cPSD| 24222476

cycle functions are commonly referred to as the eight primary functions of systems
engineering.

The customers of the systems engineer perform the life-cycle functions. The system
user’s needs are emphasized because their needs generate the requirement for the system,
but it must be remembered that all of the life-cycle functional areas generate requirements
for the systems engineering process once the user has established the basicneed. Those
that perform the primary functions also provide life-cycle representation in design-
level integrated teams.

Primary Function Definitions

Development includes the activities required to evolve the system from customer needs
to product or process solutions.

Manufacturing/Production/Construction includes the fabrication of engineering test

models and “brass boards,” low rate initial production, full-rate production of systems
and end items, or the construction of large or unique systems or sub- systems.

Deployment (Fielding) includes the activities necessary to initially deliver, transport,

receive, pro- cess, assemble, install, checkout, train, operate, house, store, or field the
system to achieve full operational capability.
 lOMoAR cPSD| 24222476

Disposal Training Verification

Operation Support

8 Primary
Life Cycle
Functions

Development Manufacturing/Production/
Deployment Construction

Figure 1-4. Primary Life Cycle Functions

Operation is the user function and includes activities necessary to satisfy defined
operational objectives and tasks in peacetime and wartime environments.

Support includes the activities necessary to pro- vide operations support, maintenance,
logistics, and material management.

Disposal includes the activities necessary to ensure that the disposal of decommissioned,
destroyed, or irreparable system components meets all applicable regulations and
directives.

Training includes the activities necessary to achieve and maintain the knowledge and
skill levels necessary to efficiently and effectively perform operations and support
functions.

Verification includes the activities necessary to evaluate progress and effectiveness of

evolving system products and processes, and to measure specification compliance.
 lOMoAR cPSD| 24222476

Systems Engineering Considerations

Systems engineering is a standardized, disciplined management process for development

of system solutions that provides a constant approach to system development in an
environment of change and uncertainty. It also provides for simultaneous product and
process development, as well as a common basis for communication.

Systems engineering ensures that the correct technical tasks get done during development
through planning, tracking, and coordinating. Responsibilities of systems engineers
include:

• Development of a total system design solution that balances cost, schedule,

performance, and risk,

• Development and tracking of technicalinformation needed for decision making,

• Verification that technical solutions satisfy customer requirements,

• Development of a system that can be produced economically and supported throughout

the life cycle,

• Development and monitoring of internal and external interface compatibility of the

sys- tem and subsystems using an open systems approach,

• Establishment of baselines and configuration control, and

• Proper focus and structure for system and major sub-system level design IPTs.

1.5 GUIDANCE

• It requires that an Integrated Product and Process approach be taken to design

wherever practicable, and

• It requires that a disciplined systems engineer- ing process be used to translate

operational needs and/or requirements into a system solution.

Tailoring the Process

System engineering is applied during all acquisi- tion and support phases for large- and
small-scale systems, new developments or product improve- ments, and single and
multiple procurements. The process must be tailored for different needs and/or
requirements. Tailoring considerations include system size and complexity, level of
system definition detail, scenarios and missions, con- straints and requirements,
technology base, major risk factors, and organizational best practices and strengths.
 lOMoAR cPSD| 24222476

For example, systems engineering of software should follow the basic systems
engineering approach as presented in this book. However, it must be tailored to
accommodate the software development environment, and the unique progress

This provides a conceptual-level description of systems engineering management. The

specific techniques, nomenclature, and recommended methods are not meant to be
prescriptive. Technical managers must tailor their systems engineering planning to meet
their particular requirements and constraints, environment, technical domain, and
schedule/budget situation.

However, the basic time-proven concepts inherent in the systems engineering approach
must be retained to provide continuity and control. For complex system designs, a full and
documented understanding of what the system must do should precede development of
component performance descriptions, which should precede component detail
descriptions. Though some parts of the sys- tem may be dictated as a constraint or interface,
in general, solving the design problem should start with analyzing the requirements and
determining what the system has to do before physical alternatives are chosen.
Configurations must be controlled and risk must be managed.

Tailoring of this process has to be done carefully to avoid the introduction of substantial
unseen risk and uncertainty. Without the control, coordination, and traceability of systems
engineering, an environment of uncertainty results which will lead to surprises.
Experience has shown that these surprises almost invariably lead to significant impacts
to cost and schedule. Tailored processes that reflect the general conceptual approach of this
book have been developed and adopted by professional societies, academia, industry
associations, government agencies, and major companies.
 lOMoAR cPSD| 24222476

FORMULATION OF ISSUES WITH A CASE STUDIES

Systems engineering principles described in the Systems Engineering Body of Knowledge
(SEBoK) Parts 1-6 are illustrated in Part 7, Systems Engineering Implementation
Examples. These examples describe the application of systems engineering practices,
principles, and concepts in real settings. These systems engineering examples can be used
to improve the practice of systems engineering by illustrating to students and practitioners
the benefits of effective practice and the risks of poor practice. There are two kinds of SE
implementation examples: articles written for the SEBoK and those based on the SE
literature.

List of Examples from the SE Literature

The following examples are included:

 Successful Business Transformation within a Russian Information Technology

Company
 Federal Aviation Administration Next Generation Air Transportation System
 How Lack of Information Sharing Jeopardized the NASA/ESA Cassini/Huygens
Mission to Saturn
 Hubble Space Telescope Case Study
 Global Positioning System Case Study
 Global Positioning System Case Study II
 Medical Radiation Case Study
 FBI Virtual Case File System Case Study
 MSTI Case Study
 Next Generation Medical Infusion Pump Case Study
 Design for Maintainability
 Complex Adaptive Operating System Case Study
 Complex Adaptive Project Management System Case Study
 Complex Adaptive Taxi Service Scheduler Case Study
 Submarine Warfare Federated Tactical Systems Case Study
 Northwest Hydro System
 lOMoAR cPSD| 24222476

Systems engineering (SE) case studies can be characterized in terms of at least two
relevant parameters, viz., their degrees of complexity and engineering difficulty, for
example. Although a so-called quad chart is likely an oversimplification, a 2 x 2 array
can be used to make a first-order characterization, as shown in Figure 1.

Figure 1 Case Study Profiler (SEBoK Original)

The x-axis depicts complicated, the simplest form of complexity, at the low-end on the
left, and complex, representing the range of all higher forms of complexity on the
[Link] y-axis suggests how difficult it might be to engineer (or re-engineer) the system
to be improved, using Conventional (classical or traditional) SE, at the low-end on the
bottom, and Complex SE, representing all more sophisticated forms SE, on the top. This
upper range is intended to cover system of systems (SoS) engineering (SoSE), enterprise
 lOMoAR cPSD| 24222476

systems engineering (ESE), as well as Complex SE (CSE).The distinctions among these

various forms of SE may be explored by visiting other sections of the SEBoK. In
summary, the SEBoK case study editors have placed each case study in one of these four
quadrants to provide readers with a suggested characterization of their case study's
complexity and difficulty. For sake of compactness the following abbreviations have
been used:

 Business Transformation (Successful Business Transformation within a Russian

Information Technology Company)
 NextGen ATC (Federal Aviation Administration Next Generation Air Transportation
System)
 Saturn Mission (How Lack of Information Sharing Jeopardized the NASA/ESA
Cassini/Huygens Mission to Saturn)
 Hubble (Hubble Space Telescope Case Study)
 GPS and GPS II (Global Positioning System Case Study)
 Medical Radiator (Medical Radiation Case Study)
 FBI Case Files (FBI Virtual Case File System Case Study)
 Small Satellite MSTI (MSTI Case Study)
 Medical Infusion Pump (Next Generation Medical Infusion Pump Case Study)
 Incubator Maintainability Design (Design for Maintainability)
 Complex Adaptive Operations (Complex Adaptive Operating System)
 Taxi Scheduler (The Development of the First Real-Time Complex Adaptive Scheduler
for a London Taxi Service)
 Project Management (The Development of a Real-Time Complex Adaptive Project
Management Systems)
 SWFTS MBSE(Submarine Warfare Federated Tactical Systems Case Study)

Value of Case Studies

Case studies have been used for decades in medicine, law, and business to help students
learn fundamentals and to help practitioners improve their practice. A Matrix of
Implementation Examples is used to show the alignment of systems engineering case
 lOMoAR cPSD| 24222476

studies to specific areas of the SEBoK. This matrix is intended to provide linkages
between each implementation example to the discussion of the systems engineering
principles illustrated. The selection of case studies cover a variety of sources, domains,
and geographic locations. Both effective and ineffective use of systems engineering
principles are illustrated.
The number of publicly available systems engineering case studies is growing. Case
studies that highlight the aerospace domain are more prevalent, but there is a growing
number of examples beyond this domain.
The United States Air Force Center for Systems Engineering (AF CSE) has developed a
set of case studies "to facilitate learning by emphasizing the long-term consequences of
the systems engineering/programmatic decisions on cost, schedule, and operational
effectiveness." (USAF Center for Systems Engineering 2011) The AF CSE is using these
cases to enhance SE curriculum. The cases are structured using the Friedman-Sage
framework (Friedman and Sage 2003; Friedman and Sage 2004, 84-96), which
decomposes a case into contractor, government, and shared responsibilities in the
following nine concept areas:

1. Requirements Definition and Management

2. Systems Architecture Development
3. System/Subsystem Design
4. Verification/Validation
5. Risk Management
6. Systems Integration and Interfaces
7. Life Cycle Support
8. Deployment and Post Deployment
9. System and Program Management

This framework forms the basis of the case study analysis carried out by the AF CSE. Two
of these case studies are highlighted in this SEBoK section, the Hubble Space Telescope
Case Study and the Global Positioning System Case Study.
The United States National Aeronautics and Space Administration (NASA) has a catalog
of more than fifty NASA-related case studies (NASA 2011). These case studies include
insights about both program management and systems engineering. Varying in the level of
detail, topics addressed, and source organization, these case studies are used to enhance
 lOMoAR cPSD| 24222476

learning at workshops, training, retreats, and conferences. The use of case studies is viewed
as important by NASA since "organizational learning takes place when knowledge is
shared in usable ways among organizational members. Knowledge is most usable when it
is contextual" (NASA 2011). Case study teaching is a method for sharing contextual
knowledge to enable reapplication of lessons learned. The MSTI Case Study is from this
catalog.
Value of System Design
Systems design is an interdisciplinary engineering activity that enables the realization of
successful systems. Systems design is the process of defining the architecture, product
design, modules, interfaces, and data for a system to satisfy specified requirements.
Systems design could be seen as the application of systems theory to product
development. There is some overlap with the disciplines of systems analysis, systems
architecture and systems engineering.

A system may be denned as an integrated set of components that accomplish a defined

objective. The process of systems design includes defining software and hardware
architecture, components, modules, interfaces, and data to enable a system to satisfy a set
of well-specified operational requirements.
In general, systems design, systems engineering, and systems design engineering all refer
to the same intellectual process of being able to define and model complex interactions
among many components that comprise a system, and being able to implement the
system with proper and effective use of available resources. Systems design focuses on
defining customer needs and required functionality early in the development cycle,
documenting requirements, then proceeding with design synthesis and system validation
while considering the overall problem consisting of:
 Operations
 Performance
 Test and integration
 Manufacturing
 Cost and schedule
 Deployment
 Training and support
 Maintenance
 Disposal
 lOMoAR cPSD| 24222476

Systems design integrates all of the engineering disciplines and specialty groups into a
team effort forming a structured development process that proceeds from concept to
production to operation. Systems design considerations include both the business and
technical requirements of customers with the goal of providing a quality product that
meets the user needs. Successful systems design is dependent upon project management,
that is, being able to control costs, develop timelines, procure resources, and manage
risks.
Information systems design is a related discipline of applied computer systems, which
also incorporates both software and hardware, and often includes networking and
telecommunications, usually in the context of a business or other enterprise. The general
principals of systems design engineering may be applied to information systems design.
In addition, information systems design focuses on data-centric themes such as subjects,
objects, and programs.

If the broader topic of product development "blends the perspective of marketing, design, and
manufacturing into a single approach to product development," then design is the act of taking the
marketing information and creating the design of the product to be manufactured. Systems design
is therefore the process of defining and developing systems to satisfy specified requirements of the
user.

The basic study of system design is the understanding of component parts and their subsequent
interaction with one another.[4]

Until the 1990s, systems design had a crucial and respected role in the data processing industry. In
the 1990s, standardization of hardware and software resulted in the ability to build
modular systems. The increasing importance of software running on generic platforms has
enhanced the discipline of software engineering.

Architectural design[edit]

The architectural design of a system emphasizes the design of the system architecture that
describes the structure, behavior and more views of that system and analysis.

Logical design[edit]

The logical design of a system pertains to an abstract representation of the data flows, inputs and
outputs of the system. This is often conducted via modelling, using an over-abstract (and
 lOMoAR cPSD| 24222476

sometimes graphical) model of the actual system. In the context of systems, designs are included.
Logical design includes entity-relationship diagrams (ER diagrams).

Physical design[edit]

The physical design relates to the actual input and output processes of the system. This is explained
in terms of how data is input into a system, how it is verified/authenticated, how it is processed,
and how it is displayed. In physical design, the following requirements about the system are
decided.

1. Input requirement,
2. Output requirements,
3. Storage requirements,
4. Processing requirements,
5. System control and backup or recovery.

Put another way, the physical portion of system design can generally be broken down into three
sub-tasks:

1. User Interface Design

2. Data Design
3. Process Design

User Interface Design is concerned with how users add information to the system and with how
the system presents information back to them. Data Design is concerned with how the data is
represented and stored within the system. Finally, Process Design is concerned with how data
moves through the system, and with how and where it is validated, secured and/or transformed as
it flows into, through and out of the system. At the end of the system design phase, documentation
describing the three sub-tasks is produced and made available for use in the next phase.

Physical design, in this context, does not refer to the tangible physical design of an information
system. To use an analogy, a personal computer's physical design involves input via a keyboard,
processing within the CPU, and output via a monitor, printer, etc. It would not concern the actual
layout of the tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard
drive, modems, video/graphics cards, USB slots, etc. It involves a detailed design of a user and a
 lOMoAR cPSD| 24222476

product database structure processor and a control processor. The H/S personal specification is
developed for the proposed system.

Functional Analysis and Allocation

Functional Analysis and Allocation is a top-down process of translating system-

level requirements into detailed functional and performance design criteria. The
result of the process is a defined Functional Architecture with allocated system
requirements that are traceable to each system function.

Functional Analysis and Allocation

The Functional Analysis and Allocation bridges the gap between the high-level set of
system requirements and constraints (fromthe Requirements Analysis) and the detailed
set required
 lOMoAR cPSD| 24222476

(in Synthesis) to develop or purchase systems and implement programs. It is an integral

part of both the Requirements Loopand the Design Loop. During this activity, an
integrated Functional Architecture is defined in sufficient depth to support the synthesis of
solutions in terms of people, products, and processes, and to allow identification and
management of attendant risk. It is an iterative process, interacting and reacting to the
ongoing activities in both the Requirements and Design Loops.

The initial step is to identify the lower-level functions required to perform the various system
functions. As this is accomplished, the system requirements are allocated and functional
architecture(s) are developed. These activities track and interact so that as details evolve, they
are continually validated against each other. Should anomalies occur, alternate architectures
and allocations may be carried through early stages of this activity until the optimum approach
becomes apparent. The internal and external functional interfaces are defined as the
architecture matures. The functional architecture(s) and their companion functional
requirements are the input to the Synthesis activity. Completing the Design Loop, the detailed
results of the Synthesis are compared to the candidate architecture(s) and allocated
requirements to help zero in on the optimum approach and to assure that all proposed solutions
meet established requirements.

Decomposition: to lower-level functions is the incoming interface for the Requirements

Loop. The functions identified in the Requirements Analysis are analyzed to define
successively lower-levels of functions that accomplish the higher-level functional
requirements. Alternate lower-level functional solutions covering all anticipated operating
 lOMoAR cPSD| 24222476

modes are proposed and evaluated to determine which provides the best fit to the parent
requirements and the best balance between conflicting ones. The initial decomposition is the
starting point for the development of the functional architecture and the allocation of
requirements to the lower functional levels. Adjustments to the decomposition strategy may
be necessary as details are developed.

Allocation: All requirements of the top-level functions must be allocated for all lower-level
functions. Traceability is an on-going record of the pedigree of requirements imposed on
system and subsystem elements. Because requirements are derived or apportionedamong
several functions, they must be traceable across functional boundaries to parent and child
requirements. Traceability allows the System Engineer to ascertain rapidly what effects any
proposed changes in requirements may have on related requirements at any system level.
The allocated requirements must be defined in measurable terms, contain applicable go/no
go criteria, and be in sufficient detail to be used as design criteria in the subsequent Synthesis
activity.

The four (4) steps that comprise the SE Process are:

Step 1: Requirements Analysis

Requirements Analysis (Step 1) is one of the first activities of the System
Engineering Process and functions somewhat as an interface between the internal
activities and the external sources providing inputs to the process. It examines,
evaluates, and translates the external inputs into a set of functional and performance
requirements that are the basis for the Functional Analysis and Allocation. It links
with the Functional Analysis andAllocation to form the requirements loop of the
System
 lOMoAR cPSD| 24222476

Engineering Process. The goal of requirements analysis is to determine the needs

that make up a system to satisfy an overallneed.

Step 2: System Analysis and Control

System Analysis and Control manages and controls the overall Systems Engineering
Process. This activity identifies the work to be performed and develops the schedules
and costs estimates for the effort. It coordinates all activities andassures that all are
operating from the same set of requirements, agreements, and design iteration. It’s
the center for configuration management throughout the systems engineering
process.
 lOMoAR cPSD| 24222476

System Analysis and Control (see Figure Above) interacts with all the other activities of the
Systems Engineering Process. It evaluates the outputs of the other activities and conducts
independent studies to determine which of the alternate approaches is best suited to the
application. It determines when the results of one activity require the action of another
activity and directs the action to be performed. The initial analyses performed in this activity
are the basis for the Systems Engineering Plan (SEP) and the systems engineering
entries in the Integrated Master Plan (IMP) which define the overall systems engineering
effort. From the SEP and IMP, the Integrated Master Schedule (IMS) is developed to relate
the IMP events and SEP processesto calendar dates.

As the process progresses, trade-off studies and system/cost- effectiveness analyses are
performed in support of the evaluation and selection processes of the other activities. Risk
identification / Risk Mitigation studies are conducted to aid in Risk Management. Analyses
also identify critical parameters to be used in progress measurement. The management
activity directs all operations and also performs Configuration Management (CM),
Interface Management (IM) and data management (DM). It specifies the performance
parameters to be tracked for progress measurement. It conducts reviews and reports
progress.
 lOMoAR cPSD| 24222476

The information from System Analysis and Control is a major part of thesystems engineering
process database that forms the process output. The analysis activity provides the results of
all analyses performed, identifies approaches considered and discarded, and the rationales
usedto reach all conclusions.

Step 3: Functional Analysis Allocation

Step 4: Design Synthesis
Design Synthesis is the process of taking the functionalarchitecture developed in the
Functional Analysis and Allocation step and decomposing those functions into
a Physical Architecture (a set of product, system, and/or software elements) that
satisfy system required functions.
 lOMoAR cPSD| 24222476

Synthesis is the process whereby the Functional Architectures and their associated
requirements are translated into physical architectures and one or more physical sets
of hardware, software, and personnel solutions. It is the output end of the Design
Loop. As the designs are formulated, their characteristics are compared to the
originalrequirements, developed at the beginning of the process, to verify the fit. The
output of this activity is a set of analysis- verified specifications which describe a
balanced, integrated system meeting the requirements, and a database that
documents the process and rationale used to establish these specifications.

The first step of Synthesis is to group the functions into physical architectures. This
high-level structure is used to
 lOMoAR cPSD| 24222476

define system concepts and products and processes, which can be used to implement
the concepts. Growing out of these efforts are the internal and external interfaces. As
concepts are developed they are fed back in the Design Loop to ascertain that
functional requirements have been satisfied. The mature concepts, and product and
process solutions are verified against the original system requirements before they
are released as the Systems Engineering Process product output. Detailed
descriptions ofthe activities of Synthesis are provided below.

Physical architecture is a traditional term. Despite the name, it includes software elements as
well as hardware elements. Among the characteristics of the physical architecture (the primary
outputof Design Synthesis) are the following: [2]

The correlation with functional analysis requires that each physical or software
component meets at least one (or partof one) functional requirement, though any
component canmeet more than one requirement,
The architecture is justified by trade studies and effectiveness
analyses,
A product Work Breakdown Structure (WBS) is developedfrom the physical
architecture,
Metrics are developed to track progress among Key Performance
Parameters (KPP), and
All supporting information is documented in a database.
 lOMoAR cPSD| 24222476

BusinessProcessReengineering(BPR)– Definition,Steps,andExamples
Your company is making great progress. You’re meeting goals easily, but the wayyou meet goals
is where the problem is. Business processes play an important rolein driving goals, but they are not
as efficient as you’d like them to be.

Making changes to the process gets more and more difficult as your business growsbecause of habits
and investments in old methods. But in reality, you cannot improve processes without making
changes. Processes have to be reengineered carefullysince experiments and mistakes bring in a lot
of confusion

Whatisbusinessprocessre-engineering(BPR)?
Business process re-engineering is the radical redesign of business processes toachieve dramatic
improvements in critical aspects like quality, output, cost, service, and speed. Business process
reengineering (BPR) aims at cutting down enterprisecosts and process redundancies on a very huge
scale.
 lOMoAR cPSD| 24222476

1
 lOMoAR cPSD| 24222476

Isbusinessprocessreengineering(BPR)sameasbusinessprocessimprovement(BPI)?
On the surface, BPR sounds a lot like business process improvement (BPI). However, there are
fundamental differences that distinguish the two. BPI might beabout tweaking a few rules here and
there. But reengineering is an unconstrainedapproach to look beyond the defined boundaries and
bring in seismic changes.

While BPI is an incremental setup that focuses on tinkering with the existing processes to improve
them, BPR looks at the broader picture. BPI doesn’t go against the grain. It identifies the process
bottlenecks and recommends changes in specificfunctionalities. The process framework principally
remains the same when BPI is inplay. BPR, on the other hand, rejects the existing rules and often
takes an unconventional route to redo processes from a high-level management perspective.

BPI is like upgrading the exhaust system on your project car. Business Process Reengineering,
BPR is about rethinking the entire way the exhaust is handled.

Fivestepsofbusinessprocessreengineering(BPR)
To keep business process reengineering fair, transparent, and efficient, stakeholders need to get a
better understanding of the key steps involved in it. Although the process can differ from one
organization to another, these steps listedbelow succinctly summarize the process:

Below are the 5 Business Process Re-engineering Steps:

1. Map the current state of your business processes

Gather data from all resources–both software tools and stakeholders.
Understand how the process is performing currently.
 lOMoAR cPSD| 24222476

2. Analyze them and find any process gaps or disconnects

Identify all the errors and delays that hold up a free flow of the process. Make
sure if all details are available in the respective steps for the stakeholders to
make quick decisions.

3. Look for improvement opportunities and validate them

Check if all the steps are absolutely necessary. If a step is there to solely inform
the person, remove the step, and add an automated email trigger.

4. Design a cutting-edge future-state process map

Create a new process that solves all the problems you have identified. Don’t
be afraid to design a totally new process that is sure to work well. Designate
KPIs for every step of the process.

5. Implement future state changes and be mindful of dependencies

Inform every stakeholder of the new process. Only proceed after everyone is
on board and educated about how the new process works. Constantly monitor
the KPIs.

Areal-lifeexampleofBPR
Many companies like Ford Motors, GTE, and Bell Atlantic tried out BPR during the
1990s to reshuffle their operations. The reengineering process they adopted made
a substantial difference to them, dramatically cutting down their expenses and
making them more effective against increasing competition.

The story
An American telecom company that had several departments to address customer
support regarding technical snags, billing, new connection requests, service
termination, etc. Every time a customer had an issue, they were required to call the
 lOMoAR cPSD| 24222476

respective department to get their complaints resolved. The company was doling out
millions of dollars to ensure customer satisfaction, but smaller companies with
minimal resources were threatening their business.

The telecom giant reviewed the situation and concluded that it needed drastic
measures to simplify things–a one-stop solution for all customer queries. It decided
to merge the various departments into one, let go of employees to minimize multiple
handoffs and form a nerve center of customer support to handle all issues.

A few months later, they set up a customer care center in Atlanta and started training
their repair clerks as ‘frontend technical experts’ to do the new, comprehensive job.
The company equipped the team with new software that allowed the support team
to instantly access the customer database and handle almost all kinds of requests.

Now, if a customer called for billing query, they could also have that erratic dial tone
fixed or have a new service request confirmed without having to call another number.
While they were still on the phone, they could also make use of the push-button
phone menu to connect directly with another department to make a query or input
feedback about the call quality.

The redefined customer-contact process enabled the company to achieve new

goals.

 Reorganized the teams and saved cost and cycle time

 Accelerated the information flow, minimized errors, and prevented reworks
 Improved the quality of service calls and enhanced customer satisfaction
 Defined clear ownership of processes within the now-restructured team
 Allowed the team to evaluate their performance based on instant feedback

Here are 6 more real-world business process management

examples.
 lOMoAR cPSD| 24222476

When should you consider BPR

The problem with BPR is that the larger you are, the more expensive it is to
implement. A startup, five months after launch, might undergo a pivot including
business process reengineering that only has minimal costs to execute.

However, once an organization grows, it will have a harder and more expensive time
to completely reengineer its processes. But they are also the ones who are forced to
change due to competition and unexpected marketplace shifts.

But more than being industry-specific, the call for BPR is always based on what an
organization is aiming for. BPR is effective when companies need to break the mold
and turn the tables in order to accomplish ambitious goals. For such measures,
adopting any other process management options will only be rearranging the deck
chairs on the Titanic.

Introduction to Quality Function Deployment

(QFD)
The average consumer today has a multitude of options available to select from
for similar products and services. Most consumers make their selection based
upon a general perception of quality or value. Consumers typically want “the most
bang for their buck”. In order to remain competitive, organizations must
determine what is driving the consumer’s perception of value or quality in a
product or service. They must define which characteristics of the products such
as reliability, styling or performance form the customer’s perception of quality
and value. Many successful organizations gather and integrate the Voice of the
Customer (VOC) into the design and manufacture of their products. They actively
design quality and customer perceived value into their products and services.
These companies are utilizing a structured process to define their customer’s
wants and needs and transforming them into specific product designs and process
plans to produce products that satisfy the customer’s needs. The process or tool
they are using is called Quality Function Deployment (QFD).
 lOMoAR cPSD| 24222476

What is Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a process and set of tools used to
effectively define customer requirements and convert them into detailed
engineering specifications and plans to produce the products that fulfill those
requirements. QFD is used to translate customer requirements (or VOC) into
measureable design targets and drive them from the assembly level down
through the sub-assembly, component and production process levels. QFD
methodology provides a defined set of matrices utilized to facilitate this
progression.
QFD was first developed in Japan by Yoji Akao in the late 1960s while working for
Mitsubishi’s shipyard. It was later adopted by other companies including Toyota
and its supply chain. In the early 1980s, QFD was introduced in the United States
mainly by the big three automotive companies and a few electronics
manufacturers. Acceptance and growth of the use of QFD in the US was initially
rather slow but has since gained popularity and is currently being used in
manufacturing, healthcare and service organizations.
 lOMoAR cPSD| 24222476

Why Implement Quality Function Deployment

(QFD)
Effective communication is one of the most important and impactful aspects of
any organization’s success. QFD methodology effectively communicates customer
needs to multiple business operations throughout the organization including
design, quality, manufacturing, production, marketing and sales. This effective
communication of the Voice of the Customer allows the entire organization to
work together and produce products with high levels of customer perceived
value. There are several additional benefits to using Quality Function
Deployment:
 Customer Focused: QFD methodology places the emphasis on the wants and
needs of the customer, not on what the company may believe the customer
wants. The Voice of the Customer is translated into technical design
specifications. During the QFD process, design specifications are driven down
from machine level to system, sub-system and component level requirements.
Finally, the design specifications are controlled throughout the production
and assembly processes to assure the customer needs are met.
 VOC Competitor Analysis: The QFD “House of Quality” tool allows for direct
comparison of how your design or product stacks up to the competition in
meeting the VOC. This quick analysis can be beneficial in making design
decisions that could place you ahead of the pack.
 Shorter Development Time and Lower Cost: QFD reduces the likelihood of late
design changes by focusing on product features and improvements based on
customer requirements. Effective QFD methodology prevents valuable
project time and resources from being wasted on development of non-value
added features or functions.
 Structure and Documentation: QFD provides a structured method and tools
for recording decisions made and lessons learned during the product
development process. This knowledge base can serve as a historical record
that can be utilized to aid future projects.
Companies must bring new and improved products to market that meet the
customer’s actual wants and needs while reducing development time. QFD
methodology is for organizations committed to listening to the Voice of the
Customer and meeting their needs.
 lOMoAR cPSD| 24222476

How to Implement Quality Function Deployment

(QFD)
The Quality Function Deployment methodology is a 4-phase process that
encompasses activities throughout the product development cycle. A series of
matrices are utilized at each phase to translate the Voice of the Customer to design
requirements for each system, sub-system and component. The four phases of
QFD are:
1. Product Definition: The Product Definition Phase begins with collection of
VOC and translating the customer wants and needs into product
specifications. It may also involve a competitive analysis to evaluate how
effectively the competitor’s product fulfills the customer wants and needs.
The initial design concept is based on the particular product performance
requirements and specifications.
2. Product Development: During the Product Development Phase, the critical
parts and assemblies are identified. The critical product characteristics are
cascaded down and translated to critical or key part and assembly
characteristics or specifications. The functional requirements or
specifications are then defined for each functional level.
 lOMoAR cPSD| 24222476

3. Process Development: During the Process Development Phase, the

manufacturing and assembly processes are designed based on product and
component specifications. The process flow is developed and the critical
process characteristics are identified.
4. Process Quality Control: Prior to production launch, the QFD process
identifies critical part and process characteristics. Process parameters are
determined and appropriate process controls are developed and
implemented. In addition, any inspection and test specifications are
developed. Full production begins upon completion of process capability
studies during the pilot build.
Effective use of QFD requires team participation and discipline inherent in the
practice of QFD, which has proven to be an excellent team-building experience.
Level 1 QFD
The House of Quality is an effective tool used to translate the customer wants and
needs into product or service design characteristics utilizing a relationship
matrix. It is usually the first matrix used in the QFD process. The House of Quality
demonstrates the relationship between the customer wants or “Whats” and the
design parameters or “Hows”. The matrix is data intensive and allows the team to
capture a large amount of information in one place. The matrix earned the name
“House of Quality” due to its structure resembling that of a house. A cross-
functional team possessing thorough knowledge of the product, the Voice of the
Customer and the company’s capabilities, should complete the matrix. The
different sections of the matrix and a brief description of each are listed below:
 “Whats”: This is usually the first section to be completed. This column is where
the VOC, or the wants and needs, of the customer are listed.
 Importance Factor: The team should rate each of the functions based on their
level of importance to the customer. In many cases, a scale of 1 to 5 is used
with 5 representing the highest level of importance.
 “Hows” or Ceiling: Contains the design features and technical requirements
the product will need to align with the VOC.
 Body or Main Room: Within the main body or room of the house of quality the
“Hows” are ranked according to their correlation or effectiveness of fulfilling
each of the “Whats”. The ranking system used is a set of symbols indicating
either a strong, moderate or a weak correlation. A blank box would represent
no correlation or influence on meeting the “What”, or customer requirement.
Each of the symbols represents a numerical value of 0, 1, 3 or 9.
 lOMoAR cPSD| 24222476

 Roof: This matrix is used to indicate how the design requirements interact
with each other. The interrelationships are ratings that range from a strong
positive interaction (++) to a strong negative interaction (–) with a blank box
indicating no interrelationship.
 Competitor Comparison: This section visualizes a comparison of the
competitor’s product in regards to fulfilling the “Whats”. In many cases, a scale
of 1 to 5 is used for the ranking, with 5 representing the highest level of
customer satisfaction. This section should be completed using direct feedback
from customer surveys or other means of data collection.
 Relative Importance: This section contains the results of calculating the total
of the sums of each column when multiplied by the importance factor. The
numerical values are represented as discrete numbers or percentages of the
total. The data is useful for ranking each of the “Hows” and determining where
to allocate the most resources.
 Lower Level / Foundation: This section lists more specific target values for
technical specifications relating to the “Hows” used to satisfy VOC.
Upon completion of the House of Quality, the technical requirements derived from
the VOC can then be deployed to the appropriate teams within the organization
and populated into the Level 2 QFDs for more detailed analysis. This is the first
step in driving the VOC throughout the product or process design process.
Level 2 QFD
The Level 2 QFD matrix is a used during the Design Development Phase. Using the
Level 2 QFD, the team can discover which of the assemblies, systems, sub-systems
and components have the most impact on meeting the product design
requirements and identify key design characteristics. The information produced
from performing a Level 2 QFD is often used as a direct input to the Design
Failure Mode and Effects Analysis (DFMEA) process. Level 2 QFDs may be
developed at the following levels:
 System Level: The technical specifications and functional requirements or
“Hows” identified and prioritized within The House of Quality become the
“Whats” for the system level QFD. They are then evaluated according to which
of the systems or assemblies they impact. Any systems deemed critical would
then progress to a sub-system QFD.
 Sub-system Level: The requirements cascaded down from the system level are
re-defined to align with how the sub-system contributes to the system
meeting its functional requirements. This information then becomes the
“Whats” for the QFD and the components and other possible “Hows” are listed
 lOMoAR cPSD| 24222476

and ranked to determine the critical components. The components deemed

critical would then require progression to a component level QFD.
 Component Level: The component level QFD is extremely helpful in
identifying the key and critical characteristics or features that can be detailed
on the drawings. The key or critical characteristics then flow down into the
Level 3 QFD activities for use in designing the process. For purchased
components, this information is valuable for communicating key and critical
characteristics to suppliers during sourcing negotiations and as an input to
the Production Part Approval Process (PPAP) submission.
Level 3 QFD
The Level 3 QFD is used during the Process Development Phase where we
examine which of the processes or process steps have any correlation to meeting
the component or part specifications. In the Level 3 QFD matrix, the “Whats” are
the component part technical specifications and the “Hows” are the
manufacturing processes or process steps involved in producing the part. The
matrix highlights which of the processes or process steps have the most impact
on meeting the part specifications. This information allows the production and
quality teams to focus on the Critical to Quality (CTQ) processes, which flow down
into the Level 4 QFD for further examination.
Level 4 QFD
The Level 4 QFD is not utilized as often as the previous three. Within the Level 4
QFD matrix, the team should list all the critical processes or process
characteristics in the “Whats” column on the left and then determine the “Hows”
for assuring quality parts are produced and list them across the top of the matrix.
Through ranking of the interactions of the “Whats” and the “Hows”, the team can
determine which controls could be most useful and develop quality targets for
each. This information may also be used for creating Work Instructions,
Inspection Sheets or as an input to Control Plans.
The purpose of Quality Function Deployment is not to replace an organization’s
existing design process but rather support and improve an organization’s design
process. QFD methodology is a systemic, proven means of embedding the Voice of
the Customer into both the design and production process. QFD is a method of
ensuring customer requirements are accurately translated into relevant technical
specifications from product definition to product design, process development
 lOMoAR cPSD| 24222476

and implementation. The fact is that every business, organization and industry
has customers. Meeting the customer’s needs is critical to success. Implementing
QFD methodology can enable you to drive the voice of your customers throughout
your processes to increase your ability to satisfy or even excite your customers.

System synthesis
Synthesis is one of the key automation techniques for improving productivity and developing
efficient implementations from a design specification. Synthesis refers to the creation of a
detailed model or blueprint of the design from an abstract specification, typically a software
model of the design. Synthesis takes different forms during different stages of the design
process. In hardware system design, several synthesis steps automate various parts of the
design process. For instance, physical synthesis automates the placement of transistors and
the routing of interconnects from a gate level description, which itself has been created by
logic synthesis from a register transfer level (RTL) model. The same principle of translation
from higher level model to a lower level model applies to system synthesis.

The third phase in systems engineering is design synthesis. Before design synthesis, all
use cases are ranked according to hierarchy.

Roles:

 Chief engineers, systems engineers

Required tasks:

 Architectural analysis
 lOMoAR cPSD| 24222476

 Architectural design

Artifacts:

 Internal block diagram

 Block definition diagram

The third phase in systems engineering is design synthesis. Before design synthesis, all
use cases are ranked according to hierarchy. During design synthesis, you develop a
physical architecture that can perform the functions that you derived in the functional
analysis phase. You also account for performance constraints as you develop thephysical
architecture.

When you perform system architectural analysis, you merge realized use cases into
integrated architecture analysis project. This task is often based on a trade study pertinent
to the system you intend to design. During architectural analysis, use cases are not
mapped to functional interfaces. Instead, you take a black box approach to examine
functional entities and determine reuse of those entities. After you examine functional
entities, you can allocate the logical architecture into a physical architecture.

You can use a white box activity diagram to allocate use cases to a physical or logical
architecture. Typically, this diagram is derived from a black box activity diagram. The
white box activity diagram is partitioned into swim lanes, which show the hierarchical
structure of the architecture. Then you can move system-level operations into an
appropriate swim lane.

You can use subsystem white box scenarios allow you to decompose system blocks to
the lowest level of functional allocation. At that level, you specify the operations to be
implemented in both the hardware and software of your system. You can derive
subsystem logical interfaces from white box sequence diagrams. The interfaces belong
to the blocks at the lowest level of your system.
 lOMoAR cPSD| 24222476

You can derive subsystem logical interfaces from white box sequence diagrams. The
interfaces belong to the blocks at the lowest level of your system. Then, you can define
subsystem behavior, also known as leaf block behavior for each lowest level of
decomposition in your system. This type of derived behavior is the physical
implementation of decomposed subsystems and is shown in a state chart diagram. Model
execution of leaf block behavior is performed on both the leaf block behavior itself, as well
as the interaction between each of the decomposed subsystems.

Approaches for generation of alternatives.

A problem essentially means an area of decision making.

After understanding the situation thoroughly and realizing the need for action, a
manager may find the problem solving approach useful to devise action programmes.
The problem solving approach involves problem definition and identification of
decision area, generating decision making alternatives, and specifying criteria for
selection, assessing alternatives and the optimal selection, and developing an action
plan for implementation, including a contingency plan.
 lOMoAR cPSD| 24222476

Defining the problem

Problem definition is one of the most crucial steps in the problem solving approach. A
wrong definition of the problem would not only fail to resolve the issues involved but
could also lead to more complicated problems. The following steps have been found
to be useful in defining problems:

Step List all concerns (symptoms), particularly from the point of view of the
1 decision-maker in the situation (i.e., the answer to 'Who?' and 'What?' of the
situational analysis).
Step Diagnose (from the answers to 'How?' and 'Why?') the concerns in order to
2 establish real causes.
Step Establish decision (problem) areas, and prioritize them in order of importance.
3
Step Evaluate - if appropriate decisions are taken in these areas - whether the overall
4 situation would improve particularly from the decision-maker's point of view.

A knowledge of the problems encountered in similar organizations would be helpful in

this exercise. Besides this, holistic as well as logical thinking would significantly help
in understanding the nature of problems, their categorization into long or short term,
and in prioritization.
 lOMoAR cPSD| 24222476

Generating alternatives

Having identified the problem, the decision-maker needs to generate appropriate

alternatives for resolving the problem. An understanding of organizational and external
constraints as well as organizational resources helps in identifying the range of feasible
action alternatives open to the decision-maker. A proper assessment of what is possible
helps them to rule out infeasible options. Sometimes the alternatives for resolving
different problems are obvious. However, more often than not, there could be a real
possibility of generating comprehensive alternatives, which could address more than
one problem area while respecting differing points of view. The next step, after
generating alternatives, would be to rank them, before actually evaluating them. The
decision-maker should check whether the alternatives generated cover the entire range
(collectively and exhaustively) available, and whether each is distinct from the other
(mutually exclusive).

The skills which could help in discovering alternatives would be holistic and logical
thinking to comprehend the situation, as well as creative skills in generating the options
which fit the situation. Knowledge of both the internal and external environments of the
organization and the subject matter pertinent to the problem (human relations, how
scientists can be motivated, etc.) would also help in arriving at better alternatives.

Specifying criteria

The ultimate purpose of developing and specifying criteria is to evaluate alternatives

and select the best one for resolving the problem. Criteria are developed from a proper
understanding of the situation and the inherent goals, objectives and purposes of the
organization and the decision-maker involved in the situation. They would also be
influenced by the goals, objectives and purposes of other individuals, departments and
organizations connected with the situation. Criteria could be economic, social or
personal. For effective use, criteria should be specific and measurable through
quantification or other means. They should also be prioritized to assist proper selection
among alternatives.

The skills needed for improving the ability to specify criteria are basically two:

 holistic skills, for identifying broader aims, goals, objectives and purposes in a
situation, and
 logical reasoning, for deducing the specific criteria and their prioritization from
such higher-order considerations.
 lOMoAR cPSD| 24222476

Evaluation and decision

Alternatives need to be evaluated against the specified criteria in order to resolve the
problem. Also, the outcome of choosing any alternative is not known with certainty.
Usually, any one alternative would not be uniformly superior by all criteria. As such,
prioritization of criteria could help in identifying the best alternative. The decision-
maker might explicitly consider trade-offs between alternatives in order to select the
best. Assessments of alternatives among the criteria need to be made, given partial and
limited information about the possible outcomes of the alternatives. A final check may
yet be needed to see whether adoption of the best assessed option is:

 consistent with the requirements of the situation, bearing in mind the uncertainty
involved,
 implementable, and
 convincing to others involved.

The skills needed for improving this phase would thus be the ability to analyse logically,
the ability to infer implications based on incomplete information and uncertainty, and
the skill to convince others about the decision taken so as to obtain approval or help in
proper implementation, or both.

Developing an action plan

Once the alternatives are developed, an action plan has to be developed. This is
essentially the implementation phase. In this phase, the decision-maker needs to decide
who would do what, where, when, how, etc. The process of arriving at these decisions
is just like the steps involved in the problem solving approach, except that the chosen
alternative becomes an input to this step. This phase would require coordination skills
to properly organize a variety of resources (human, material and fiscal) and develop a
time-phased programme for implementation.

Feedback and contingency planning

For a variety of reasons, the original decision (chosen alternative) may not work well
and the decision-maker may have to be ready with a contingency plan. This implies
devising feedback mechanisms allowing monitoring of the status of the situation,
including results of the action plan. It also implies anticipating the most likely points of
failure and devising appropriate contingency plans to handle the possible failures.
 lOMoAR cPSD| 24222476

The additional skills required in this step would be those of devising control and
feedback mechanisms.