OVERVIEW OF

ESSENTIALS
CHAPTER 2
 2.1 INTRODUCTION
This chapter provides an overview of the essentials
of project management and the systems engineering
process as well as its management. This is followed by
an examination of the essentials of the systems
acquisition life cycle, which itself is correlated with the
systems engineering process. The chapter concludes
with a citation of some of the standards relevant to
project management and systems engineering.
 2.2 PROJECT MANAGEMENT ESSENTIALS

The previous chapter explored some of the elements of project

management, including the roles of the project triumvirate—
the Project Manager (PM), the Chief Systems Engineer (CSE),
and the Project Controller (PC)—and the various
organizational interfaces that affect how they approach and
perform their jobs. Here we continue this exploration, but
focus on the essentials of project management in a more step-
by-step fashion. An overview of the essentials of project
management is depicted in Figure 2.1. This figure shows the
project management triumvirate as a team that oversees the
essential project management functions of planning,
organizing, directing, and monitoring.
 2.3 SYSTEMS ENGINEERING PROCESS
AND MANAGEMENT ESSENTIALS
An overview of the essentials of the systems engineering process and its
management is provided in Figure 2.2. As with the project management chart
of Figure 2.1, the process is initiated by the customer/user with statements of
needs, goals, objectives, and requirements. These feed the development of the
project plan (as depicted as well in Figure 2.1) and, from a systems engineering
perspective, the elements of mission engineering and requirements analysis and
allocation. These feed into the element of functional analysis and allocation,
which forms the basis for the design/synthesis of the system architecture.
Iterations between the synthesis and analysis elements, and the implicit high-
level trade-offs that are required, lead to the definition of a preferred system
architecture. Confirming the validity of this architecture also requires both a
life-cycle costing and an analysis of the risks associated with this architecture.
At this point, the systems engineering team, with the interaction of the project
manager, has developed what is believed to be a cost-effective architectural
design for the system (Box 1).
 2.4 SYSTEM ACQUISITION ESSENTIALS

The matter of project management and systems engineering can also be

approached from the perspective of the customer interested in acquiring a system.
Such a customer needs to do a considerable amount of planning in order to do so,
even if another party is to actually carry out most of the project and the systems
engineering that is part of the project. A typical example might be a government
agency, such as the Department of Transportation (DOT) or the National
Aeronautics and Space Administration (NASA), that wishes to procure systems that
will be responsive to its needs and requirements. In the case of the DOT, through its
subordinate Federal Aviation Administration (FAA), it may need to acquire a new
radar as part of its air traffic control charter. NASA, as an example, may need to
procure a new or upgraded satellite that will carry out a portion of its ‘‘mission to
planet earth’’ initiative. In both cases, a typical plan calls for following a systems
acquisition process set forth by the government, with a major role to be executed by
a large systems contractor.
 2.4.1 SPECIFIC FOCUS FOR SYSTEMS
ACQUISITION AGENT

The acquisition agent for the customer or user of a system must focus on certain activities in
order to assure that the acquisition process is as effective as possible. The following areas of focus
are suggested, with emphasis that depends on the particular phase that is being approached:

 Restatement of  Key schedule

needs/goals/objectives (of milestones
that phase)
 Reiteration of requirements
 Budget limitations and
 Preparation of tasks constraints
statements, statements of  Project reviews
work (SOWs), and work
breakdown structures
(WBSs)
 2.5 SELECTED STANDARDS
Standards that may be applied in the project management or systems
engineering arenas provide guidance to the Project Manager or the Chief
Systems Engineer. Various domain-specific fields (e.g., computers,
communications) provide detailed standards that also suggest to
manufacturers of hardware and software how they may be able to assure
compatibility with each others’ equipment. For example, producers of
software must select the operating system with which their software will
be compatible. In this section, we deal only with standards that are
operative at the level of the overall project management and systems
engineering activities because domain-specific standards would fill many
volumes of text.
2.5.1 MILITARY-STANDARD
-499A
An engineering standard was produced in 1974 that
has supported and guided the systems engineering
process and its management. This ‘‘engineering
management’’ standard served as a touchstone for
systems engineering, especially for systems
developed for the military. The standard was
‘‘developed to assist government and contractor
personnel in defining the system engineering effort
in support of defense acquisition programs.’’
2.5.2 MIL-STD-499B (DRAFT)
This draft standard, entitled ‘‘systems engineering,’’
defines systems engineering as ‘‘an interdisciplinary
approach to evolve and verify an integrated and
optimally balanced set of product and process designs
that satisfy user needs and provide information for
management decision making’’ . Systems engineering
management is cited as ‘‘the management, including the
planning and control for successful, timely completion of
the design, development, and test and evaluation tasks
required in the execution of the systems engineering
process.’’
2.5.3 IEEE P1220
This is a ‘‘Standard for Systems Engineering,’’
as developed by the Institute of Electrical and
Electronics Engineers (IEEE) [2.5]. Examining this
standard in detail shows that it has its roots in
Military-Standard-499B, as described in the
previous section.
The four steps in the systems engineering process have been
expanded to five, which are:

 Requirements analysis  Systems analysis

 Functional analysis  Verification and
 Synthesis validation

The latter two new terms are defined as:

•Verification. A process of determining whether or not the
products of a given phase of development fulfill the requirements
established during the previous phase

•Validation. A process of evaluating a configuration item,

subsystem, or system, to ensure compliance with system
requirements
2.5.4 EIA-632
This standard, with the title ‘‘Processes for
Engineering a System,’’ has been promulgated by
the Electronic Industries Association (EIA) [2.6].
Although an earlier version of this standard (1994)
looked quite a lot like Mil-Std499B, the later
version represented a considerable departure.
Several important points can be made about this
standard.

 First, it was basically  Third, and most

developed through the significant, is the
combined efforts of the EIA
and the International overall structure of the
Council on Systems standard.
Engineering (INCOSE).
 Second, it represents a
shift from systems
engineering to the
processes that are required
in order to engineer any
type of system.
This structure identifies thirteen processes that are critical to the
engineering of systems, with these processes cited under the five
categories listed below:

A. Acquisition and Supply D. Product Realization

1. Supply process 8. Implementation process
2. Acquisition process 9. Transition to use process
B. Technical Management E. Technical Evaluation
3. Planning process 10. Systems analysis process
4. Assessment process 11. Requirements validation
5. Control process process
C. System Design 12. System verification
6. Requirements definition process
process 13. End products validation
7. Solution definition process process
 2.5.5 EIA/IS -731
This is another standard provided by the Electronic Industries
Association (EIA), focusing upon the Systems Engineering
Capability Model (SECM). The standard itself was the result of the
joint efforts of the EIA, INCOSE, and the Enterprise Process
Improvement Collaboration (EPIC). Previously, the Systems
Engineering Capability Maturity Model, developed at the Software
Engineering Institute of Carnegie-Mellon University, had produced
the first such model, based upon the structure of their software model.
This was called the SE-CMM. INCOSE then formulated their version
of such a model, namely, the Systems Engineering Capability Model
(SECAM). The SECM then became the consequence of harmonizing
these two earlier models. The standard itself is divided into two parts.
One is the model itself, and the other is the SECM appraisal method.
2.5.6 SYSTEMS ACQUISITION
DIRECTIVES AND INSTRUCTIONS
The acquirer of large-scale systems, such as those procured
by the U.S. Department of Defense (DoD), has an extremely
complex job. Some of this was alluded to before with respect
to the essentials of the systems acquisition process. The DoD
has issued a directive and instruction that provide policies
and procedures for the acquisition of military systems,
stating that ‘‘acquisition programs shall be managed with the
goal to optimize total system performance and reduce the
cost of ownership.’’ These standards are rather voluminous
but are required reading for those organizations that are
producing systems for the DoD.
2.5.7 KEY SOFTWARE DEVELOPMENT
STANDARDS
Software development is a critical aspect of building and fielding a system and, as
such, is dealt with separately and in detail in Chapter 10. A very wellknown
standard for software development was the Department of Defense standard 2167A
(DoD-Std-2167A) [2.11], which had the title ‘‘Defense System Software Standard.’’
The key phases of software development defined in that standard were

 System requirements  Coding and computer

analysis/design software unit (CSU) testing
 Computer software
 Software requirements component (CSC) integration
analysis and testing
 Preliminary design  Computer software
 Detailed design configuration item (CSCI)
testing
 System integration and testing
 2.5.8 INTERNATIONAL ORGANIZATION
FOR STANDARDIZATION (ISO)
The International Organization for Standardization
(ISO) has been producing standards that apply in
the international arena. Companies that wish to do
business outside the United States are paying a
great deal of attention to such standards,
recognizing that compliance is essential in order to
compete successfully.
 2.5.9 OTHER STANDARDS
Other standards have been promulgated that can be used by the
project management team in order to assist in the design and
development of systems. Military Standard 499B. From this, we see a
variety of military standards and handbooks on important subjects such
as configuration management, environmental analysis, human factors,
manufacturing, quality, reliability, safety, security, and value engineering.
For those who may be operating as acquisition agents for systems,
standards are available that can provide inputs to such activities as
reviews and audits, work breakdown structures (WBSs), statements of
work (SOWs), technical data packages, and specifications.