2ND EDITION

American Society of Engineering Management

Editors: John V. Farr, S. Jimmy Gandhi, and Donald N. Merino

Engineering Management Handbook, 2nd Edition

ISBN: 978-0-9975195-0-1

Published by:
The American Society of Engineering Management
P.O. Box 820
614 Pine Street, Ste. 206B
Rolla, MO 65401

©2016 ASEM. All rights reserved.

Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any
means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior
written permission of the publisher.
ACKNOWLEDGMENTS

The American Society of Engineering Management (ASEM) and the authors and editors of this handbook
would specifically like to thank Dr. Donald N. Merino, Alexander Crombie Humphreys Chaired Professor of
Economics of Engineering Emeritus at Stevens Institute of Technology for his financial contribution that made
the writing of the 2nd edition of the Engineering Management Handbook possible. We would also like to thank
the editors Dr. John V. Farr and Dr. S. Jimmy Gandhi for their time dedicated to the handbook.
The following organization through their generosity supported the final editing and publishing:

CIMCIL Moore Stephens

Management Training & Consultancy, Belgium

Dr. He Jishan
Honorary Member of ASEM, Member of the Chinese Academy of
Engineering, Honorary President for Life of Junefield College of CSU

Old Dominion University

Dept. of ​Engineering Management & Systems Engineering
Norfolk,Virginia

TchI Innovation
Change & Innovation in Technical Environments
Training & Consultancy, Tremelo, Belgium

RS Project Management Consultancy & Training Services

Management Training & Consultancy
Philippines & UAE

URS l CH2M Oak Ridge LLC (UCOR)

Nuclear Services & Engineering​
Oak​ ​Ri​​dge, Tennessee

University of Arkansas
Department of Industrial Engineering
Fayetteville, Arkansas

University of Central Florida

Engineering Leadership & Innovation Institute (eli2)

Washington State University

Engineering and Technology Management
Voiland College of Engineering and Architecture
Online master’s and certificate program - etm.wsu.edu

We would like to also acknowledge Mr. Nakul Sharma, Graduate Student at California State University,
Northridge for helping organize and supporting the updating of the handbook. He did an outstanding job of
managing the development of this handbook. Ms. Lisa Fisher and Kristine Gallo served as the editor and lay-
out, and designed the covers, respectively. Most importantly the editors would like to thank every author who
gave of their time to support ASEM through this handbook.
Lastly, we would like to thank ASEM leadership for continuing to recognize the value of this handbook.

iii
PREFACE
Welcome to the 2nd edition of the Engineering Management Handbook. The first edition was published in
2010. Six years later we have updated much of the original material and added seven new chapters. We hope
to continue to update this handbook with plans to produce case studies as supplemental materials, include new
material, update and expand the existing material, etc.
Engineering managers have traditional been educated to work in the manufacturing sectors but now
must succeed in a world where services based industries account for most economic activity. In today’s global
business environment, engineer managers must use a wide variety of traditional engineering and leadership
skills from the fields of operations research, statistics, management, systems engineering, business, traditional
engineering, etc. There is value to having one source that can summarize many of the methods, processes, and
tools (MPTs) for mainly the practicing engineering manager.
Given this backdrop, we chose to organize this handbook into six sections:
• Historical, Professional, and Academic Perspective,
• Governance and Management of Engineering Core Competencies,
• Quantitative Methods and Modeling,
• Accounting, Financial and Economic Basis,
• Project Management and Systems Engineering, and
• Business Acumen.

There are 23 chapters that have been divided into these areas. Most of the 16 chapters in the first edition
were updated and in some cases totally rewritten. Seven new chapters were added to this edition to include
material addressing patents, intellectual property, multi-generational workers, informatics, quality, innovation,
entrepreneurship, and supply chain. The MPTs presented must be viewed as enablers of solutions and not
just a collection of traditional academic stovepipes. Like this handbook, engineering management (EM) must
evolve to remain relevant in our globally society.
This handbook is intended to serve engineering managers and a wide range of professionals in related disci-
plines to include systems engineers, software engineers, technology management, traditional engineers, etc. In
particular, this handbook should serve engineers at all levels in industry, government, and academia involved in
the management of professionals and technology. Our goals in writing in this handbook include:
• Defining the different MPTs needed by the 21st century engineering manager in support of lifelong
learning,
• Handbook for academics,
• General reference into what is EM,
• Reference for the practicing engineering manager, and
• Advance the understanding of the complexity of method, processes, and tools needed by all engineers and
technologists for our technology centric society.

Hopefully, this 2nd edition will continue to serve as a catalyst for follow-on editions. No one source can
in depth capture all of the MPTs to be a successful engineering manager. However, our goal was simply to
provide one reference that can introduce the readers to certain MPTs. Lifelong learning is the key remaining
relevant into today’s technology driven workforce.

v
 Unfortunately, like many books we had to “freeze” this edition to produce a product with many topics
still not addressed. As we were developing the handbook we realized that there are still many MPT gaps in the
handbook. For example, chapters on the following topics would greatly improve the handbook:
• Performance Appraisals and Metrics,
• Mentoring and Coaching,
• Statistical Quality Control,
• Business Operations of Technical Organization,
• Team Dynamics and Management, and
• Multinational and Multicultural Issues.

John V. Farr S. Jimmy Gandhi Donald N. Merino

California State University,
United States Military Academy Stevens Institute of Technology
Northridge

vi
TABLE OF CONTENTS

ACKNOWLEDGMENTS................................................................................................................................................................ iii

PREFACE...................................................................................................................................................................................... v

Chapter 1: Engineering Management—Past, Present, and Future...................................................................................................... 1

1.1 Introduction..................................................................................................................................................................... 2
1.1.1 Overview of Engineering Management....................................................................................................................... 2
1.1.2 The History of the Engineering Management Discipline............................................................................................. 2
1.1.3 Definition of Engineering Management...................................................................................................................... 4
1.2 Present State of the Engineering and Technology Management................................................................................... 5
1.2.1 The Connection of the Engineering Management Discipline to Other Disciplines...................................................... 5
1.2.2 Engineering Management Related Professional Societies............................................................................................ 6
1.2.3 Engineering Management Related Journals................................................................................................................ 6
1.2.4 Engineering Management Related Conferences......................................................................................................... 9
1.2.5 The Future of the Engineering Management Discipline.............................................................................................. 9
1.3 Emerging Engineering Management Related Trends, Drivers, and Challenges............................................................... 9
1.4 Engineering Management Discipline’s Knowledge Roles............................................................................................. 11
1.5 Engineering Management Discipline Stakeholder Needs............................................................................................. 12
1.6 Conclusions and Summary........................................................................................................................................... 13
1.7 References.................................................................................................................................................................... 14

Chapter 2: Professional Responsibility, Ethics, and Legal Issues........................................................................................................ 17

2.1 Introduction.................................................................................................................................................................. 18
2.1.1 Relevance and Importance........................................................................................................................................ 18
2.1.2 What are Ethics?....................................................................................................................................................... 18
2.1.3 What Constitutes Intellectual Property?.................................................................................................................. 18
2.2 Engineering Code of Conduct...................................................................................................................................... 18
2.2.1 Introduction to the NSPE Ethical Canons................................................................................................................... 18
2.2.2 Safety, Health, and Welfare of the Public.................................................................................................................. 18
2.2.3 Professional Service Only in Qualified Areas............................................................................................................. 19
2.2.4 Objective and Truthful Public Statements................................................................................................................. 19
2.2.5 Faithful Agents for Employers or Clients................................................................................................................... 19
2.2.6 Avoidance of Deceptive Acts..................................................................................................................................... 19
2.2.7 Enhancing the Profession Through Ethical Behavior................................................................................................. 19
2.3 Ethical Decision-Making............................................................................................................................................... 20
2.3.1 Introduction............................................................................................................................................................... 20
2.3.2 Utilitarian Rule........................................................................................................................................................... 20
2.3.3 Moral Rights Rule...................................................................................................................................................... 20
2.3.4 Justice Rule................................................................................................................................................................ 21
2.3.5 Practical Rule............................................................................................................................................................. 21
2.3.6 Implementing the Ethical Principles.......................................................................................................................... 21
2.4 Global Considerations in Ethical Conduct .................................................................................................................... 21
vii
 2.4.1 The Global Environment............................................................................................................................................ 21
2.4.2 Laws and Codes for International Business............................................................................................................... 22
2.4.3 Ethical Decision Making in the Global Environment.................................................................................................. 22
2.5 Protecting Employees Who Raise Ethical Issues........................................................................................................... 22
2.5.1 Introduction............................................................................................................................................................... 22
2.5.2 Creating the Right Culture......................................................................................................................................... 22
2.5.3 Sarbanes-Oxley Act.................................................................................................................................................... 23
2.6 Responsibilities for Intellectual Property...................................................................................................................... 23
2.6.1 Why Protect Intellectual Property?........................................................................................................................... 23
2.6.2 Invention Disclosure Processes.................................................................................................................................. 23
2.6.3 Patents....................................................................................................................................................................... 23
2.6.4 Copyrights.................................................................................................................................................................. 24
2.7 References.................................................................................................................................................................... 24
2.8 Other Sources of Information....................................................................................................................................... 24

Chapter 3: Management Theory and Concepts ................................................................................................................................. 25

3.1 Introduction.................................................................................................................................................................. 26
3.2 Historical Perspective................................................................................................................................................... 26
3.3 Scientific Management................................................................................................................................................. 27
3.4 The Bureaucracy.......................................................................................................................................................... 27
3.4.1 A Critique.................................................................................................................................................................. 28
3.5 Behavioral Approaches................................................................................................................................................. 29
3.6 Quantitative Methods ................................................................................................................................................. 29
3.7 Summary...................................................................................................................................................................... 29
3.8 Attempts at Integration................................................................................................................................................ 30
3.9 What Is Working?........................................................................................................................................................ 30
3.10 Conclusion ................................................................................................................................................................. 31
3.11 References ................................................................................................................................................................. 31

Chapter 4: Managing Knowledge Workers......................................................................................................................................... 33

4.1 Introduction.................................................................................................................................................................. 34
4.1.1 Attempts at Integration............................................................................................................................................. 34
4.1.2 Summary................................................................................................................................................................... 35
4.2 How It All Works Together............................................................................................................................................ 35
4.2.1 The “Integrated” Part................................................................................................................................................ 35
4.2.2 The External Environment ........................................................................................................................................ 36
4.2.3 The Internal Environment ......................................................................................................................................... 37
4.2.4 Management Systems............................................................................................................................................... 37
4.2.5 Organizational Structure............................................................................................................................................ 37
4.2.6 People (Orientation).................................................................................................................................................. 37
4.2.7 The Model................................................................................................................................................................. 38
4.3 The “People” Orientation............................................................................................................................................. 38
4.3.1 Background on Behavioral Approaches..................................................................................................................... 38
4.3.2 McGregor’s Theory X and Theory Y........................................................................................................................... 39
4.3.3 Maslow’s Hierarchy of Human Needs ....................................................................................................................... 39
4.3.4 Herzberg’s Motivators and Hygienes......................................................................................................................... 40
4.3.5 McClelland’s Need to Achieve................................................................................................................................... 41
4.3.6 Pink’s Motivational Concepts.................................................................................................................................... 42
4.3.7 B. F. Skinner’s Operant Conditioning Theory.............................................................................................................. 42
4.3.8 Multiple Generations in the Workplace.................................................................................................................... 43
4.3.9 Summary.................................................................................................................................................................... 44
4.4 People Orientation—Team Management ..................................................................................................................... 44
viii
4.4.1 Likert—An Integrating Principle.................................................................................................................................. 45
4.4.2 Characteristics of High Producing Organizations........................................................................................................45
4.4.3 Characteristics of Low Producing Organizations ........................................................................................................45
4.4.4 Team Management..................................................................................................................................................... 46
4.4.5 Likert’s System IV........................................................................................................................................................ 48
4.4.6 Blake and Mouton’s Managerial Grid......................................................................................................................... 49
4.4.7 The Managerial Grid .................................................................................................................................................. 50
4.5 Summary....................................................................................................................................................................... 51
4.6 References .................................................................................................................................................................... 51

Chapter 5: Types of Intellectual Property .......................................................................................................................................... 53

5.1 Introduction.................................................................................................................................................................. 54
5.2 Copyrights..................................................................................................................................................................... 54
5.3 Trademarks.................................................................................................................................................................... 55
5.4 Trade Secrets................................................................................................................................................................ 56
5.5 Patents.......................................................................................................................................................................... 57
5.6 Obtaining a Patent........................................................................................................................................................ 60
5.7 Design Patents.............................................................................................................................................................. 61
5.8 Plant Patents................................................................................................................................................................. 61
5.9 Utility Patents............................................................................................................................................................... 61
5.10 Major Elements of Patent Application........................................................................................................................ 62

Chapter 6: What is a Patent?.............................................................................................................................................................. 65

6.1 Where Patents are Held................................................................................................................................................ 66
6.2 What are the Laws and Rules in the U.S.?.................................................................................................................... 67
6.3 The Courts.................................................................................................................................................................... 69
6.4 Reading a Patent........................................................................................................................................................... 71
6.4.1 Sample Drawing......................................................................................................................................................... 74
6.4.2 Typical First Two Pages of the Specification.............................................................................................................. 75
6.4.3 Claims Section........................................................................................................................................................... 79
6.5 What Can You Do with a Patent?.................................................................................................................................. 80

Chapter 7: Leading Individuals and Engineering Project Teams ........................................................................................................ 83

7.1 Introduction ................................................................................................................................................................. 84
7.2 The Leader.................................................................................................................................................................... 84
7.3 Leading Individuals....................................................................................................................................................... 85
7.4 Leading Teams.............................................................................................................................................................. 87
7.4.1 Forming..................................................................................................................................................................... 87
7.4.2 Storming.................................................................................................................................................................... 87
7.4.3 Norming..................................................................................................................................................................... 88
7.4.4 Performing................................................................................................................................................................. 88
7.4.5 Adjourning................................................................................................................................................................. 88
7.5 Leading......................................................................................................................................................................... 88
7.6 A Leadership Development Model ............................................................................................................................. 89
7.6.1 Assessment................................................................................................................................................................ 89
7.6.2 Challenge .................................................................................................................................................................. 90
7.6.3 Support...................................................................................................................................................................... 90
7.7 Closing Thoughts.......................................................................................................................................................... 91
7.8 References.................................................................................................................................................................... 91

ix
 Chapter 8: Managing the Multi-Generational Knowledge Based Workforce..................................................................................... 93
8.1 Introduction ................................................................................................................................................................. 94
8.1.1 Overview................................................................................................................................................................... 94
8.2 Generations.................................................................................................................................................................. 94
8.2.1 Baby Boomers............................................................................................................................................................ 95
8.2.2 Generation X (Gen X’ers)........................................................................................................................................... 95
8.2.3 Generation Y (Gen Y)................................................................................................................................................. 96
8.3 Management Impacts................................................................................................................................................... 96
8.3.1 Baby Boomers............................................................................................................................................................ 96
8.3.2 Generation X.............................................................................................................................................................. 96
8.3.3 Generation Y.............................................................................................................................................................. 97
8.4 Management Strategies for Leaders and Followers..................................................................................................... 97
8.5 Optional Content Commitment ................................................................................................................................... 97
8.5.1 Commitment and the Generations............................................................................................................................ 98
8.6 Recommendations for the Management Discipline..................................................................................................... 99
8.6.1 Understanding........................................................................................................................................................... 99
8.6.2 Bias............................................................................................................................................................................ 99
8.7 References.................................................................................................................................................................. 100

Chapter 9: Operations Research....................................................................................................................................................... 105

9.1 Introduction to Operations Research Modeling......................................................................................................... 106
9.1.1 Importance of Operations Research for Engineering Managers.............................................................................. 106
9.1.2 History of Operations Research............................................................................................................................... 106
9.1.3 Operations Research Methodology......................................................................................................................... 106
9.2 Deterministic Models ................................................................................................................................................ 108
9.2.1 Linear Programming................................................................................................................................................ 108
9.2.2 Basic Problem Formulation...................................................................................................................................... 108
9.2.3 Sensitivity Analysis.................................................................................................................................................. 110
9.2.4 Duality Theory......................................................................................................................................................... 111
9.2.5 Applications............................................................................................................................................................. 112
9.2.6 Integer Programming............................................................................................................................................... 112
9.2.7 Solution Techniques................................................................................................................................................. 113
9.2.8 Binary and Auxiliary Binary Variable........................................................................................................................ 113
9.2.9 Applications............................................................................................................................................................. 113
9.3 Non-Linear Programming........................................................................................................................................... 113
9.3.1 Solution Techniques................................................................................................................................................. 113
9.3.2 Separable Programming.......................................................................................................................................... 113
9.3.3 Applications ............................................................................................................................................................ 114
9.4 Dynamic Programming............................................................................................................................................... 114
9.4.1 Solution Techniques................................................................................................................................................. 114
9.4.2 Applications............................................................................................................................................................. 114
9.5 Stochastic Models ...................................................................................................................................................... 115
9.5.1 Markov Chains......................................................................................................................................................... 115
9.5.2 Discrete-time Markov Chains.................................................................................................................................. 115
9.5.3 Semi-Markov Processes........................................................................................................................................... 117
9.5.4 Queuing Theory....................................................................................................................................................... 118
9.5.5 Stability of Queues................................................................................................................................................119
9.5.6 Little’s Rule............................................................................................................................................................119
9.5.7 Single-Server Single-Channel Queues....................................................................................................................119
9.5.8 Multiple-Server Queues........................................................................................................................................121
9.6 Advanced and Other Topics......................................................................................................................................121
9.6.1 Meta-heuristics......................................................................................................................................................121
x
9.6.2 Advanced Stochastic Models................................................................................................................................122
9.6.3 Brownian Motion...................................................................................................................................................124
9.6.4 Discrete-Event Simulation.....................................................................................................................................125
9.7 Big Data and Operations Research...........................................................................................................................126
9.7.1 An Introduction to Big Data and the Internet of Things........................................................................................126
9.7.2 Big Data Value Chain..............................................................................................................................................127
9.7.3 Big Data Case Studies............................................................................................................................................128
9.8 References ............................................................................................................................................................... 128

Chapter 10: Simulation............................................................................................................................................................131

10.1 Introduction ............................................................................................................................................................. 132
10.1.1 Importance of Simulation..................................................................................................................................... 132
10.1.2 Key Terms of Simulation ...................................................................................................................................... 133
10.1.3 Simulation Theory for Engineers.......................................................................................................................... 134
10.1.4 Simulation Applications for Engineers.................................................................................................................. 134
10.1.5 Simulation Engineering......................................................................................................................................... 135
10.1.6 Modeling and Simulation as a Discipline............................................................................................................... 135
10.2 Simulation Theory.................................................................................................................................................... 136
10.2.1 Mathematical Foundations................................................................................................................................... 136
10.2.2 Computer Science Foundations............................................................................................................................ 138
10.2.3 Discrete Event Simulation..................................................................................................................................... 139
10.2.4 Data Analysis........................................................................................................................................................ 141
10.2.5 Monte-Carlo Simulation and Continuous Simulation........................................................................................... 141
10.3 Simulation Applications .......................................................................................................................................... 143
10.3.1 Simulation as an Engineering Method.................................................................................................................. 143
10.3.2 Simulation with ARENA........................................................................................................................................ 145
10.3.3 Agent-based Modeling......................................................................................................................................... 146
10.3.4 Simulation and Systems Engineering Models........................................................................................................ 148
10.4 References................................................................................................................................................................ 149

Chapter 11: Decision Analysis.................................................................................................................................................151

11.1 Introduction ............................................................................................................................................................. 152
11.1.1 What is Decision Analysis?................................................................................................................................... 152
11.1.2 Why Use Decision Analysis?................................................................................................................................. 152
11.1.3 When Do You Use Decision Analysis?................................................................................................................... 152
11.1.4 Who Uses Decision Analysis? .............................................................................................................................. 152
11.2 Decision Processes................................................................................................................................................... 153
11.2.1 Challenges ............................................................................................................................................................ 153
11.2.2 Analytical Process.................................................................................................................................................. 153
11.2.3 Decision Conference Process................................................................................................................................. 153
11.2.4 Dialog Decision Process......................................................................................................................................... 154
11.2.5 Advantages and Disadvantages of Decision Processes.......................................................................................... 155
11.3 Decision Elements.................................................................................................................................................... 155
11.3.1 Values and Outcomes ........................................................................................................................................... 155
11.3.2 Uncertainty ........................................................................................................................................................... 155
11.3.3 Decisions ............................................................................................................................................................... 156
11.4 Decision Modeling—Illustrative Product Development Example............................................................................. 156
11.4.1 Basic Influence Diagram ....................................................................................................................................... 156
11.4.2 Basic Decision Tree ............................................................................................................................................... 156
11.4.3 Basic Risk Profile.................................................................................................................................................... 157
11.4.4 Value of a Test ....................................................................................................................................................... 158
11.4.5 Value of Imperfect Information about Market Success ....................................................................................... 159
xi
 11.4.6 Value of Perfect Information About Market Success ............................................................................................ 160
11.4.7 Value of Control..................................................................................................................................................... 161
11.4.8 Sensitivity Analysis................................................................................................................................................ 161
11.4.9 Comparison of Influence Diagrams and Decision Trees ........................................................................................ 161
11.5 Single Attribute Utility.............................................................................................................................................. 161
11.5.1 Utility .................................................................................................................................................................... 161
11.5.2 Risk Preference ..................................................................................................................................................... 162
11.5.3 Utility with Decision Trees .................................................................................................................................... 162
11.6 Multiple Objective Decision Analysis (MODA).......................................................................................................... 162
11.6.1 Additive Value Model............................................................................................................................................ 162
11.6.2 Value Functions .................................................................................................................................................... 163
11.6.3 Swing Weights ...................................................................................................................................................... 163
11.6.4 Swing Weight Matrix ............................................................................................................................................. 164
11.6.5 Multiple Objective Decision Analysis with Decision Trees .................................................................................... 165
11.7 Role of Engineering Manager................................................................................................................................... 165
11.8 Advanced and Other Topics...................................................................................................................................... 166
11.9 References................................................................................................................................................................ 166

Chapter 12: Multi-Criteria Analysis.........................................................................................................................................169

12.1 Introduction to Multi-Criteria Analysis .................................................................................................................... 170
12.1.1 Background............................................................................................................................................................ 170
12.1.2 Overview of Multi-Criteria Analysis....................................................................................................................... 170
12.1.3 Relevance of MCA to Engineering Management................................................................................................... 170
12.2 Analytic Hierarchy Process....................................................................................................................................... 171
12.2.1 Overview of Analytic Hierarchy Process................................................................................................................ 171
12.2.2 The AHP Process................................................................................................................................................... 171
12.2.3 Advantages and Limitations of AHP as a Multi-Criteria Tool................................................................................. 174
12.2.4 Conclusion............................................................................................................................................................. 175
12.3 Analytic Network Process......................................................................................................................................... 175
12.3.1 Overview of Analytic Network Process.................................................................................................................. 175
12.3.1.1 ANP Structure..................................................................................................................................................... 175
12.3.2 The ANP Process.................................................................................................................................................... 175
12.3.4 Benefits and Limitations of ANP as a Multi-Criteria Tool ...................................................................................... 178
12.3.3 Conclusion ............................................................................................................................................................ 178
12.4 Multi-Attribute Analysis (MAA)................................................................................................................................ 179
12.4.1 Overview............................................................................................................................................................... 179
12.4.2 The Multi-Attribute Analysis (MAA) Process......................................................................................................... 179
12.4.3 Utility Theory (Utility Analysis).............................................................................................................................. 180
12.4.4 Conclusion............................................................................................................................................................. 181
12.5 References................................................................................................................................................................ 182

Chapter 13: Engineering Informatics – State of the Art and Future Trends............................................................................183
13.1 Introduction ............................................................................................................................................................. 184
13.2 Overview of Engineering Information Integration.................................................................................................... 187
13.2.1 IIIE-A New Discipline of Industrial Information Integration.................................................................................... 187
13.2.2 Engineering Integration......................................................................................................................................... 188
13.3 Enabling Technologies.............................................................................................................................................. 191
13.3.1 Business Process Management............................................................................................................................. 191
13.3.2 Information Integration and Interoperability........................................................................................................ 194
13.3.3 Enterprise Architecture and Enterprise Application Integration........................................................................... 195
13.3.4 Service-oriented Architecture (SOA)..................................................................................................................... 196
13.4 Summary and Challenges......................................................................................................................................... 196
xii 13.5 References................................................................................................................................................................ 197
Chapter 14: Basic Accounting and Finance.............................................................................................................................199
14.1 Introduction ............................................................................................................................................................. 200
14.1.1 Importance of Accounting to Engineers................................................................................................................ 200
14.1.2 Accounting and Engineering Economics................................................................................................................ 200
14.1.3 What is Accounting? ............................................................................................................................................. 200
14.1.4 Users of Accounting Information .......................................................................................................................... 200
14.2 Basic Accounting....................................................................................................................................................... 200
14.2.1 Introduction........................................................................................................................................................... 200
14.2.2 Financial Accounting.............................................................................................................................................. 201
14.2.3 Transactions........................................................................................................................................................... 202
14.2.4 Financial Condition................................................................................................................................................ 202
14.2.5 Financial Statement Terminology.......................................................................................................................... 202
14.2.6 Financial Performance........................................................................................................................................... 204
14.2.7 Accounting Equation.............................................................................................................................................. 204
14.3 Income Statement.................................................................................................................................................... 204
14.3.1 Introduction........................................................................................................................................................... 204
14.3.2 The Income Statement......................................................................................................................................... 205
14.4 Balance Sheet........................................................................................................................................................... 206
14.4.1 Introduction............................................................................................................................................................ 206
14.4.2 The Balance Sheet................................................................................................................................................. 206
14.5 Stockholder’s (Owner’s) Equity................................................................................................................................ 209
14.5.1 Introduction........................................................................................................................................................... 209
14.5.2 Stockholder’s Equity.............................................................................................................................................. 210
14.5.3 Paid-In Capital ....................................................................................................................................................... 210
14.5.4 Retained Earnings.................................................................................................................................................. 211
14.5.5 Example of Retained Earnings .............................................................................................................................. 211
14.6 Cash Flow Statement................................................................................................................................................ 211
14.6.1 Introduction........................................................................................................................................................... 211
14.6.2 The Cash Flow Statement...................................................................................................................................... 212
14.6.3 Example of Cash Flow Statement.......................................................................................................................... 213
14.7 Depreciation............................................................................................................................................................. 214
14.7.1 Introduction........................................................................................................................................................... 214
14.7.2 Depreciation Terminology..................................................................................................................................... 214
14.7.3 Depreciation Methods........................................................................................................................................... 215
14.7.4 Gains and Losses from the Disposal of Assets....................................................................................................... 217
14.8 After Tax Analysis...................................................................................................................................................... 217
14.8.1 Introduction .......................................................................................................................................................... 217
14.8.2 After Tax Analysis and Cash Flow.......................................................................................................................... 218
14.8.3 After Tax Cash Flow from Depreciation Charges.................................................................................................... 218
14.8.4 After Tax Cash Flow from Investment Tax Credit .................................................................................................. 218
14.8.5 After Tax Cash Flows from Loans........................................................................................................................... 219
14.9 Accounting Process................................................................................................................................................... 219
14.9.1 Introduction........................................................................................................................................................... 219
14.9.2 The Accounting Process......................................................................................................................................... 219
14.9.3 Double Entry Accounting....................................................................................................................................... 219
14.10 Financial and Managerial Accounting..................................................................................................................... 220
14.10.1 Introduction......................................................................................................................................................... 220
14.10.2 Breakeven Analysis.............................................................................................................................................. 220
14.10.3 Contribution Margin............................................................................................................................................ 221
14.10.4 Contribution Margin Ratio................................................................................................................................... 221
14.10.5 Breakeven Sales in Dollars................................................................................................................................... 221
14.10.6 Target Net Profit.................................................................................................................................................. 222
xiii
 14.10.7 Sales to Achieve Target Return on Sales.............................................................................................................. 222
14.10.8 Degree of Operating Leverage............................................................................................................................. 222
14.11 Advanced and Other Topics.................................................................................................................................... 222
14.12 Summary................................................................................................................................................................ 223
14.13 References.............................................................................................................................................................. 223

Chapter 15: Engineering Economics........................................................................................................................................225

15.1 Capital Expenditures................................................................................................................................................. 226
15.1.1 Importance of Capital............................................................................................................................................ 226
15.1.2 Capital Selection Process....................................................................................................................................... 226
15.1.3 Minimum Attractive Rate of Return ...................................................................................................................... 226
15.2 Mathematics of Finance........................................................................................................................................... 226
15.2.1 Rates of Return....................................................................................................................................................... 226
15.2.2 Simple and Compound Interest ............................................................................................................................ 226
15.2.3 Effective Interest Rates.......................................................................................................................................... 229
15.2.4 Compounding and Discounting............................................................................................................................. 230
15.2.5 Cash Flow Patterns................................................................................................................................................ 230
15.2.6 Loan Programs and Personal Finance..................................................................................................................... 232
15.3 Figures of Merit (FoM).............................................................................................................................................. 232
15.3.1 Present Worth ....................................................................................................................................................... 232
15.3.2 Annual Worth........................................................................................................................................................ 233
15.3.3 Future Worth......................................................................................................................................................... 233
15.3.4 Capital Recovery.................................................................................................................................................... 234
15.3.5 Capitalized Cost..................................................................................................................................................... 234
15.3.6 Internal Rate of Return (IRR) ................................................................................................................................ 235
15.3.7 Benefit Cost Analysis (BCA)................................................................................................................................... 235
15.4 Retirements and Replacements................................................................................................................................ 237
15.4.1 Types of Retirement and Replacement Problems................................................................................................. 237
15.4.2 Total Costs and Economic Life................................................................................................................................ 237
15.4.3 Capitalized Costs.................................................................................................................................................... 238
15.4.4 Operating and Maintenance Costs........................................................................................................................ 239
15.5 Inflation.................................................................................................................................................................... 240
15.5.1 Causes of Inflation.................................................................................................................................................. 240
15.5.2 Types of Inflation................................................................................................................................................... 240
15.5.3 Using Price Indices................................................................................................................................................. 241
15.5.4 Inflation and MARR............................................................................................................................................... 241
15.5.5 Cash Flows and Inflation........................................................................................................................................ 241
15.5.6 Common Problems Relating to Inflation................................................................................................................ 242
15.6 After Tax Analysis...................................................................................................................................................... 242
15.6.1 Net Cash Flow from Operating Activities .............................................................................................................. 243
15.6.2 Net Cash Flow from Capital Related Line............................................................................................................... 243
15.6.3 After Tax Cash Flow from Depreciation Charges.................................................................................................... 244
15.6.4 After Tax Cash Flow from Investment Tax Credit .................................................................................................. 244
15.6.5 After Tax Cash Flows from Loans........................................................................................................................... 244
15.6.6 After Tax Cash Flow for Salvage/Disposal of Assets .............................................................................................. 245
15.6.7 Total Cash Flow Discounted................................................................................................................................... 245
15.6.8 ATA Example.......................................................................................................................................................... 245
15.7 Decision Analysis..................................................................................................................................................... 248
15.7.1 Types of Problems................................................................................................................................................. 248
15.7.2 Choosing Among Alternatives Using ATA............................................................................................................... 248
15.7.3 Decision Model...................................................................................................................................................... 249
15.8 References................................................................................................................................................................ 250
xiv
Chapter 16: Project Management’s Role in Engineering Management..................................................................................251
16.1 Introduction.............................................................................................................................................................. 252
16.2 Project Management................................................................................................................................................ 252
16.2.1 Initiating Processes................................................................................................................................................ 254
16.2.2 Planning Processes................................................................................................................................................ 255
16.2.3 Executing Processes............................................................................................................................................... 259
16.2.4 Monitoring and Controlling Processes.................................................................................................................. 259
16.2.5 Closing Processes................................................................................................................................................... 263
16.3 Summary.................................................................................................................................................................. 263
16.4 References................................................................................................................................................................ 264

Chapter 17: Systems Engineering............................................................................................................................................265

17.1 Introduction.............................................................................................................................................................. 266
17.1.1 What is Systems Engineering?............................................................................................................................... 266
17.1.2 Why Did Systems Engineering Originate?............................................................................................................. 267
17.1.3 The Systems Engineering Lifecycle....................................................................................................................... 268
17.1.4 The Role of Systems Modeling and Systems Simulation........................................................................................ 270
17.2 Stakeholder Requirements Definition...................................................................................................................... 270
17.2.1 Use Cases and Scenarios....................................................................................................................................... 271
17.2.2 Performance Criteria............................................................................................................................................. 271
17.2.3 Inputs and Outputs................................................................................................................................................ 271
17.2.4 Conclusions............................................................................................................................................................ 272
17.3 Requirements Analysis............................................................................................................................................. 273
17.4 Architectural Design................................................................................................................................................. 274
17.5 Implementation........................................................................................................................................................ 274
17.5.1 Intermediate Specifications................................................................................................................................... 275
17.5.2 Peer Reviews......................................................................................................................................................... 275
17.5.3 Quality Inspections................................................................................................................................................ 276
17.6 Integration................................................................................................................................................................ 276
17.6.1 Big Bang Approach................................................................................................................................................ 276
17.6.2 Bottom-Up Approach............................................................................................................................................ 277
17.7 Verification............................................................................................................................................................... 277
17.7.1 Inspection.............................................................................................................................................................. 277
17.7.2 Demonstration....................................................................................................................................................... 278
17.7.3 Analysis.................................................................................................................................................................. 278
17.7.4 Test........................................................................................................................................................................ 278
17.8 Transition.................................................................................................................................................................. 278
17.9 Validation.................................................................................................................................................................. 278
17.10 Operation and Maintenance.................................................................................................................................. 278
17.11 Disposal.................................................................................................................................................................. 279
17.12 Conclusions............................................................................................................................................................. 279
17.13 References.............................................................................................................................................................. 280

Chapter 18: Systems Thinking.................................................................................................................................................281

18.1 Introduction ............................................................................................................................................................. 282
18.1.1 Changing Domain for Engineering Managers........................................................................................................ 283
18.1.2 Systems Thinking Challenges for Engineering Managers....................................................................................... 285
18.1.3 Implications of Systems Thinking (ST) for Engineering Management (EM)........................................................... 286
18.2 Overview of Systems Thinking ................................................................................................................................. 287
18.2.1 Nature of Systems Thinking................................................................................................................................... 287
18.2.2 Hard and Soft Systems Thinking............................................................................................................................ 288
18.2.3 Roles for Systems Thinking in Engineering Management....................................................................................... 290
xv
 18.3 Philosophy and Central Concepts for Systems Thinking .......................................................................................... 291
18.3.1 Philosophical Basis for Systems Thinking............................................................................................................... 291
18.3.2 Foundation Principles for Systems Thinking.......................................................................................................... 292
18.4.3 Using the Foundations for Systems Thinking......................................................................................................... 299
18.4 Systems Thinking: Dealing with Complexity ............................................................................................................ 300
18.4.1 Nature and Challenge of Complexity for Engineering Managers........................................................................... 300
18.5 Systems Thinking Capacity for Engineering Managers............................................................................................. 301
18.6 Systems Thinking as a Responsive Strategy for Dealing with Complexity................................................................. 303
18.7 Methods and Tools for Systems Thinking ................................................................................................................ 304
18.7.1 Role of Tools for Systems Thinking........................................................................................................................ 305
18.7.2 Taxonomy of Tools for Systems Thinking............................................................................................................... 308
18.7.3 Selected Tools for Systems Thinking...................................................................................................................... 309
18.8 Systems Thinking Implications for Engineering Management ................................................................................ 309
18.8.1 Using Systems Thinking in Engineering Management........................................................................................... 309
18.8.2 Limitations for Systems Thinking........................................................................................................................... 310
18.9 Conclusion ............................................................................................................................................................... 311
18.10 References ............................................................................................................................................................. 313

Chapter 19: Risk Management................................................................................................................................................317

19.1 Introduction ............................................................................................................................................................. 318
19.1.1 What are Risks, Hazards and Accidents?............................................................................................................... 318
19.1.2 Why is Managing Risk Important for Engineering Managers?............................................................................... 319
19.1.3 What is Risk Management?................................................................................................................................... 319
19.1.4 What Are the Basic Activities in Risk Management?............................................................................................. 320
19.2 Scenario Identification ............................................................................................................................................. 321
19.2.1 Identify Desired Scenarios..................................................................................................................................... 322
19.2.2 Identify Risk Scenarios........................................................................................................................................... 322
19.2.3 Characterize Risk Scenarios Via Causalities and Correlation................................................................................. 322
19.3 Consequence and Likelihood Estimation.................................................................................................................. 326
19.3.1 Consequence Estimation....................................................................................................................................... 326
19.3.2 Likelihood Estimation............................................................................................................................................ 326
19.4 Risk Ranking.............................................................................................................................................................. 328
19.4.1 Risk Ranking Using Consequence and Likelihood.................................................................................................. 328
19.4.2 Risk Ranking Using Other Properties..................................................................................................................... 328
19.5 Generation and Tradeoff of Mitigation Alternatives................................................................................................. 329
19.5.1 Mitigation Strategies............................................................................................................................................. 329
19.5.2 As Low As Reasonably Practicable......................................................................................................................... 330
19.5.3 Comparative Analysis for Tradeoffs....................................................................................................................... 331
19.5.3 Analytic Hierarchy Process (AHP).......................................................................................................................... 332
19.6 Potential Problem Analysis....................................................................................................................................... 333
19.6.1 Stone-in-the-Pond Analogy................................................................................................................................... 333
19.7 Implementation, Documentation and Monitoring................................................................................................... 333
19.7.1 The Need for Documentation and Monitoring...................................................................................................... 333
19.7.2 Lessons Learned for the Engineering Managers.................................................................................................... 333
19.8 Advanced and Other Topics..................................................................................................................................... 334
19.9 References................................................................................................................................................................ 335

Chapter 20: What is Quality Management?............................................................................................................................337

20.1 A Definition of Quality Management........................................................................................................................ 338
20.2 A Brief History of Quality Management................................................................................................................... 338
20.3 Quality Planning....................................................................................................................................................... 345
20.4 Quality Assurance..................................................................................................................................................... 348
xvi
20.5 Quality Control......................................................................................................................................................... 349
20.6 Quality Improvement............................................................................................................................................... 349
20.7 The Seven Quality Tools............................................................................................................................................ 352
20.7.1 Process Maps......................................................................................................................................................... 352
20.7.2 Checklists............................................................................................................................................................... 353
20.7.3 Histograms............................................................................................................................................................. 353
20.7.4 Pareto Charts......................................................................................................................................................... 353
20.7.5 Ishikawa Diagrams................................................................................................................................................. 355
20.7.6 Control Charts........................................................................................................................................................ 356
20.7.7 Scatter Charts........................................................................................................................................................ 357
20.8 Quality Leadership and Teams.................................................................................................................................. 358
20.9 References................................................................................................................................................................ 359

Chapter 21: Strategic Management........................................................................................................................................361

21.1 Introduction ............................................................................................................................................................. 362
21.1.1 Importance of Strategic Management to Engineering Managers......................................................................... 362
21.1.2 What is Strategic Management? .......................................................................................................................... 362
21.2 Strategic Management Process................................................................................................................................ 363
21.2.1 Introduction............................................................................................................................................................ 363
21.2.2 Core of the Strategic Management Process.......................................................................................................... 363
21.2.3 Strategic Management Process Functions............................................................................................................. 365
21.2.4 Setting Strategic Intent Through Strategic Planning.............................................................................................. 366
21.2.5 Deploying the Strategic Intent............................................................................................................................... 368
21.2.6 Setting Strategy Through Implementation Planning.............................................................................................. 369
21.2.7 Deploying Resources............................................................................................................................................. 371
21.2.8 Executing the Strategy........................................................................................................................................... 372
21.2.9 Deploying Results.................................................................................................................................................. 374
21.2.10 Reviewing Performance Through Performance Evaluation................................................................................. 376
21.2.11 Deploying Learnings............................................................................................................................................ 376
21.3 Bibliography and References.................................................................................................................................... 377

Chapter 22: Innovation and Entrepreneurship .......................................................................................................................379

22.1 Introduction.............................................................................................................................................................. 380
22.2 Entrepreneurial Mindset and Qualities of an Entrepreneur..................................................................................... 380
22.2.1 So What Exactly is Entrepreneurial Mindset?........................................................................................................ 380
22.3 Functions of an Entrepreneur................................................................................................................................... 381
22.4 Intrapreneur............................................................................................................................................................. 382
22.4.1 Differences between Entrepreneur and Intrapreneur........................................................................................... 382
22.5 Innovation and Its Importance in Entrepreneurship................................................................................................ 383
22.6 Innovation: The Likely Cause of Successful Sustainable Businesses........................................................................ 385
22.6.1 Types of Innovation............................................................................................................................................... 385
22.6.2 Factors Affecting Innovation.................................................................................................................................. 386
22.7 Metrics to Measure Innovation................................................................................................................................ 386
22.8 The Design Thinking Process.................................................................................................................................... 387
22.9 The Entrepreneurial Process.................................................................................................................................... 388
22.10 How Can Small/Medium Enterprises (SMEs) Incorporate Innovation.................................................................... 389
22.11 Continuous Improvement....................................................................................................................................... 390
22.12 Competitive Advantages for the U.S....................................................................................................................... 391
22.13 References ............................................................................................................................................................. 391

Chapter 23: Supply Chain Management for Engineering Managers ......................................................................................393

23.1 Introduction.............................................................................................................................................................. 394
xvii
 23.1.1 Definition of a Supply Chain.................................................................................................................................. 394
23.2 Supply Chain Management...................................................................................................................................... 395
23.3 Lean Supply Chain.................................................................................................................................................... 396
23.4 Importance of Supply Chain Management for Industries........................................................................................ 397
23.5 Supply Chain Management Risks.............................................................................................................................. 398
23.5.1 Definition............................................................................................................................................................... 398
23.5.2 Risks....................................................................................................................................................................... 398
23.6 Role of Engineers in the Supply Chain...................................................................................................................... 401
23.7 Application of Supply Chain in Industries................................................................................................................. 401
23.7.1 Examples................................................................................................................................................................ 401
23.7.2 Best Practices in Supply Chain Management......................................................................................................... 402
23.8 Innovation in Supply Chain Management................................................................................................................ 403
23.9 Conclusion................................................................................................................................................................ 403
23.10 References.............................................................................................................................................................. 404

Author Biographies .................................................................................................................................................................407

xviii
LIST OF FIGURES

Chapter 1
Figure 1.1. Management and Educational Trends That Have Affected the EM Field..........................................................4
Figure 1.2. Engineering Management as the Bridge Between Engineering and Management..........................................6
Figure 1.3. Challenges for the Technical Organization and Engineering Manager............................................................11
Figure 1.4. Five Knowledge Roles of the EM Discipline....................................................................................................12

Chapter 2
Figure 2.1. Organizational Stakeholders...........................................................................................................................20

Chapter 4
Figure 4.1. The Five Elements of the Integrated Management Model.............................................................................36
Figure 4.2. Maslow’s Hierarchy of Human Needs............................................................................................................39
Figure 4.3. Traditional Organization Structure.................................................................................................................47
Figure 4.4. Team-Based Organization..............................................................................................................................48
Figure 4.5. Likert’s Basic Model.......................................................................................................................................49
Figure 4.6. The Managerial Grid......................................................................................................................................50

Chapter 6
Figure 6.1. Page of U.S. Patent.........................................................................................................................................71
Figure 6.2. Sample Drawing for a U.S. Patent...................................................................................................................74
Figure 6.3. Typical Pages of the Specifications.................................................................................................................76
Figure 6.4. Claims Section of a Patent..............................................................................................................................79

Chapter 9
Figure 9.1. Operations Research Methodology..............................................................................................................107
Figure 9.2. Basic Linear Programming Formulations......................................................................................................108
Figure 9.3. Feasible Region and Iso-Objective Lines.......................................................................................................109
Figure 9.4. Corner Point Optimal Solution......................................................................................................................110
Figure 9.5. Dual Linear Programs for Basic Linear Programs..........................................................................................112
Figure 9.6. Piecewise Approximation to a Non-linear Function.....................................................................................114
Figure 9.7. Big Data Value Chain.....................................................................................................................................127

Chapter 10
Figure 10.1. Modeling and Simulation as a Discipline....................................................................................................135
Figure 10.2. Visualization of the Principle of the Inverse Transform Method/Algorithm...............................................138
Figure 10.3. Time Advance in Discrete Event Simulation...............................................................................................140
Figure 10.4. Phases for Conducting a Study as Recommended in the NATO COBP........................................................144
Figure 10.5. Executing an ARENA Model.........................................................................................................................145
Figure 10.6. Architectural Frame Addressing Main Agent Characteristics......................................................................147
Figure 10.7. Agents, Environment, and Societies...........................................................................................................148

xix
 Chapter 11
Figure 11.1. Decision Conference...................................................................................................................................154
Figure 11.2. Dialog Decision Process..............................................................................................................................154
Figure 11.3. Basic Influence Diagram.............................................................................................................................156
Figure 11.4. Basic Decision Tree.....................................................................................................................................157
Figure 11.5. Basic Cumulative Risk Profile......................................................................................................................157
Figure 11.6. Influence Diagram with Test.......................................................................................................................158
Figure 11.7. Decision Tree with Test...............................................................................................................................158
Figure 11.8. Influence Diagram with Test and Market Survey........................................................................................159
Figure 11.9. Probability Calculations..............................................................................................................................159
Figure 11.10. Decision Tree with Test and Market Survey..............................................................................................160
Figure 11.11. Three Utility Functions.............................................................................................................................162
Figure 11.12. Four Types of Value Functions..................................................................................................................163

Chapter 12
Figure 12.1. A Simple Three-Level AHP Model...............................................................................................................172
Figure 12.2. Simple ANP Network for a Decision-Making Process.................................................................................176
Figure 12.3. The Shape of a Hypothetical Utility Function.............................................................................................181

Chapter 13
Figure 13.1. The Scope of Engineering Informatics Proposed........................................................................................186
Figure 13.2. IIIE Discipline History..................................................................................................................................187
Figure 13.3. Discipline Structure of IIIE..........................................................................................................................188
Figure 13.4. The Relationship Between Engineering Integration, Manufacturing Integration, Customer Integration, and
Enterprise Integration....................................................................................................................................................189

Chapter 14
Figure 14.1. Concept of Breakeven Analysis..................................................................................................................221

Chapter 15
Figure 15.1. Shorthand Notation Used for Engineering Economics...............................................................................230
Figure 15.2. Cash Flow Notation ...................................................................................................................................231
Figure 15.3. Constant Payments - Interest and Principle Combined (amortization).......................................................232
Figure 15.4. Cash Flow Diagram for Purchasing an Automatic Welder .........................................................................233
Figure 15.5. Capitalized Cost.........................................................................................................................................234
Figure 15.6. Generalization of an R&R Problem.............................................................................................................238
Figure 10.6. General Decision Model to Determine Economic Feasibility......................................................................249

Chapter 16
Figure 16.1 Project Management Related to Engineering Management.......................................................................252
Figure 16.2. Project Management Process Groups........................................................................................................253
Figure 16.3. Work Breakdown Structure........................................................................................................................257
Figure 16.4. Linear Responsibility Chart.........................................................................................................................258
Figure 16.5. Project Performance Target - Scope, Time, and Cost..................................................................................260
Figure 16.6. Earned Value Graph....................................................................................................................................261

Chapter 17
Figure 17.1. Mind Map of SE Key Concepts....................................................................................................................266
Figure 17.2. U.S. Army Corporal Sounding Rocket..........................................................................................................267
Figure 17.3. Hall’s Book on Systems Engineering............................................................................................................268
Figure 17.4. Common Systems Engineering Lifecycles in Use Today..............................................................................268
Figure 17.5. ISO/IEC 15288 Systems Engineering Processes..........................................................................................269

xx
Figure 17.6. Sample Hybrid SUV Operational Use Case..................................................................................................271
Figure 17.7. Input/Output Matrix...................................................................................................................................272
Figure 17.8. DoDAF Architecting Guidance....................................................................................................................275
Figure 17.9. Big Bang Approach to Integration...............................................................................................................276
Figure 17.10. Bottom-Up Approach to Integration.........................................................................................................277

Chapter 18
Figure 18.1. Using the Foundations of Systems..............................................................................................................290
Figure 18.2. Philosophic Level Spectrum........................................................................................................................292
Figure 18.3. Observation Through Intervention Activities Loop.....................................................................................305
Figure 18.4. Making Sense of “Methodologies,” “Methods” and “Tools”......................................................................306
Figure 18.5. Levels of Integrated Systems Thinking Application.....................................................................................312

Chapter 19
Figure 19.1. Schematic of the Activities in the Risk Management Framework..............................................................321
Figure 19.2. Simplified FTA Showing How Causalities of Risk Scenarios Can Be Represented by
Events and Gate Symbols.............................................................................................................................................326
Figure 19.3. Estimating Probabilities of Damages..........................................................................................................327
Figure 19.4. Example of Risk Matrix to Rank Risk Scenarios Based on Consequence and Likelihood ...........................331

Chapter 20
Figure 20.1. Process Map Example.................................................................................................................................352
Figure 20.2. Histogram Examples...................................................................................................................................353
Figure 20.3. Pareto Chart................................................................................................................................................354
Figure 20.4. Ishikawa Diagram........................................................................................................................................355
Figure 20.5. Control Chart 1............................................................................................................................................356
Figure 20.6. Control Chart 2...........................................................................................................................................357
Figure 20.7. Scatter Chart Reflecting Positive Correlations.............................................................................................357
Figure 20.8. Scatter Chart Reflecting Negative Correlations...........................................................................................358

Chapter 21
Figure 21.1. Strategic Management Process..................................................................................................................363
Figure 21.2. Goals, Objectives, Strategies......................................................................................................................365

Chapter 22
Figure 22.1. Functions of an Entrepreneur.......................................................................................................................................381
Figure 22.2. Innovation Process - Six Stages....................................................................................................................................384
Figure 22.3. Design Thinking Process.................................................................................................................................................387
Figure 22.4. Stages of Entrepreneurial Process...............................................................................................................................389
Figure. 22.5. Continuous Improvement Process.............................................................................................................................390

Chapter 23
Figure 23.1. Supply Chain Organizational Pyramid.........................................................................................................................394
Figure 23.2. SIPOC Diagram................................................................................................................................................................396
Figure 23.3. Attributes of Lean Supply Chain...................................................................................................................................397
Figure 23.4. Definitions of Supply Chain Agility by Executives ...................................................................................................400
Figure 23.5. Agile Supply Chain...........................................................................................................................................................401

xxi
xxii
LIST OF TABLES
Chapter 1
Table 1.1. ABET accredited and ASEE EM Related Programs..............................................................................................3
Table 1.2. Common Characteristics of EM Definitions........................................................................................................5
Table 1.3. Professional Societies Associated with the EM Discipline..................................................................................7
Table 1.4. Journals Associated with the Engineering Management Discipline...................................................................8
Table 1.5. Professional Conferences Associated with the EM Discipline............................................................................9
Table 1.6. EM Discipline’s Stakeholder Needs..................................................................................................................13

Chapter 4
Table 4.1. Overlapping Concepts......................................................................................................................................44
Table 4.2. Theory of Motivating Knowledge Workers.......................................................................................................51

Chapter 8
Table 8.1. Influence of Commitment on Workplace Impact.............................................................................................98

Chapter 11
Table 11.1. Advantages and Disadvantages of Decision Processes................................................................................155
Table 11.2. Elements of the Swing Weight Matrix..........................................................................................................164
Table 11.3. Topics Referenced to Standard Texts in the Field........................................................................................167

Chapter 12
Table 12.1. Scale for Pair-wise Comparison Using AHP1.................................................................................................172
Table 12.2. Pair-Wise Comparison Between Attributes..................................................................................................172
Table 12.3. Pair-Wise Comparison Between Attributes with Totals................................................................................173
Table 12.4. Normalized Values of Pair-Wise Comparison Between Attributes...............................................................173
Table 12.5. Pair-Wise Comparison Between Brands with respect to Maintenance Cost................................................176
Table 12.6. ANP Supermatrix—Un-weighted.................................................................................................................177
Table 12.7. ANP Supermatrix—Weighted.......................................................................................................................177
Table 12.8. ANP Limit Supermatrix.................................................................................................................................177
Table 12.9. Final Alternative Values based on ANP........................................................................................................178

Chapter 14
Table 14.1. Comparison of Types of Business Entities....................................................................................................201
Table 14.2. A Typical Income Statement.........................................................................................................................206
Table 14.3. Assets, Liabilities and Equity for ASEM LLC..................................................................................................208
Table 14.4. Balance Sheet for ASEM LLC.........................................................................................................................209
Table 14.5. Two Sources of Equity Capital for Shareholders Equity...............................................................................210
Table 14.6. Stockholder’s Equity Based Upon Two Sources of Equity Capital................................................................210
Table 14.7. ASEM Corporation Stockholder’s Equity Statement on December 31, 200X..............................................211
Table 14.8. Stockholder’s Equity Statement for ASEM Corp as of December 31...........................................................211
Table 14.9. Cash Flow Statement....................................................................................................................................212
Table 14.10. Revenue and Expenses for Merino Realty.................................................................................................213
Table 14.11. Cash Flow from Merino Reality Income Statement...................................................................................214
xxiii
 Table 14.12. SL Depreciation Example...........................................................................................................................216
Table 14.13. MACRS Depreciation Example...................................................................................................................217
Table 14.14. Loan Balance / Amortization Table.............................................................................................................219
Table 14.15. T-account Method of Recording Debits and Credits..................................................................................220
Table 14.16. Location of Typical Items That are Posted..................................................................................................220

Chapter 15
Table 15.1. Demonstration of Simple vs. Compound Interest.......................................................................................228
Table 15.2. Effects of Compounding Period...................................................................................................................230
Table 15.3. Salvage Value and O&M Costs by Year.........................................................................................................238
Table 15.4. Capitalized Costs by Year..............................................................................................................................239
Table 15.5. EVAC Calculation for O&M Costs..................................................................................................................239
Table 15.6. Total EVAC for an O&M Example..................................................................................................................239
Table 15.7. Net Cash Flow from Operating Activities.....................................................................................................243
Table 15.8. Net Cash Flows from Capital Related Activities............................................................................................243
Table 15.9. Loan Balance / Amortization Table...............................................................................................................245
Table 15.10. Total Cash Flow (Operating and Capital) Discounted.................................................................................245
Table 15.11. Economic Data for the ATA Problem..........................................................................................................246
Table 15.12. ATA Loan Amortization Table......................................................................................................................246
Table 15.13. Depreciation Expenses for the ATA Problem..............................................................................................247
Table 15.14. Net Cash Flows from Operating Income....................................................................................................247

Chapter 16
Table 16.1. Project Management Tools and Techniques.................................................................................................257

Chapter 17
Table 17.1. Input/Output Matrix....................................................................................................................................272
Table 17.2. Requirements Traceability Matrix................................................................................................................273

Chapter 18
Table 18.1. Multiple Perspectives of Systems Thinking..................................................................................................288
Table 18.2. Distinctions between Hard and Soft Systems Thinking................................................................................289
Table 18.3. Guiding Systems Principles for Systems Thinking.........................................................................................293
Table 18.4. Systems Thinking Characteristics.................................................................................................................302
Table 18.5. System-based Methodologies.....................................................................................................................307
Table 18.6. Jackson’s “Creative Holism” Taxonomy........................................................................................................307

Chapter 19
Table 19.1. PHA Worksheet............................................................................................................................................323
Table 19.2. JSA Worksheet..............................................................................................................................................324
Table 19.3. FEMA Worksheet..........................................................................................................................................325
Table 19.4. Basic FTA Symbols........................................................................................................................................325
Table 19.5. Example of Risk Matrix to Rank Risk Scenarios Based on Consequence and Likelihood .............................328
Table 19.6. Exploratory Questions That Can Be Used to Describe Risk Scenarios..........................................................329
Table 19.7. Risk Analysis Tools .......................................................................................................................................332
Table 19.8. References for Advanced Risk Analysis .......................................................................................................335

Chapter 20
Table 20.1. Pareto Results Example ...............................................................................................................................355

Chapter 23
Table 23.1. Varying Definitions of Supply Chain as Provided by Different Authors........................................................394
Table 23.2. Outsourcing Risks.........................................................................................................................................399

xxiv
 Engineering Management: Past, Present, and Future

1
Engineering Management—Past, Present,
and Future

Timothy G. Kotnour
University of Central Florida

John V. Farr
United States Military Academy

1
Engineering Management Handbook

1.1 Introduction
1.1.1 Overview of Engineering Management
With the globalization of the manufacturing base, outsourcing of many technical services, the efficien-
cies derived from advances in information technology (and the subsequent decrease in mid-management
positions), and the shifting of our economy to be service-based, the roles of the technical organization
and the engineering manager have dramatically changed. The 21st century technical organization must be
concerned with:
1. Maintaining an agile, high quality, and profitable business base of products or services in a fluctuating
economy,
2. Hiring, managing, and retaining a highly qualified and trained staff of engineers, scientists, and tech-
nicians in a rapidly changing technological environment, and
3. Demonstrating a high level of capability maturity.

Engineers often enter the job market not as traditional engineers but as project managers, technical sales,
and lead systems engineers (especially within the defense and information management arenas) involved
with conceiving, defining, architecting, designing, integrating, marketing, and testing complex and
multi-functional information technology centric systems (Abel, 2005). Within five years, for most engi-
neers this has become their primary job function. Combined with the fact that the modern engineering
enterprise is now characterized by geographically dispersed and multi-cultural organizations, engineering
management (EM) is more relevant than ever. Because of the blurring of boundaries between technical
and management roles, engineers must continue to redefine their roles to remain relevant in the modern
economy. Like all technical professions, EM has evolved dramatically because of the information age and
the interdisciplinary nature and complexity of modern systems.

1.1.2 The History of the Engineering Management Discipline

According to Kocaoglu (1984), EM as a formal degree has existed since the mid 1940s. However, we
know that courses in business and management aspects of engineering have been taught since the 1900s.
For example, Stevens Institute of Technology founded a Department of Business Engineering in 1902
with the aim to teach students “to become efficient managers” (Clark, 2000). The Massachusetts Institute
of Technology offered a degree in industrial management around 1913 (Kocaoglu, 1989). Several EM or
EM-type programs grew out of the post World War II industrial expansion to include the University of
Washington (1947) and Michigan Technological University (1949). The major growth occurred in the
1960s and 1970s. The first EM department was founded at the University of Missouri – Rolla (UMR
now known as Missouri University of Science and Technology) in 1967. UMR also awarded the first
PhD in EM in 1984 (Murray and Raper, 1997). The UMR contribution is further discussed by Bab-
cock (2000). Today, there are probably in excess of 85 universities offering undergraduate and graduate
degrees in programs named EM in the United Sates. Most EM programs can be categorized as being
embedded within an industrial engineering department/program or combined with systems engineering
departments/programs. Few undergraduate education EM programs exist because industrial engineering
departments have been reluctant to embrace the profession at the undergraduate level. If you include the
international programs, those embedded as concentrations within industrial engineering degrees, con-
centrations within MBAs, and hybrid programs such as engineering administration, systems EM, there
are probably hundreds of universities that offer an EM-type degree. Given the recent downturn in MBAs
degrees awarded in many programs (Triad Business Journal, 2004), EM degrees/programs/department
should continue to grow.
At the undergraduate level, there has also been growth in terms of related classes, minors, and certif-
icates that are embedded within traditional degrees. However, the number of undergraduate EM pro-
grams has seen little growth. As shown in Table 1.1, the ABET website lists 11 accredited undergraduate
programs in the US and five internationally with the word “management” in the program name and only

2
 Engineering Management: Past, Present, and Future

one has been accredited in the US for the first time in the last five years. Only five use the term “engi-
neering management” exclusively for the program name. A recent American Society for Engineering
Education (ASEE) publication on domestic engineering programs lists 23 EM undergraduate programs,
which also are summarized in Table 1.1.

Table 1.1. ABET accredited and ASEE EM Related Programs (from Kaufman et al., 2015)

ABET Accredited EM Programs* ASEE Listed EM Undergrad Programs

Domestic University of Arizona
University of Arizona** (2003) Arizona State University
Clarkson University*** (2009) California State, Long Beach
University of Connecticut (1978) California State, Northridge
Missouri University of Science and Technology ** University of California – Santa Cruz
(1979) Christian Brothers University
North Dakota State University (1971) The College of New Jersey
Oklahoma State University (1936) Colorado School of Mines
University of the Pacific**(2003) Gonzaga University
Rensselaer Polytechnic Institute (1978) Illinois Institute of Technology
South Dakota School of Mines and Technology Mercer University
(1991) Miami University
Stevens Institute of Technology** (1990) Missouri University of Science and Tech.
United States Military Academy** (1985) University of North Carolina - Charlotte
University of the Pacific
International NYU Polytechnic School of Engineering
Arab Academy for Science and Technology and University of Portland
Maritime Transport (2009) Southern Methodist University
Istanbul Technical University (2009) St. Mary’s University
Kuwait University (2006) Stevens Institute of Technology
Universidad Autonoma de San Luis Potosi (2012) University of Tennessee - Chattanooga
University of Sharjah (2010) United States Military Academy
University of Vermont

* Programs with “Management” in the name, ** “Engineering Management” programs, *** “Engineering and Management”
programs. The number in parenthesis under ABET accredited programs is the year that the program was first accredited.

The EM profession mirrors both trends in business and education. Early business engineering focused
on the civil and mechanical engineering disciplines. As shown in Figure 1.1, with the work Taylor (1911)
contributed to the early focus on manufacturing that dominated the discipline through the 1990s. Rapid
advances in information technology in the 1980s and organizational changes in all engineering practices
led to decline in the specialist engineer and a rise in the generalist engineer. To reflect the shift from man-
ufacturing to turn-key systems integrators in a global economic environment many EM programs are now
aligned with systems engineering programs (Farr and Buede, 2003).

3
Engineering Management Handbook

Figure 1.1. Management and Educational Trends That Have Affected the EM Field

(Shewart, 1924)
Quality Control,
Department of

(Taylor, 1911)
Stevens Int of

(Jacko, 2005)
(Clark, 2000)

Management
Engineering,

Tech (1902)

Principles of
Engineering

Statistical
Industrial

Scientific
Business

(1909)
1900-1925

(ORMS, 2005)
Operations
Research
(1937)
1925-1950

Thinking Emery
and (Trist,
Systems

1960)

1950-1975
Six Sigma (1986)

ISO 9000 (1991)

(Motorola, 2005)
(Deming, 1982)

Champy, 1993)
Reengineering
(Hammer and
Schon, 1978)
Organization,

Management
Total Quality
(Argyris and

(ISO, 2005)
Learning

Process

1975-2000

1.1.3 Definition of Engineering Management

In the literature you find few definitions of EM. Table 1.2 summarizes some the key characteristics com-
mon to all definitions of EM. We like the definition presented by Omurtag (1988) or Farr (2008).
The EM field has its roots in the traditional engineering and management disciplines (Waters, 1994).
This evolution has helped define the field. In the next section, we discuss the “knowledge” basis for the
disciplines.

4
 Engineering Management: Past, Present, and Future

Table 1.2. Common Characteristics of EM Definitions

Definition Reference
Engineering management is designing, operating, and continuously improving Omurtag (1988)
purposeful systems of people, machines, money, time, information, and energy
by integrating engineering and management knowledge, techniques, and skills to
achieve desired goals in technological enterprise through concern for the envi-
ronment, quality, and ethics.
The engineering manager is distinguished from other managers because he or Babcock and Morse
she posses both the ability to apply engineering principles and a skill in organizing (2002)
and directing people and projects. He or she is uniquely qualified for two types
of jobs; the management of technical functions (such as design or production) in
almost any enterprise, or the management of broader functions (such as market-
ing or top management) in a high technology enterprise.
Engineering management is the discipline addressed to making and implementing IEEE (1990) and
decisions for strategic and operational leadership in current and emerging tech- Kocaoglu (1991)
nologies and their impacts on interrelated systems.
Engineering management is the art and science of planning, organizing, allocating American Society
resources, and directing and controlling activities which have a technological for Engineering
component. Management
In today’s global business environment, engineer managers integrate hardware, Farr (2011)
software, people, processes and interfaces to produce economically viable and
innovative products and services while ensuring that all pieces of the enterprise
are working together.

1.2 Present State of the Engineering and Technology Management Field

The present state of the EM field is described by understanding four elements: (a) the contributing
disciplines, (b) professional societies, (c) relevant journals, and (d) professional conferences. Through the
analysis of the present state conclusions for the future direction are offered: (1) the integration of the three
core contributing disciplines of EM needs to continue and (2) the integration of the diverse set of profes-
sional societies, journals, and conferences that needs to take place.

1.2.1 The Connection of the Engineering Management Discipline to Other

Disciplines
To understand the EM discipline we need to understand how the discipline relates to other disciplines.
In reviewing the history of EM, we assert that EM has evolved from the engineering and management
disciplines. EM is the bridge between the engineering and management disciplines. Consistent with the
definitions provided in the previous section, we view engineering manager as the “bridge” (Hicks, Ute-
ly, and Westbrook, 1999) between the traditional disciplines of science/engineering and management
(see Figure 1.2).

5
Engineering Management Handbook

Figure 1.2. Engineering Management as the Bridge Between Engineering and Management

Engineering Engineering MBA

Management

Traditional Management Management Management of General

Engineering Within an Across Technology Management
Discipline Engineering Engineering
Discipline Disciplines

In reviewing the journals, professional societies, and conferences, five disciplines contribute to defin-
ing three different perspectives on the EM field. The five discipline groups are as follows:
1. Engineering disciplines. The core engineering disciplines in which the discipline focuses on the engi-
neering and design process unique to a domain (e.g., civil, traditional industrial, mechanical, electrical).
2. Discipline specific engineering management. The EM discipline that focuses on the management
process for a specific engineering discipline (e.g., management of the civil engineering process, man-
agement of the industrial engineering process).
3. Generalist engineering management. The EM discipline that focuses on the fundamental EM pro-
cess across many engineering disciplines.
4. Management of technology. The business or management discipline that focuses on managing the
creation, development, and use of technology (Badaway, 1998).
5. General management. The management discipline that focuses on the management of any organization.

Given these descriptions, three perspectives to EM are: (1) discipline specific EM, (2) generalist EM,
and (3) management of technology. Industrial engineering could be considered to be part of the overlap
between engineering and EM in Figure 1.2. As will become evident in the rest of this section, the EM
field continues to support this view. The EM discipline emerges from five unique sets of journals, profes-
sional societies, and conferences to provide three unique perspectives to the field.

1.2.2 Engineering Management Related Professional Societies

Consistent with the three perspectives of the EM field we categorize the different professional societies re-
lated to EM. As has been completed before (Sarchet and Baker, 1995), Table 1.3 summarizes the different
professional societies. In addition to the three perspectives to EM we have added three other categories
for completeness: (1) disciplines associated with processes and tools used by the engineering manager,
(2) general management, and (3) engineering education. Engineering disciplines and societies associated
with the Accreditation Board for Engineering and Technology (ABET) were used as the source for the
engineering programs. All of the engineering discipline professional societies are not included, just the
societies with an associated EM group or division. We share these professional societies to help the reader
understand the different avenues for actively participating and contributing to the profession. The EM
discipline is supported with six groups of professional journals.

1.2.3 Engineering Management Related Journals

Consistent with the three perspectives of the EM field, we review and categorize the different journals re-
lated to EM. Table 1.4 summarizes the journals related to EM. For completeness, in addition to the three
perspectives to EM we have added three other categories: (1) disciplines associated with processes and
tools used by the engineering manager, (2) general management and (3) engineering education. We share
these related journals to help the reader understand where to go to for knowledge and to contribute to the
knowledge of the profession. This list is not meant to be an exhaustive list. The EM discipline emerges
from six unique sets of journals.
6
 Engineering Management: Past, Present, and Future

Table 1.3. Professional Societies Associated with the EM Discipline

Group Professional Societies

Engineering • American Society of Civil Engineers (ASCE) (www.asce.org)

Management within an • IEEE Engineering Management Society (IEEE EMS) (www.ieee.org/ems)
Engineering Discipline • Institute of Industrial Engineers (IIE) (www.iienet.org)
• Institute of Industrial Engineers (IIE)- Society for Engineering & Management
Systems (SEMS) (www.iienet.org)
• Society of Petroleum Engineers (SPE) (www.spe.org)
• Society of Manufacturing Engineers (SME) (www.sme.org)
• American Society for Mechanical Engineering (ASME) (asme.org)

Disciplines Associated • Association for the Advancement of Cost Engineering (AACE) (aacei.org)
with Processes and • International Council of Systems Engineering (INCOSE) (www.incose.org)
Tools Used by the • Project Management Institute (PMI) (www.pmi.org)
Engineering Manager

Engineering • American Society for Engineering Management (ASEM) (www.asem.org)

Management Across • Canadian Society for Engineering Management (CSEM)
Disciplines (www.csem-scgi.ca/index.html)

Management of • International Association for Management of Technology (IAMOT)

Technology (www.iamot.org)
• Product Development Management Association (PDMA) (www.pdma.org)

General Management • Academy of Management (AM) (www.aomonline.org)

• Institute for Operations Research and the Management Sciences (INFORMS)
(www.informs.org)

Engineering Education • American Society of Engineering Education (ASEE) (www.asee.org)

7
Engineering Management Handbook

Table 1.4. Journals Associated with the Engineering Management Discipline

Group Journals

Engineering Management within • Journal of Management in Engineering

an Engineering Discipline • Leadership and Management in Engineering
• The Journal of Construction Engineering and Management

Disciplines Associated with • Cost Engineering

Processes and Tools Used by • International Journal of Project Management
the Engineering Manager • Journal of Systems Engineering
• Project Management Journal
• The Engineering Economist

Engineering Management • IEEE Transactions on Engineering Management

Across Disciplines • Engineering Management Review
• Engineering Management Journal (ASEM)
• The Engineering Management Journal (IEE IN UK)

Management of Technology • International Journal of Technology Management

• Journal of Engineering & Technology Management
• Journal of High Technology Management
• Journal of Product Innovation Management
• Technological Forecasting and Social Change
• Technovation
• R&D Management
• Research Policy
• Research Technology Management
• Technological Analysis and Strategic Management

General Management • Academy of Management Review

• Academy of Management Journal
• Administrative Science Quarterly
• California Management Review
• Decision Analysis
• Harvard Business Review
• Information Technology & People
• Interfaces
• International Journal of Operations & Production Management
• International Journal of Quality & Reliability Management
• International Journal of Service Industry Management
• Management Decision
• Management Review
• Management Science
• Manufacturing & Service Operations Management
• National Productivity Review
• Organization Science
• Sloan Management Review

Engineering Education • Journal of Engineering Education

• IEEE Transactions on Engineering Education

8
 Engineering Management: Past, Present, and Future

1.2.4 Engineering Management Related Conferences

Consistent with the three perspectives of the EM field we reviewed and categorized the different professional
conferences related to EM. Table 1.5 summarizes these conferences. We would like to share these related
conferences to help the reader understand where to go to for knowledge and to contribute to the knowledge
of the profession. This list of conference is not meant to be exhaustive, rather a starting place. The EM disci-
pline emerges from six unique sets of conferences.

Table 1.5. Professional Conferences Associated with the EM Discipline

Group Conferences

Engineering Management within • American Society of Civil Engineers (ASCE) (www.asce.org)

an Engineering • Institute of Industrial Engineers (IIE) (www.iienet.org)
Discipline

Disciplines Associated with • International Council of Systems Engineering (INCOSE) (www.incose.org)

Processes and Tools Used by the • Project Management Institute (PMI) (www.pmi.org)
Engineering Manager

Engineering Management • American Society for Engineering Management (ASEM) (www.asem.org)

Across Disciplines • IEEE Engineering Management Society (IEEE EMS) (www.ieee.org/ems)
• PICMET (www.picmet.org)

Management of Technology • International Association for Management of Technology (IAMOT)

(www.iamot.org)
• PICMET (www.picmet.org)
• Product Development Management Association (PDMA) (www.pdma.org)

General Management • Academy of Management (AM) (www.aomonline.org)

• Institute for Operations Research and the Management Sciences
(INFORMS) (www.informs.org)

Engineering Education • American Society of Engineering Education (ASEE) (www.asee.org)

• Masters of Engineering Management Programs Consortium
(http://www.mempc.org)
• Accreditation Board of Engineering and Technology
(http://www.abet.org)

1.2.5 The Future of the Engineering Management Discipline

The intent of this section is to develop a framework to continue the conversation about the future of EM.
The intent is not to define the agenda, but rather provide the structure from which further conversations
can be developed. In reviewing the past and present of EM and the emerging issues facing the world,
the discipline of EM offers a unique ability to make lasting contributions (Sarchet and Baker, 1989). To
define strategic issues we first understand three items: (1) a description of trends and challenges facing the
EM organization, (2) a model of the EM discipline from a perspective of knowledge roles, and (3) a de-
scription of global outcomes for the stakeholders of the EM discipline. By taking these three perspectives
we can better understand and define the emerging issues facing the discipline.

1.3 Emerging Engineering Management Related Trends, Drivers, and

Challenges
Barkema, Baum, and Mannix (2002) defined a set of trends defining management challenges. These chal-
lenges included: greater diversity; greater synchronization requirements; greater time pacing requirements;
9
Engineering Management Handbook

faster decision-making, learning, and innovation; faster newness and obsolescence of knowledge; more
frequent environmental discontinuities; faster industry life-cycles; greater risk of competency traps; and
faster newness and obsolescence of organizations. The challenges are being driven by the increased global-
ization of the knowledge economy and the increasing complexity of the systems. Technology managers are
facing challenges managing in this domain. Engineering managers face challenges that include: (1) strate-
gic planning for technology products, (2) new product project selection, (3) organizational learning about
technology, and (4) technology core competencies (Scott, 1998). During the 2003 annual conference of
the American Society for Engineering Management (ASEM), a session was held with both practicing and
academic EM participants on defining the challenges associated with EM. During this session the partic-
ipants identified challenges in three groups: (1) business environment trends and challenges, (2) organi-
zational trends and challenges, and (3) engineering management/manager trends and challenges (Utley,
Farrington, and Kotnour, 2003). The business environment trends and challenges included:
• Globalization,
• Short-term profit focused,
• Increased regulatory/environmental stewardship/ethical focus, and
• Changing demographics of the workforce.

These trends create further trends and challenges for the technical organization:
• Forging partnerships,
• Operating networks of relationships,
• Implementing a process-based organization,
• Continuously managing change, and
• Gaining/maintain employee loyalty and commitment.

The engineering manager then faces of the challenges of operating in this environment. Specific chal-
lenges include:
• Managing and leading teams,
• Understanding and managing uncertainty,
• Managing and leading the workforce,
• Changing culture,
• Using tools and metrics to manage, and
• Developing the needed management and leadership skills and behaviors.

Figure 1.3 summarizes these challenges. These trends and challenges offer the strategic context for the
EM discipline. For example, the discipline needs to become more global and integrative across disciplines.
The EM discipline must define a body of knowledge that provides the knowledge needed by the engineer-
ing manager to be successful in the challenging environment.

10
 Engineering Management: Past, Present, and Future

Figure 1.3. Challenges for the Technical Organization and Engineering Manager

We Defined EM Challenges
Business Environment Trends & Challenges
• Globalization
• Short-term profit focused
• Regulatory, environmental and ethical
• Demographics (age of the workforce, diversity, attitudes of the
workforce)

Organizational Trends & Challenges

• Forging partnerships (with competitors)
• Operating network relationships
• Implementing a process-based organization
• Continuously managing change
• Gaining and maintaining employee loyalty and commitment

Engineering Management/Manager Trends & Challenges

• Managing and leading teams
• Understanding and managing uncertainty
• Managing and leading the workforce
• Changing culture
• Using tools and metrics to manage
• Developing management and leadership skills and behaviors

1.4 Engineering Management Discipline’s Knowledge Roles

The EM discipline plays five knowledge roles (Boyer, 1990; Kotnour, 2001). The roles are based on the
knowledge management function (i.e., generate, assimilate, or communicate) and application of the
knowledge (i.e., generalist/across many organizations or organization specific). As can be seen in Figure
1.4, each of these roles supports the other roles. The challenge for the EM discipline is in integrating these
five roles. The five roles are:
1. Research: The process of generating generalized knowledge. This knowledge can be applied to many
different domains and does not necessarily solve an organization’s unique problem. This knowledge
serves as the content and basis for the other roles.
2. Education: The process of teaching students knowledge that can be applied to many different do-
mains or applications. The education roles pulls content from the other roles.
3. Training: The process of transferring knowledge to a unique domain, application, or organization. In
training, the discipline’s knowledge is used to provide specific application insights.
4. Technical assistance: The process of working with an organization to solve a specific performance
challenge. This technical assistance support creates knowledge unique to an organization. This unique
knowledge can be used to generalize from for research or used as case studies in training or education
classes.
5. Service: The set of activities to provide support to the university, profession, and society. The service
role also provides an overarching or governance function for the discipline. The service or professional
society role helps to assimilate the knowledge through conferences and journals.

These five knowledge roles are needed to provide positive outcomes for the EM discipline’s stakehold-
ers. The strategic issue facing the EM discipline is on how to integrate these five roles across the global and
diverse set of contributing disciplines, professional societies, journals, and conference of EM. The intent
of the rest of this chapter is to define specific challenges facing the EM discipline.

11
Engineering Management Handbook

Figure 1.4. Five Knowledge Roles of the EM Discipline

Technical
Generate Research
Assistance
Knowledge Function

Assimilate Service

Communicate Training Education

Organization Generalized
Unique
Application Level

1.5 Engineering Management Discipline Stakeholder Needs

To raise a set of questions to help determine the agenda for the future of the EM discipline, we must first
understand the discipline’s stakeholders and needs. The stakeholders are the set of individuals or groups
who impact and are impacted by the profession. Table 1.6 summarizes the needs of the EM disciplines
stakeholders. These outcomes can provide the overarching guidance or goals for the discipline.

12
 Engineering Management: Past, Present, and Future

Table 1.6. EM Discipline’s Stakeholder Needs

Stakeholder Desired Outcome Engineering Management

Discipline’s Contribution in Helping
the Stakeholder Achieve their
Desired Outcome

Society • Strong, stable society • Provide graduates who are functional and
• Useful products and services make a difference

High-tech organizations • Success in growing their • Provide educated graduates

business • Provide real-time knowledge to improve
organizational performance

Profession • Enhanced professionalism and • Provide service to the professional

profession societies and active students/graduates

Practicing engineering • Success in the workplace • Provide real-time knowledge to improve

manager and individual, team, and organizational
engineering team performance

Professional engineer • Maintain professional • Provide real-time knowledge to improve

certification individual performance
• Offer opportunities to complete
professional registration requirements

University community • Enhance the reputation of the • Provide an outlet (i.e., conferences
university and scholarly journals) for faculty to
professionally grow and gain recognition
for academic programs

Student • Productive, working member • Provide educational and work experiences

of society to enable them to be a life-long learner
• Provide a connection to employers and
graduate schools

Faculty • Enhanced reputation and • Provide the infrastructure and outlets for
freedom to intellectually conducting teaching, research, and service
explore

Accreditation • Meet the desired outcomes • Define the bodies of knowledge and
institutions of the accreditation process characteristics of the EM discipline
• Systematically implement the accreditation
process

1.6 Conclusions and Summary

The intent of this chapter was to review the history and current state of the EM discipline as a foundation
to help define the future of the discipline. We have presented a review of the history of the profession
and also presented several definitions. To further describe the current state of the profession we have
summarized relevant professional organizations, publications, and technical societies. However, the main
contribution of this chapter is to present emerging trends, knowledge roles, and stakeholder needs for the
profession along with strategic issues that will affect the future of EM and engineering education.
We offer four conclusions from this work. First, the EM profession is at a critical juncture in its matu-
ration. Unlike many traditional engineering professions, EM has been agile and responsive to changes in
13
Engineering Management Handbook

the global economic community. This can mainly be attributed to our main role as continuing education
for engineers and scientists. In practice, we have had to be on the leading edge of managerial trends to
produce competitive products and services. In order to remain relevant, we have had to adapt our skill
sets. However, the role of EM is changing from both an educational and practical perspective. Most EM
programs are run very similar to MBA programs with adjunct faculty. EM education is becoming more
accepted within most universities. Unfortunately, few universities have standalone EM programs at the
undergraduate and graduate levels staffed with mainly full-time faculty. The number of undergraduate
programs has experienced steady growth. From a practicing EM perspective, the challenges in many ways
are more daunting. Rapid changes in business practices require a continual self-evaluation and retraining
to remain relevant.
Second, the EM profession needs to build an integrated approach of teaching, research, technical
assistance, training, and service. From this integration, the discipline will continue to grow and make
significant contributions. Third, to draw this synergy, the EM profession must also recognize the comple-
mentary perspectives that different contributing fields can bring. These complementary perspectives will
help develop and transfer the knowledge needed to address the challenges of the technical environment
and technical organization. Fourth, the EM professional societies offer a key mechanism to foster collab-
oration across disciplines. The leadership for the profession needs to come from active participation from
the discipline itself and the leadership of the professional societies.

1.7 References
Abel, K., An Analysis of Stevens Engineering Management Graduates, 1990 – 2004, Hoboken, NJ: Stevens
Institute of Technology, 2005.
Argyris, C., and Schon, D. A., Organizational Learning: A Theory of Action Perspective, Reading, MA:
Addison-Wesley, 1978.
Babcock, Daniel, “Management Divisions of Engineering Societies,” Engineering Management Journal,
vol. 1, no. 3, Sept. 1989, pp. 9-14.
Babcock, Daniel, “Tribute to Bernie Sarchet,” Engineering Management Journal, vol. 12, no. 1, March
2000, p. 2.
Babcock, Daniel, and Morse, Lucy C., Managing Engineering and Technology, 3rd Edition, Upper Saddle
River, NJ: Prentice Hall, Inc., 2002.
Badaway, M. K., “Technology Management Education: Alternative Models,” California Management
Review, vol. 40, no. 4, 1998, pp. 94-116.
Baldridge, D. C., Floyd, S. W., and Markoczy, L., “Are Managers from Mars and Academicians from
Venus? Toward an Understanding of the Relationship Between Academic Quality and Practical Rel-
evance,” Strategic Management Journal, vol. 25, no. 11, 2004, pp. 1063-1074.
Barkema, H. G., Baum, J. A., and Mannix, E. A., “Management Challenges in a New Time,” Academy of
Management Journal, vol. 45, no. 5, 2002, pp. 916-930.
Boudreau, J. W., “Organizational Behavior, Strategy, Performance and Design in Management Science,”
Management Science, vol. 50, no. 11, 2004, pp. 1463-1476.
Boyer, E. L., Scholarship Revisited: Priorities of the Professoriate, The Carnegie Foundation for the Advance-
ment of Teaching, 1990.
Clark, Geoffrey W., History of Stevens Institute of Technology – A Record of Broad Based Curricula and
Technogenesis, 1870-2000, Jersey City, NJ: Jensen/Daniels Publishers, 2000.
Collins, T. R., Berivudes, M. G., Youngblood, A. D., and Pazos, P., Professional Development Training for
Engineering Managers,” Engineering Management Journal, vol. 16, no. 3, Sept. 2004.
Deming, W. E., Out of Crisis, Massachusetts Institute of Technology, Center for Advanced Engineering
Study, Cambridge, MA, 1982.
Dorf, R. C., The Technology Management Handbook, CRC Press, 1999.
Emery, F. E., and Trist, E. L., “Socio-technical Systems,” In C.W. Churchman and M. Verhulst (editors),
Management Sciences: Models and Techniques, Oxford: Pergamon, 1960.

14
 Engineering Management: Past, Present, and Future

Farr, J., and Bowman, B., “ABET Accreditation of Engineering Management Programs: Contemporary
and Future Issues,” Engineering Management Journal, vol. 11, no. 4, December 1999, pp. 7-13.
Farr, John V., and Buede, Dennis, “Systems Engineering and Engineering Management: Keys to the
Efficient Development of Products and Services,” Engineering Management Journal, vol. 15, no. 3,
September 2003, pp. 3-11.
Farr, John V., Systems Life Cycle Costing: Economic Analysis, Estimation, and Management, CRC Press,
January 2011.
Hammer, M., and Champy, J., Reengineering the Corporation, New York: Harper Business, 1993.
Hicks, P., Utely, D., and Westbrook, J. “What are we teaching our engineering managers?” Engineering
Management Journal, vol. 11, no. 1, March 1999, pp. 29-34.
IEEE Editorial, “Research and Education Characteristics of the Engineering Management Discipline,”
IEEE Transactions on Engineering Management, vol 37, no. 3, August 1990, pp. 172-176.
International Organizations for Standardization, http://www.iso.ch/iso/en/iso9000-14000/index.html,
accessed January 24, 2005.
Jacko, Julie A., http://www.isye.gatech.edu/lhci/hci_role.pdf, accessed January 24, 2005.
Johnson, J. H., Micro Projects Cause Constant Change, presented at Second International Conference on
Extreme Programming and Agile Processes in Software Engineering, (20-23 May 2001), Cagliari, Italy,
Kocaoglu, Dundar, “Engineering Management Education and Research,” Engineering Management Con-
ference/International Congress on Technology and Technology Exchange, Pittsburgh, PA, October 8,
1984.
Kocaoglu, Dundar, “Strategic Opportunities for Engineering Management,” Engineering Management
Journal, vol. 1, no. 1, March 1989, pp. 8-10.
Kocaoglu, Dundar, “Education for Leadership in Management of Engineering and Technology,”
PICMET 91 – Portland International Conference on Management of Engineering and Technology,
pp 78-83, Portland OR, 1991.
Kotnour, T. G., “Building Knowledge for and about Large-Scale Organizational Transformations,” Inter-
national of Operations and Production Management, 2001.
Motorola Inc., http://www.motorola.com/content/0,,3074-5804,00.html, access January 24, 2005.
Murray, Susan L., and Raper, Stephen A., “Engineering Management and Industrial Engineering: Six One
Way, A Half Dozen the Other,” American Society of Engineering Education Annual Conference,
Session 2542, 1997.
OR/MS Today, http://www.lionhrtpub.com/orms/orms-2-01/nps.html, accessed January 24, 2005.
Ramos-Rodrigues, A. R. and Ruiz-Navarro, J. “Changes in the Intellectual Structure of the Strategic
Management Research: A Bibliometric Study of the Strategic Management Journal, 1980-2000,” Stra-
tegic Management Journal, vol 25, no. 10, 2004, pp. 981-1004.
Sarchet, Bernie, and Baker, Merl, “Engineering Management—Key to the Future,” Engineering Manage-
ment Journal, vol. 1, no. 1, March 1989, pp. 4-7.
Sarchet, Bernie, and Baker, Merl, “Defining the Boundaries of Engineering Management,” Engineering
Management Journal, vol. 7, no. 2, March 1995, pp. 7-10.
Scott, G. M., “The new age of new product development: Are we there yet?” R & D Management, vol.
28, no. 4, 1998.
Shewhart, Walter A., Bell Laboratory Memorandum, Issued May 16, 1924, http://www.itl.nist.gov/
div898/handbook/pmc/section1/pmc11.htm, accessed January 24, 2005.
Taylor, Frederick Winslow, The Principles of Scientific Management, 1911.
Triad Business Journal, http://triad.bizjournals.com/triad/stories/2004/03/29/focus2.html?t=printable,
accessed March 1, 2005.
Utley, D., Farrington, P., and Kotnour, T. G., “Understanding the Challenges of the Engineering Man-
ager,” working paper, Author, University of Alabama Hunstsville, 2003.
Waters, Bob, “Engineering Management Tradition and Education: Past, Present, and Future,” Engineering
Management Journal, vol. 6, no. 3, Sept. 1994, pp. 5-8.

15
16
 Professional Responsibility, Ethics, and Legal Issues

2
Professional Responsibility, Ethics,
and Legal Issues

William J. Daughton
Missouri University of Science and Technology

17
Engineering Management Handbook

2.1 Introduction
2.1.1 Relevance and Importance
As a profession, engineering must adhere to the highest standards of integrity and honesty. Engineering
has a direct impact on society in terms of safety and quality of life so engineers must be vigilant in adher-
ing to the highest principals of ethical conduct in conducting their professional work.
Engineering is often directly involved with the creation of technology-based work product that has
significant value to the employer or client. The value of this work product must be protected leading to
patents and copyrights. Engineering managers must be aware of their responsibilities in this domain to
ensure the proper protection of company work product assets.

2.1.2 What are Ethics?

Ethics is concerned with the kind of values and morals an individual or a society finds desirable or appro-
priate (Northouse, 2016). Northouse also points out that ethical theory guides individuals or organiza-
tions in decision-making about what is right or wrong in given situations. It should be noted that ethics
and legal requirements are different. Often, the real ethical dilemmas are choices among alternative that
are all within the law but have different impacts on constituents.

2.1.3 What Constitutes Intellectual Property?

For the engineering manager, intellectual property (IP) can be divided into two parts: industrial assets that
are the result of invention or design and the creative work of individual authors. Both have the potential
to need protection and the source of the protection in each case is different.

2.2 Engineering Code of Conduct

2.2.1 Introduction to the NSPE Ethical Canons
The National Society of Professional Engineers (NSPE) list fundamental canons that form the basis for
ethical conduct (NSPE, 2009):
Engineers in the fulfillment of their professional duties shall:
1. Hold paramount the safety, health, and welfare of the public.
2. Perform services only in areas of their competence.
3. Issue public statements only in an objective or truthful manner.
4. Act for each employer or client as a faithful agent or trustee.
5. Avoid deceptive acts.
6. Conduct themselves honorably, responsibly, ethically, and lawfully so as to enhance the honor, reputa-
tion, and usefulness of the profession.

2.2.2 Safety, Health, and Welfare of the Public

From a practical standpoint this canon requires engineering managers to be focused on ensuring that the
work of their engineers is in compliance with all requirements set forth by their employer or client and
with all established standards for workmanship and safety. If a violation report is received of either of
these requirements, an engineering manager has an obligation to obtain all facts pertinent to the situation,
and if the facts support the violation, report it to higher-level management of the employer or to the cli-
ent. It is critical that the information be fact-based and not based on rumor or speculation. The credibility
of the reporting engineers and the engineering manager is at stake in making such reports.
Any information related to such disclosures cannot be revealed without the approval of the employer
or client except as required by law or these canons. In holding the health, safety, and welfare of the public
as paramount, this canon also requires that engineering managers report the unlawful practice of engi-
neering by any person or company and to cooperate with proper authorities investigating such unlawful
practice.

18
 Professional Responsibility, Ethics, and Legal Issues

2.2.3 Professional Service Only in Qualified Areas

Engineering managers must ensure that the engineers assigned to a specific job or projects indeed have
appropriate credentials to qualify them to do the work. There may be a hierarchy of engineering expe-
rience and qualifications in a group of engineers assigned to a job or project, and this allows for at least
one senior engineer with review and validation authority to oversee the technical work of less experienced
or apprentice engineers. Ultimately, the work must be approved by qualified engineering and technical
management individuals.

2.2.4 Objective and Truthful Public Statements

As indicated in section 2.2, fact-based reporting of information is essential for the credibility of the
engineers, engineering managers, and their employers. Objective and relevant facts must be included in
technical reports and presentations, and the engineering manager must ensure that such facts are not
selectively removed.
Established and recognized technical professionals are often asked to provide public comment and
opinion on technical matters. There are two critical factors to be considered if this situation arises:
1. Such comments and opinions are based on knowledge of the facts and competence in the subject matter.
2. If such comments or opinions are inspired or paid for by interested parties, that should be disclosed
prior to any public statements.

2.2.5 Faithful Agents for Employers or Clients

This canon relates directly to conflict of interest. A situation that is perceived to create a conflict should be
fully disclosed to the employer or client. Such conflicts include:
1. Compensation by more than one party for services on the same project.
2. Financial or other considerations of more than trivial value from outside parties in connection with
work being performed. Any consideration from an outside party that can influence the judgment,
decisions, or work on an engineering manager represents a potential conflict.
3. Acceptance of a contract from a governmental body (local, state, or federal) on which a principal or
officer of the organization serves as a member.
4. Participating in a decision as a member of a governmental body that involves the individual’s employ-
er. The right course of action here is for individuals in this situation to disclose the conflict and recuse
themselves until the matter is resolved.

2.2.6 Avoidance of Deceptive Acts

Although this may seem obvious, there are several specific ethical and potentially legal situations worth
mentioning.
The first situation deals with misrepresenting or exaggerating individual or group capabilities or
knowledge for the purpose of winning a contract or procuring professional work. Engineering managers
must be particularly careful to ensure capabilities or knowledge are not misrepresented or even miscon-
strued by potential clients. Engineering managers would often be the name-of-record in validating work
completed. There could be serious legal liabilities as well as ethical issues.
The second situation involves behind-the-scenes offerings of payments or other considerations to a
public authority to influence decisions favorably on the awarding of contracts or work. The bidding pro-
cess for public work must be able to withstand public scrutiny.

2.2.7 Enhancing the Profession Through Ethical Behavior

This may seem like a catch-all statement but it really points to the fact that each engineer and engineering
manager is part of larger whole and any unethical or illegal activities of any sort by a single individual
tarnishes the reputation and credibility of everyone in the profession. Seeing individuals involved in un-
ethical or illegal behavior encourages slippery-slope thinking; e.g., “because others have done it, why not
me?”. To protect the reputation of the profession, serious attention must be paid to ethics and legality.
19
Engineering Management Handbook

2.3 Ethical Decision-Making

2.3.1 Introduction
There are four principles for making ethical decisions that engineering managers can use to analyze the
impact of their decisions on the key stakeholders on an organization. As the label implies, stakeholders
have a stake in the success of the organization, and all decisions that are made by the organization have
potential consequences on one or more of the stakeholder groups. As a result, it is imperative to consider
the impact of such decisions from an ethical standpoint.
Traditionally, the organizational stakeholders are shown in Figure 2.1.

Figure 2.1. Organizational Stakeholders

Suppliers Customers

Employees Organization Communities

Stockholders

For simplicity, Employees include everyone, managers as well. Some sources separate employees and
managers due to their different roles (Jones and George, 2006), but purposes of this treatment they are
combined. Here, the term Communities refers to the local communities in which the organization has a
presence as well as the broader content of national or international communities.
The four ethical principles that can be applied to analyze the impact of managerial decisions on the
above group of stakeholders are (Jones and George, 2006):
1. Utilitarian Rule
2. Moral Rights Rule
3. Justice Rule
4. Practical Rule

These rules are in practice useful guidelines to guide decision-making by balancing the self-interest of
the organization with those of the stakeholders.

2.3.2 Utilitarian Rule

This rule is based on the concept that an ethical decision is one that produces the greatest good for
the greatest number of stakeholders. So in applying this rule, engineering managers should consider
how various alternatives would benefit or harm the stakeholder group. The principle is to choose an
alternative that provides the most benefit or least harm for all stakeholders in equal measure. The
practical problem with this rule is that such decisions may result in no one being satisfied with
the outcome.

2.3.3 Moral Rights Rule

Under this rule, an ethical decision is one that protects the inalienable rights of the people affected by the
decision. Issues of health and safety relative to Employees and Communities would be paramount here.
20
 Professional Responsibility, Ethics, and Legal Issues

In addition rights of free speech and privacy arise as well. The practical difficulty with this rule is that
decisions that protect the rights of some stakeholders may hurt the rights of others.

2.3.4 Justice Rule

This rule is based on fair and equitable distribution of benefits or harm. It requires engineering managers
to consider alternatives based on the degree to which they will impact all these stakeholders. The dilemma
is what constitutes “fair and equitable.” Engineering managers must determine procedures for distributing
outcomes fairly to all stakeholders.

2.3.5 Practical Rule

The three previous rules may be difficult to readily apply in complex or fuzzy situations. However, this
rule is one that is easy to apply and is one that no one should have any hesitation to use. Basically, the rule
asks how a typical person would react to a decision from an ethical standpoint. The practical statement of
the rule often appears as “Would you want this decision to be on the front page of your local newspaper?”
Alternatively, “Would you want your mother to know what you did?” The point is whether the ethics of a
decision or action could withstand public scrutiny. This rule is actually very powerful and easy to apply.

2.3.6 Implementing the Ethical Principles

The principles cited in Sections 2.3.2 through 2.3.5 provide foundations for making ethical decisions.
The challenge is evaluating an ethical dilemma so that one or more of the principles may be fairly applied.
One approach (Morse and Babcock 2010) focuses on a series of steps for facilitating solutions to ethical
dilemmas.
• Step 1. Determine the facts—While an engineer might consider this obvious, this step takes on
special significance in ethical dilemmas where emotion and passion often run high. Time con-
straints may limit this step, but still it is important to take the time to verify accusations and not
be overrun by innuendo and rumor.
• Step 2. Define the stakeholders—As pointed out in Section 2.3.1, it is important to understand
which stakeholder groups may be affected and how by implementing one or more of the ethical
decision rules.
• Step 3. Assess the motivation of the stakeholders—Once the groups who have a stake in the
decision have been identified, it is important to assess why they would care and how they might
react to a decision.
• Step 4. Formulate alternative solutions—Using the organizations core ethical values as a guide,
develop alternatives to resolve the dilemma.
• Step 5. Evaluate purposed alternatives—Using the information gathered about the affected stake-
holders and applying the ethical decision principles, determine which alternatives provide the
most positive or least negative effects on the stakeholders.
• Step 6. Seek additional assistance, as appropriate—Review codes of ethics and previous similar
cases, and seek guidance from knowledgeable individuals.
• Step 7. Select the best course of action—Determine the optimal solution utilizing information
from steps 4-6.
• Step 8. Implement the selected solution—Ensure the solution conditions are properly and fully
implemented.
• Step 9. Monitor and assess the outcome—Monitor how the implemented solution is received by
the affected stakeholder groups and archive this information for use in future dilemmas.

2.4 Global Considerations in Ethical Conduct

2.4.1 The Global Environment
Engineering managers today work in a global environment. Whether it is R&D, manufacturing,
technical marketing and sales, or financial engineering, work is occurring in a globally distributed
21
Engineering Management Handbook

environment. Managers need to understand how to ethically behave when conducting business
outside the United States. Moral beliefs, social customs, and culture create different ethical standards
in other parts of the world. Engineering managers must recognize these moral, social, and culture
influences define what is considered appropriate and acceptable in doing business. Further, compa-
nies themselves must let their engineering managers know what is expected of them when working in
foreign locations.

2.4.2 Laws and Codes for International Business

The U.S. Foreign Corrupt Practices Act (FCPA) makes it illegal to knowingly corrupt a foreign official.
However, even the FPCA allows for small payments to foreign government employees who are primarily
working in administrative or clerical roles when such payments are considered part of the business culture
in that country.
The UN Global Compact describes principles for doing business globally in the areas of human
rights, labor, the environment, and in anticorruption. This compact has been signed by a large number of
CEOs around the world and does represent an effort to establish international ethical guidelines.
The best advice is to seek the guidance and counsel of the organization prior to starting a business
relationship in another country. Or, if that relationship already exists, determine what practices have been
considered ethical in the past in these relationships. An organization’s legal office may have specific guide-
lines and the HR department may offer training for new managers. The one parting caveat is do not enter
into an international relationship unprepared for ethical dilemmas.

2.4.3 Ethical Decision Making in the Global Environment

As seen in the preceding sections, there are a number of challenges when faced with ethical dilemmas
that have a global component. However, by addressing a few basic questions, engineering managers may
minimize ethical problems:
• Is it legal?
• Does it in anyway violate basic human rights?
• Is it consistent with the norms and culture of the society affected?
• If there are seemingly ethical conflicts, can those be reconciled?

Basic human rights include the right to good health, good standard of living, and the opportunity
for economic advancement. In essence, they represent human dignity. Cultural-specific norms refer to the
norms in the culture or cultures being affected by the decision. Clearly the term “reconciled” may raise
some eyebrows as it appears to be a way to circumvent ethical obligations. However, the reference here is
to find ways to work within the culture of a given country or part of the world while still respecting the
legal and ethical requirements of the home country. This often arises with respect to gifts. As an example,
in a country where exchanging gifts are the norm, a large company-to-company gift may be considered
while small, nominal value personal gifts are exchanged. This would meet the requirements of both the
U.S. and the other country.

2.5 Protecting Employees Who Raise Ethical Issues

2.5.1 Introduction
Engineers working on new technology or products may become aware of potential adverse impact to the
health and safety of the end user or to society at large. They also may see the behavior of other individuals
as violating ethical principles.

2.5.2 Creating the Right Culture

For engineering managers it is important to develop a healthy, open working relationship with the engi-
neering staff. This will enable potential ethical issues to be discussed openly and misconceptions, rumors,
22
 Professional Responsibility, Ethics, and Legal Issues

and lack of complete information to be addressed. There are occasionally stories circulating through a
laboratory or engineering office about some type of unethical situation or behavior, often totally false or
perhaps with a grain of truth. Unless these can be dealt with openly, they will take on a life of their own.
What may have been a something almost trivial can grow to be a source of major discontentment and sus-
picion. There must be a working culture that encourages this kind of dialog and one that does not imply
threats to an individual’s career for raising these issues.

2.5.3 Sarbanes-Oxley Act

However, if employees perceive that their concerns are being ignored or covered up, or they feel that they
cannot discuss the concerns with management, then what may occur is a whistle-blower case. Whis-
tle-blowers now have some protection under the Sarbanes-Oxley Act. Retaliation against an employee
for reporting ethical or legal issues may result in a 10-year prison sentence for the offending individual.
However, in practice examples of retaliation can still be found. The current act is definitely a progressive
step forward but it is not a guarantee that a whistle-blower will completely shielded from retaliation.

2.6 Responsibilities for Intellectual Property

2.6.1 Why Protect Intellectual Property?
Work product generated by engineering groups or individuals may have significant strategic, competi-
tive, or economic value to the organization. For industry assets such as inventions or designs, the value
may be strategic such as being able to penetrate a new market, competitive, such as being able to offer
a product with new or enhanced features, or economic, such as simplifying a design to reduce manufac-
turing costs. Individual and group creative work may contribute new ideas, methods, or approaches to
enhance or improve any operational aspects of an organization, not just work product related. Credit for
and use of these ideas, methods, and approaches can be protected to limit outside use and dissemination.

2.6.2 Invention Disclosure Processes

Most commercial organizations have well-defined steps for disclosing inventions and those steps may
differ somewhat from one another. However, to successfully plug into that process, engineering managers
should follow a few simple guidelines:
1. Ensure all engineers and other technical contributors understand the importance of documenting
their work.
2. Ensure all engineers and other technical contributors have a notebook with permanent binding so
that pages cannot be added or removed in which their technical work can be recorded.
3. Emphasize the need to record and document technical activity with dates of work accomplished. En-
gineers engaged in any research or development as part of the normal work activity must be routinely
assigned notebooks. Other engineers and technical contributors who from time to time work on proj-
ects with potential for protected work product should have notebooks available to record such work.
4. Store and maintain notebooks pending resolution of any disclosure claims.
5. Serve as an interface with organization IP liaisons and legal departments to simplify the disclosure of ideas.
6. Ensure that inventors are properly recognized for their contributions.

2.6.3 Patents
If an organization determines that an invention disclosure is novel and valuable, it may choose to purse a
patent to protect the invention. Patents in the U.S. are held for 20 years for an invention (14 years for a
design) and provide the organization with exclusive rights of use and the opportunity to license the inven-
tion to others. Typically, patent attorneys employed by the organization manage the application process.
Patents provide the owners with the opportunity to license the invention to others for their use in
exchange for payment, which may create a significant revenue stream.

23
Engineering Management Handbook

2.6.4 Copyrights
Copyrights can be awarded to owners of works such as books, pamphlets, lectures, professional papers,
and training materials. The owner of the work may be the author, or in a professional setting, the em-
ployer if the work was created as part of the author’s assignment or job duties. The owner may see value
in protecting such materials from free use and dissemination for strategic, competitive, or economic
reasons and choose to identify the work as copyright protected. Effectively, a created work is considered
protected as soon as it exists, and no public filing for copyright protection required.
There are several limitations to the use of copyrighted material without authorization:
• Single copies for private, non-commercial use.
• Free use provided the source is properly referenced. This exception also allows for the use of protected
works for teaching purposes or for news reporting.
• Fair use depending on such things as the nature of the use, the amount of the total work used, and
the impact the use has to the potential value of the whole work.
• Non-voluntary licenses when compensation is paid to the author in respect of the use.

Copyrights may be transferred by the owner. All economic rights may be transferred to a third
party and such transfers may include selling those rights in return for payment. Transfers take two
forms:
1. Assignments or the transfer of property rights. The party to whom the property rights are transferred
becomes the new copyright owner. Often the publication of technical papers in proceedings or jour-
nals is contingent upon the assignment of copyright to the publisher.
2. Licenses are granted to third parties to use the copyrighted materials but the copyright remains with
the original owner. License agreements may include payment to the original owner for use by the
third party.

2.7 References
C. M. Chang, Engineering Management, Challenges in the New Millennium, Pearson/Prentice Hall, 2005.
Jones, G. and George, J., Contemporary Management, McGraw-Hill Irwin, 4th edition, 2006.
National Association of Professional Engineers (NSPE), Code of Ethics, http://www.nspe.org/Ethics/
CodeofEthics, 2009.
P. Northouse, Leadership Theory and Practice, Sage, 7th edition, 2016.

2.8 Other Sources of Information

A Guide to the Engineering Management Body of Knowledge, Domain 11, ASEM publication, 3rd edition,
2012.
World Intellectual Property Organization (WIPO), http://wipo.int/freepublications/en/intproperty/,
2009.

24
 Management Theory and Concepts

3
Management Theory and Concepts

Jerry Westbrook
University of Alabama, Huntsville

Chris Edmonds
Roddies’ Code and Roddie Edmonds Foundation

25
Engineering Management Handbook

3.1 Introduction
The objective of this chapter is to layout the evolution of the EM theory in order to better define the cur-
rent thinking about EM. The end result may be a more standardized approach as to what is taught in EM
academic programs and what is practiced by EM professionals in this country and around the world.

3.2 Historical Perspective

The logical beginning place for EM theory is with the Industrial Revolution. Prior to the Industrial
Revolution, manufacturing was done by craftsmen, making one item at a time. Practically everything was
made to order. There is some mention of enterprising craftsmen hiring workers to do the simpler parts
of the total tasks and the craftsmen performed the skilled work in order to increase the number of items
produced. Transportation was so primitive that it was difficult to secure raw materials consistently and it
was equally difficult to identify a sufficient number of customers to make such efforts worthwhile. The
invention of the steam engine did much to change this. The steam engine spawned transportation systems
not dreamed of previously. In addition, the steam engine provided the potential for powering manufac-
turing industries. This fact was not lost on a myriad of inventors who used the steam engine to develop
ways of manufacturing quality goods that previously were made only by craftsmen. James Watt invented
the steam engine and formed a partnership with Matthew Boulton to manufacture and sell them. “In
1776, Watt’s first engine was sold to John Wilkinson for use in his iron works. Not knowing what price
to charge, an agreement was made that the steam engine would be ‘rated’ at the equivalent of how many
horses could do the same amount of work: hence the derivation of ‘horsepower’ for mechanical engines”
(Wren, 1979).
Another inventor, Richard Arkwright, is credited as being first to develop the concept of the factory.
He organized all of the equipment required to make cotton cloth in one building. This model of effi-
ciency was copied and improved on for many years. But it takes more than equipment and buildings to
make products. It takes workers, preferably skilled workers. There was an initial effort made to recruit
the skilled craftsmen to work in factories. There were not enough of them so farmers were also recruited.
These two groups proved to be difficult to deal with. They were independent by nature and resented the
factories which, in some cases, caused them to lose their former professions, and in every case attempted
to regiment them and tell them what to do all of the time. As a result, there are many incidents recorded
where factory equipment was destroyed by these discontented workers. These workers came to be known
as “Luddites,” named after a youth in Ludlam had smashed his knitting frame when his father had been
too harsh with him (Wren, 1979).
Because of the shortage of skilled labor, the independence of craftsmen and farmers and the problems
with them destroying machinery, factory owners turned to another labor source: women and children. It
has been estimated that by the year 1800, 75% of the factory workforce consisted of women and children.
Management talent was just as scarce as skilled labor. There was very little known about how to successful-
ly run a factory. Abuses of women and children were widespread. Fourteen-hour workdays were common.
The English Parliament investigated and attempted to establish a 10-hour workday for children. This
effort went on for 20 years but was never passed. Yet, during this same time Robert Owen started and op-
erated the New Lanark factory in Lanark, Scotland (George, 1968). Children’s work hours were limited to
10 and ¾ hours per day. Both school time and teachers were provided by the company, and workers were
provided with homes at moderate cost. Company meetings and outings were held on a regular basis. And
most importantly, the company was very profitable. After the invention of the steam engine, the second
most significant development of the Industrial Revolution was the adjustment the early factory owners
made to accommodate the large proportion of unskilled labor. They broke the complex tasks down into a
myriad of simple tasks. They developed “division of labor.” Division of labor, considered the first EM the-
ory, was widely written about during this time as a necessary principle for success in manufacturing. All of
the decisions were made at the top of the organization by management. Workers only had to concentrate
on the small task in front of them. Even so, some factories experienced problems with workers not paying
attention to their work. Incentive plans were instituted so that workers were paid for only the good pieces
they produced.
26
 Management Theory and Concepts

Frenchman Henri Fayol (1949) is generally credited with being the first to develop general manage-
ment principles. Fayol published his management principles in 1916 but they were not translated into
English until 1949. He was an engineer who rose to the position of general manager in a mining firm.
Fayol made two significant contributions to management theory. He was the first to propose management
principles and he was the first to define elements of management. His 14 principles include:
1. Division of work
2. Authority and responsibility (relationship)
3. Discipline
4. Unity of command
5. Unity of direction
6. Subordination of individual to general interest
7. Remuneration (fairness of )
8. Centralization (degree of appropriateness)
9. Scalar chain (of command)
10. Order
11. Equity (loyalty and fairness)
12. Stability of tenure (unnecessary turnover)
13. Initiative (motivation of subordinates)
14. Espirit de corps

Fayol’s (1949) elements of management are: planning, organizing, commanding, coordinating, and
controlling. These are considered to be fundamental concepts that are still being taught ninety years after
they were first published.

3.3 Scientific Management

Frederick W. Taylor was a contemporary of Fayol. While Fayol’s background was in mining, Taylor’s was
in processing (steel) and construction. The next major development in management theory was Frederick
W. Taylor’s Scientific Management. This is presented as the third major EM theory. Taylor’s (1911) meth-
odology is contained in his four principles:
1. Develop a large collection of knowledge about the process under study. Use this knowledge to deter-
mine the one best way to perform the work.
2. Scientifically select workers who are most able to perform the work by the specified method.
3. Train the workers to do the work using the “one best way.” Provide incentives for using the correct method.
4. Let management and workers collaborate on decisions so that the unique knowledge that each has
can be used toward the solution of organizational problems.

It can be seen that division of labor is implied in these four principles. There is an overriding assump-
tion that management divides the work and makes decisions affecting the way work is to be done. Taylor
(1911) believed that if any task is studied sufficiently, management can determine the one best way for
doing anything and can optimize productivity. He further believed that the variation introduced by the
workers could be reduced to insignificance through training and incentives. Workers and machines were
seen as only slightly different.

3.4 The Bureaucracy

The next major theory to be discussed was developed by the German economist Max Weber. Weber
(1947) became sensitive to the abuses of both bad and unscrupulous managers. He sought to develop
a management system which would protect the worker while at the same time require managers to use
accepted management practices. Weber was one of the first to make a clear distinction between managers
and owners. He saw owners as those who routinely hired without regard to abilities and qualifications.
They were also likely to promote workers to higher level positions similarly. The principles Weber chose to
accomplish his goals were as follows (1947):
27
Engineering Management Handbook

1. A well-defined hierarchy of authority with centralized decision making (by top management)
2. A clear division of work (labor)
3. Rational program of personnel administration
4. Rules and regulations as to how each job was to be done and the acceptable rate of production
5. Written records
6. A staff of experts to assist managers in solving complex problems

According to Weber’s (1947) concept, the manager represented authority. The manager was at the
top of the organizational pyramid and made decisions based on “his sphere of competence.” “Rules and
regulations” (Weber, 1947) prescribed as many decisions as possible, thus ensuring fair treatment of em-
ployees.
The purpose of the “rational program of personnel administration” (Weber, 1947) was to “pre-make”
decisions so that every employee is treated exactly like all others. Job descriptions and production quotas
would ensure that only reasonable work would be expected of employees. Complex problems were to be
solved by the manager and his staff of experts, not by the workers. Weber felt that not only would workers
be protected by such a system but that the organization would be more productive also. Again, we see the
familiar division of labor.
Division of labor helped to train managers for each division of the process. This proliferation of man-
agers adds levels to the organization. The many levels of the organization also contribute to the primary
attribute of this system control. So, multi-levels of structure and a small span of control are characteristic
of Weber’s design. Weber failed to see that his system would only function adequately in a stable environ-
ment where neither competitors nor technology were changing rapidly. If either of these were to begin to
change, the organization bound by rules and a strict chain of command could not adapt to the changing
environment. Weber’s system was designed to control, to prevent abuses. It was not designed to innovate,
to develop new products or processes. It was called by a familiar name—it is the bureaucracy and it created
a set of problems never envisioned by Weber.

3.4.1 A Critique
The problem is that most industries in the U.S. use some version of the bureaucratic management
principles just discussed. Chris Argyris (1957) wrote perhaps the most accurate critique of these manage-
ment principles. First, he researched the common characteristics of personality development. They are as
follows:
1. Man develops from a passive infant to an increasingly active adult
2. Goes from a state of dependence to independence
3. Changes from simple behavior to complex with maturity
4. From shallow interests, man develops deep commitments
5. Goes from short time frames to long time frames—more affected by the past than the future
6. Develops from family subordinate to peer or leader
7. Goes from a lack of awareness of self to the development of self control

Argyris (1957) further identified four common classical organization concepts and compares the
result of using them with the traits of normal personality development listed above.
• Division of labor—The individual sells skills rather than total abilities
• Chain of command—This tends to make individuals dependent, passive
• Unity of direction—This is leader oriented, not a function of workers
• Span of control (usually four to eight)—Adds levels to the organization, thus increases dependence

Argyris (1957) hypothesized three results of using classical organization concepts:

1. There is a lack of congruency between normal personality development and classical organization
concepts.
2. This lack of congruency generates frustration, short-term perspective and conflict.
28
 Management Theory and Concepts

3. The result will be inter-subordinate hostility, rivalries, and a focus on parts of the organization rather
than the whole.

Argyris (1957) found that management frequently (at the time of the writing of his article) used con-
cepts designed for use on uneducated women and children in manual labor factories.

3.5 Behavioral Approaches

The first years of the twentieth century saw a multitude of management concepts developed. In addition
to Fayol’s Principles’ Scientific Management and the bureaucracy, Frank and Lillian Gilbreath developed
methods analysis and Henry Gantt developed the Gantt chart. The idea that management practice could
improve productivity had many organizations actively searching for additional management concepts
that would give their organizations a competitive advantage. Western Electric conducted a wide range
of experiments with management practice at its Hawthorne works. They experimented with lighting,
work breaks, incentive systems, organization communication and other concepts. The general conclusion
reached was that the attitude of workers had much to do with organization productivity. They did not
reach firm conclusions on how to develop those positive attitudes. Theories on workforce motivation
required another thirty-five years to develop.

3.6 Quantitative Methods

The quantitative methods of management were developing at the same time as the qualitative concepts.
George Dantzig published a description of the simplex method of linear programming in 1947. Other
optimizing techniques soon followed. The operations research (OR) movement formed and grew fast in
the 1950s and 60s. There was a general feeling of the time that as computers become faster, management
will be able to solve most of its problems mathematically using a variety of OR concepts. The develop-
ment of decision trees, game theory, dynamic programming, and chaos theory are examples of concepts
that would enhance the ability of managers to make optimal decisions.
Engineering economy was first promoted within AT&T in the 1920s as a way to make better finan-
cial decisions. They developed the first textbook in the field and taught their managers and engineers in
company sponsored classes. Engineering economy continued to evolve and became a course common to
most industrial engineering curricula in the 1960s and is now a part of most EM programs. Engineering
economy is a way of making economic decisions in terms of current currency valuations or taking time
value of money for future resources into account.
Engineering economy combined with cost and managerial accounting provide managers with power-
ful tools to aid decision-making. The tendency for bureaucratic organizations with decision-making con-
centrated at the top, the overuse of quantitative decision-making without first-hand knowledge of organi-
zational processes led to a term labeled as “the rational model” by Peters and Waterman in their book In
Search of Excellence (1982). The “rational model” was associated with low productivity organizations. Even
powerful management tools and concepts can be used to the disadvantage of an organization.

3.7 Summary
Hallmarks of classical management are division of labor, unity of command, and chain of command. Ar-
gyris (1957) found that applications of these concepts tend to cause problems for the organization. Taylor
(1911) proposed the development of a body of knowledge on all-important tasks; there is one “best” way
for doing a task, and management and workers should work together to solve production problems. This
solved some production problems but contributed to others. Assortments of quantitative methods are
available to assist managers, and there are concepts to motivate workers to do the jobs that need to be
done. There are probably more examples of poor management than good. How, then, do we choose the
best management practices under a specific set of circumstances?

29
Engineering Management Handbook

3.8 Attempts at Integration

How does the behavioral information relate to the overall management knowledge base? Koontz (1961)
made an attempt to put much of this information into perspective. He formulated six “schools of man-
agement thought”. Six schools are a bit unwieldy. They can easily be narrowed to three:
1. The Management Process School (including The Empirical School). The Management Process
School describes management activities as planning, organizing, communication coordinating, and
controlling. Focusing on these activities will improve the skills of the individual manager and that
of the organization. Research by Mintzberg (1971) indicates that these activities do not adequately
describe what a manager does in organizations he studied. The “management activities” do seem to be
helpful in providing a conceptual framework to describe managerial activities. In other words, they
form a good starting point in describing management.
The Empirical School is promoted by the Harvard Business School. It uses case studies of actual
situations to train and educate future managers and organizational leaders. Principles of management
are formulated based on experiences either actual or resulting from studies of real situations. The case
study approach allows students to learn from managers’ successes and failures. Studies of cases allow
students to begin forming their own “principles” of management.
2. The Behavioral School (including both individual and group processes).This school infers that manage-
ment is getting people wanting to get the work done versus just expecting them to get the work done. Indi-
vidual theories include the motivation research of Herzberg (Motivators and Hygienes), Maslow (Hierarchy
of Human Needs), McGregor (Theory X and Theory Y), McClelland (The Urge to Achieve) and others.
Methods of achieving success through group or team processes has been developed by many,
including Blake and Mouton (The Managerial Grid), Likert’s “Four Systems”, and Katzenbach and
Smith (The Wisdom of Teams).
3. The Mathematical School (including all quantitative methods of solving management problems).
One part of this school includes optimization concepts such as linear programming, decision probabi-
listic theory.

Then the question becomes one of balance between the concepts and their appropriate relationship
to each other. The EM field is dominated by knowledge workers, professionals, and talented technical
personnel. Classical management concepts (as Argyris pointed out) were developed for unskilled workers
in an environment controlled by upper management.
Not included in the Schools of Management Thought is the impact of the organization structure.
Burns and Stalker (1961) discovered that organizational success showed a relationship between the level of
technology used and the type of structure employed. “Organic” structures were better adapted to orga-
nizations using moderate or high technology as a critical part of the enterprise. “Mechanistic” structures
were used by organizations producing commodities with low technology processes. This 1961 study was
done at a time when the use of low technology was a real option. Today, there are few organizations with
that luxury. The implication drawn is that the Human Behavior School is more important to most organi-
zations, especially to those employing the highest levels of technology.

3.9 What Is Working?

The most important concept to recognize is that in a technology-driven organization, the most valuable
asset is the collective knowledge and abilities of employees. If facilities are degraded or destroyed, they can
be rebuilt, at a significant cost, but it can be done. If key employees leave, they take significant amounts
of knowledge with them. This knowledge may be more difficult to replace than facilities as well as more
costly. It would be worthwhile to examine the practices of successful medium- to high-tech organizations.
Article after article has some combination of the following characteristics:
• Fayol and the Management Process School—Managers must be knowledgeable about the functions
of management and how the processes work.
• Scientific Management—There is a body of knowledge of the processes required to do the primary
work of the organization. Management must have this information and understand how to continu-
30
 Management Theory and Concepts

ally improve them. There are too many instances where company executives attempt to manage with
financial data without process knowledge.
• Behavioral Approaches—Capabilities of knowledge-workers must be harnessed to achieve success
in the era of the global economy. Willing, capable employees solve problems and create solutions and
opportunities. Talented workers must participate in decisions affecting their work. Decisions must
be made close to the situation by managers most familiar with the situations. Complex work is done
in teams that coordinate tasks as a normal team function. Training is expected of all employees. The
organizations cannot improve unless its members improve.
• Quantitative Approaches—Mathematical models and probabilistic approaches have much to offer in
the solution of complex problems but they are not a substitute for a positive, productive culture.
• Organization Structure—Flat organization structure, fewer levels, relatively high employee to
manager ratio is the norm. Management layers add control when flexibility is more valued. Imposed
controls are counterproductive. Team developed goals are part of an effective control system.

There are literally dozens of “systems” being used by industries that use some combination of these
factors. Some of the systems in current use are: Total Quality Management, Statistical Process Control,
Just in Time Inventories, Team Management, Management by Objectives, etc. Other companies, not
wanting to be left out, have attempted to use these systems with widely varying success. These systems in
themselves are no panaceas.
Educators in EM should not be tempted to base programs in the classical theories that have limited use
in the typical EM environment; nor should they be tempted to over-commit to the latest management “fads”
such as TQM. If properly implemented, some of these “fads” may be productive. If they are used in an appro-
priate structure with the knowledge of behavioral theories, their probability of success goes up dramatically.

3.10 Conclusion
There is a place for both classical management concepts, new techniques in EM curricula. Additional in-
formation on the nature of the external and internal environments has much to do with the way each is to
be applied. Other necessary ingredients for a successful management strategy are: an appropriate structure
and a knowledge of behavioral theories that underlie the new techniques.

3.11 References
Argyris, Chris, “The Individual and Organization: Some Problems of Mutual Adjustment,” Administrative
Science Quarterly, vol. 2, June 1957.
Burns, Tom, and Stalker, G. M., The Management of Innovation, London, 1961.
Fayol, Henri, General and Industrial Management, Pitman Books Limited, 1949.
George, Claude S., Jr., The History of Management Thought, Englewood Cliffs NJ: Prentice Hall Inc.,
1968.
Herzberg, Frederick, “One More Time: How Do You Motivate Employees,” Harvard Business Review,
January- February, 1968.
Koontz, Harold, “The Management Theory Jungle,” Journal of the Academy of Management, December
1961.
Maslow, Abraham H., “A Theory of Human Motivation,” Psychological Review, 1943, p. 50.
McGregor, Douglas M., “The Human Side of the Enterprise,” Management Review, November 1957.
Mintzberg, Henry, Managerial Work: Analysis From Observation, Management Science, vol. 18, no. 2,
October 1971.
Peters, Thomas J., and Waterman, Robert H. Jr., In Search of Excellence, New York: Warner Books, 1982.
Taylor, Frederick W., Shop Management, New York: Harper and Brothers, 1911.
Weber, Max, The Theory of Social and Economic Organization, McMillan Publishing Co., 1947. (A trans-
lation of the original document.)
Wren, Daniel A., The Evolution of Management Thought, New York: John Wiley and Sons, 1979.

31


32
 Managing Knowledge Workers

4
Managing Knowledge Workers

Jerry D. Westbrook, PhD

University of Alabama, Huntsville

Chris Edmonds
Roddies’ Code and Roddie Edmonds Foundation

33
Engineering Management Handbook

4.1 Introduction
It is generally agreed that management is the way an organization functions to get needed things done.
That is about all that is agreed on. Management has been an issue for thousands of years. The Egyptians
organized thousands of workers to build the pyramids and hundreds of impressive monuments. Romans
built aqueducts to provide its cities with fresh water. They built roads that are still visible today. Much of
the ancient accomplishments were built with slave labor or other kind of forced labor. This is the day of
the knowledge worker (Drucker, 1959). People who work with their brains are critical to the success of
most, if not all current organizations.
Koontz (1961) attempted to summarize most management schemes that are in use today. He called
them “Schools of Management Thought.”
They are the:
• Management Process School
• Empirical School
• Social Systems School
• Human Behavior School
• Mathematical School
• Decision Theory School

4.1.1 Attempts at Integration

How does the behavioral information relate to the overall management knowledge base? As discussed in
the previous chapter, Koontz (1961) made an attempt to put much of this information into perspective.
He formulated six “schools of management thought.” Six schools are a bit unwieldy. Three of the schools
have much in common with another the six schools can be narrowed to three. The original six schools are
described below.
1. The Management Process School—The Management Process School describes management as a
process that can be taught and learned and consists of such activities as planning, organizing, staffing,
leading, and communicating and controlling. Focusing on these activities will improve the skills of
the individual manager and those of the organization. There was an old argument over whether man-
agement can be taught or is something one is born with. This school infers that management princi-
ples can be taught and learned, and further, such principles can guide management decisions, thereby
making the organization more productive.
Typical management principles center around the following:
• Chain of Command—Communication is primarily vertical, guided by direct reporting relation-
ships.
• Division of Labor—Work is divided into relatively small tasks so that lower skilled workers can
be trained to do these tasks repetitively. This concept was developed during the Industrial Revolu-
tion where unskilled women and children were employed to do work of that time.
• Narrow Span of Control—Number of direct reports per manager. Span of control depends on
many factors such as the skill level and number of tasks supervised. The question was “how many
workers could one manager supervise”? Division of labor tends to reduce that ratio to as little as
an average of four workers to one supervisor.
• Unity of Command—One worker has one supervisor to minimize any confusion as whom to
take orders from.

Research by Mintzberg (1971) indicates that these activities do not adequately describe what a man-
ager does in organizations he studied. Mintzberg found more communication activities such as “figure-
head” and “spokesperson” and other activities such as “disturbance handler and resource allocator. The
“management activities” do seem to be helpful in providing a conceptual framework to describe manageri-
al activities. In other words, they form a good starting point in describing management.

34
 Managing Knowledge Workers

2. The Empirical School—The Empirical School is promoted by the Harvard Business School. It uses
case studies of actual situations to train and educate future managers and organizational leaders. Prin-
ciples of management are formulated based on experiences either actual or resulting from studies of
real situations. The case study approach allows students to learn from managers’ successes and failures.
Studies of cases allow students to begin forming their own “principles” of management.
3. Social Systems School—This school of management thought examines how workers perform in
groups or teams. The Hawthorne Experiments was the initial study for this way of looking at man-
agement. The Hawthorne Experiments showed that both external conditions such as lighting and
work rules affect productivity, but so does how teams relate to organizational goals. Achieving success
through group or team processes has been developed by many more researchers and theorists, includ-
ing Blake and Mouton (The Managerial Grid), Likert’s “Four Systems,” and Katzenbach and Smith
(The Wisdom of Teams).
4. The Human Behavioral School—This school infers that management is providing the environment
where people want to get the work done versus just expecting it knowledge workers work with their
minds. How they feel about their job influences their effectiveness. Individual theories of this school
include the motivation research of Herzberg (Motivators and Hygienes), Maslow (Hierarchy of Hu-
man Needs), McGregor (Theory X and Theory Y), McClelland (The Urge to Achieve) and others.
5. The Mathematical School—This school attempts to model a significant portion of an organization’s
systems. Mathematical techniques such as linear or non-linear programming are then used to opti-
mize each system to get maximum productivity. Modeling a significant portion of the organization’s
functions is a formidable task. Regardless, proponents of this school forge ahead. Several university
EM programs focus on this school.
6. Decision Theory School—Decision Theory seeks to determine strategies for unique situations likely
to be encountered by an organization. Decision rules that yield the best result for the broadest array
of situations are used to select the best strategies. Probability of the occurrence of each situation is
estimated and enters in the decision process. This school is prevalent during election years. Research
programs are considered depending on which candidate may win a major office. For example, if a
Democratic candidate should win, environmental research may be funded at a higher level. If the
Republican candidate should win, new weapons systems may receive additional funding. Both univer-
sities and private contractors use decision theory to assist in resource allocation for potential future
projects and project proposals.

4.1.2 Summary
Each school of management thought makes significant contributions to the study and practice of man-
agement. Many of these schools are taught without referring to the others. The case study approach is a
valuable tool for teaching management concepts. Linear and non-linear programming can solve problems
other schools cannot approach. It is important to know when any one school is applicable to a situation
existing in an organization.

4.2 How It All Works Together

4.2.1 The “Integrated” Part

All of the schools of management thought have contributions to make. Those of us with engineering
backgrounds can appreciate the availability of management principles. They provide a guide where there
is little management experience or training in our backgrounds. It is the “people” part where there are the
most unknowns. We have little preparation for dealing with talented professionals who know more about
aspects of their jobs than their supervisors. In order to put all of the schools together where they make
sense and provide a road map for our management careers, a model has been put together to assist in
this effort.

35
Engineering Management Handbook

The Integrated Management Model is shown below in Figure 4.1. It has five elements. The overall
interpretation of the model is that management is composed of management systems, the organization
structure and a people (knowledge worker) orientation. These are inter-related building blocks. The exter-
nal and internal business environments impact them.

Figure 4.1. The Five Elements of the Integrated Management Model

• External Environment • Internal Environment

• Customers » Management
• Competitors Management Systems » Employee
demographics
• Suppliers
(age, etc.)
• Community Org. Structure » Skills
• Regulators » Facilities
• Funding People Orientation » Structures (levels)
agencies

Integrated Management Model

4.2.2 The External Environment

The External Environment includes elements that impact the organization externally. They have influence
on an organization from the outside. They include:
• Customers
• Competitors
• Suppliers
• Community
• Regulators
• Funding agencies

Each of these must be known and dealt with strategically. For example, a strong customer may ver-
tically integrate and become a competitor. A supplier may give competitors better prices. Competitors’
research and development programs may yield a better, cheaper product. The community may support
a local organization or may attempt to put unfavorable regulations in place. Maintaining favorable local
relations is important. These entities are a fundamental part of a strategic plan. Threats and opportunities
are developed from an analysis of the external environment.

36
 Managing Knowledge Workers

4.2.3 The Internal Environment

The Internal Environment is made up of the internal resources that are available to allow the organization
to operate successfully. It must be determined if the resources available are adequate for the challenges the
organization faces. Composition of the internal environment include the following:
• The size and skill base of the workforce
• Key employee demographics
• Adequacy, age, and condition of facilities
• Management style and organization culture
• The facilities available to meet customer demands

A strategic analysis of the internal environment yields strengths and weaknesses. The resources avail-
able to an organization impact the management of that organization.

4.2.4 Management Systems

Management Systems are the way an organization gets things done. There are many types of systems:
everything from accounting, purchasing, and production to strategic efforts to coordinate work flow.
It is the latter that is of most interest. Many powerful and useful systems have been implemented
in the past twenty-five years. Further back, one of the first management systems was Management
By Objectives (MBO). Then Zero Defects, Total Quality Management (TQM), and Business Pro-
cess Re-engineering (BPR) became popular. Each had a half life of approximately two years and was
gone. They were good systems that didn’t last. Why? Many were never implemented very well.
Middle management gave lip service to some but never really supported them. Upper manage-
ment felt like the systems were for workers, not them. The structures of some organizations were too
complex to support the system. The reasons were systemic. The whole organization failed to adopt
and use the new system.
Lean Enterprise and Six Sigma are the management systems currently in use. Will they survive or be
discarded like the rest? That will be determined, but they can succeed if the organizations using them take
subtle but fundamental actions.

4.2.5 Organizational Structure

Organizational Structure is the silent force behind an organization’s success or failure. Structure can be
defined in several ways.
• The number of levels in the organization that communication must travel between and among members
• The number of employees reporting to one manager—this is called span of control
• How members of the organization relate to each other—formally or informally, vertically or omni-di-
rectionally

The higher the technology level in use, the faster communications must be. This is associated with
relatively flat structures. Complex, tall structures do not tend to thrive in rapidly changing business envi-
ronments.

4.2.6 People (Orientation)

Much of a knowledge worker based organization’s success depends on how the organization relates
to its employees. Most organizations proclaim that their employees are their most valued assets but
make decisions taking them for granted. This thought is inscribed on plaques on the walls of many
corporate headquarters that have moved most of their operation to another country. Acting in a
manner that generates trust allows a knowledge worker organization to succeed. In other words,
what hangs on the wall must happen in the hall. Failure to do so is the reason so many of the systems
mentioned above did not work very long.

37
Engineering Management Handbook

4.2.7 The Model

All elements of the model work together. Systems fail when they do not act in a coordinated manner. The in-
ternal environment must have the necessary resources. The external environment must present opportunities
and manageable threats. Appropriate systems must be used and the structure must support those systems.
The knowledge workers must be in an environment that challenges and appreciates their contributions.
• Integration of these elements is presented in the Strategic Management chapter.
• Assessment of appropriate structures is presented in the Organization Structure chapter.
• Concepts for managing and motivating knowledge workers are presented in the People Orientation
chapter.
• Integration of organization systems are discussed in the Systems Management chapter.
• Determining the conditions that allow teams to be effective is established in the Team and Group
Management chapter.

4.3 The “People” Orientation

The focus here is on the “People” block of the Integrated Management Model previously discussed. It is
the block that forms the base of the model. It interacts with both the internal and external environments.
Observations have been made that indicate that employee representatives tend to treat customers much
the same way as the organization treats them. The Organization Structure and Systems blocks can only
function with motivated and productive knowledge workers.
Today’s economy is being driven by knowledge workers. Inventors, innovators, process developers,
and process improvers are all knowledge workers. This is a term coined by Peter Drucker (1966). He
recognized that the world had changed from a manufacturing economy to an information economy where
manufacturing is an integrated element in a larger system.
Knowledge workers changed the rules of management. No longer can a manager observe a (knowl-
edge) worker and assess the effectiveness of the work being done, or even if the worker is working. When
work is mental, the value of the work may not be known for a significant period of time. If the knowledge
worker does not feel as if he or she is being treated fairly, rewarded adequately or supported appropriately,
the worker may not be able to concentrate on the complex issues at hand. This slowing of work may go
without detection.
It is more important than ever to understand behavioral concepts of management. The knowledge
worker wants to be a part of the organization, not just occupy a “slot” on the organization chart.
The model previously introduced will continue to guide the thought process in these chapters. In
this chapter, we will study the “People” Orientation, the least known and practiced of the concepts in
the model.

4.3.1 Background on Behavioral Approaches

The first years of the twentieth century saw a multitude of management concepts developed. A French
engineer, Henri Fayol, developed the first recorded principles of management. Frederick W. Taylor de-
veloped Scientific Management to increase productivity. Frank and Lillian Gilbreath developed methods
analysis and Henry Gantt developed the Gantt chart for scheduling large-scale projects. The idea that
management practice could improve productivity had many organizations actively searching for addition-
al management concepts that would give their organizations a competitive advantage.
Western Electric conducted a wide range of experiments with management practice at its Hawthorne
works. They experimented with lighting, work breaks, incentive systems, organization communication
and other concepts. The general conclusion reached was that the attitude of workers had much to do with
organization productivity. They did not reach firm conclusions on how to develop those positive attitudes.
Theories on workforce motivation required another thirty-five years to develop.
Harvard professor Chris Argyris performed a seminal study of many previous studies of management.
He compared management principles with normal personality development and concluded that modern
management tended to treat workers as children while expecting adult behaviors. The results of the study
38
 Managing Knowledge Workers

raised concerns about what is considered normal management practice. If there is any semblance of truth
in Argyris’ work, those guiding EM programs must be very careful about what they teach as being accept-
able practice.
After World War II, many behavioral theories were developed. The ill-fated “human relations” move-
ment spawned much research which has proved to be beneficial but not the total answer. We will explore
the major behavioral concepts that apply to knowledge workers by engineering managers. Concepts
developed by Douglas McGregor, Abraham Maslow, Frederick Herzberg and David McClelland will be
discussed in depth.

4.3.2 McGregor’s Theory X and Theory Y

Douglas McGregor was a Harvard professor and business consultant. He had many clients over an ex-
tended period of time. McGregor (1957) observed managers making assumptions about workers in their
decisions. He labeled these assumptions about workers as:
• Theory X—Assumes workers must be coerced to work, they are lazy and want security above all.
• Theory Y—Assumes that workers will exercise self-control to achieve organizational objectives to
which they are committed, seek responsibility and are innovative in solving organizational problems.

Neither assumption should be assumed to be good or bad. They were assumptions that formed the
bases of decisions. McGregor observed that management made these assumptions about its workers and
made decisions based on the assumptions. If the assumptions were in error, workers developed resent-
ment that management never understood. Problems arose when assumptions became reality. If a man-
ager assumed that workers could not be trusted and made decisions based on that assumption, workers
responded to how they were treated. They became like the assumption. Likewise, if there are assumptions
that the workforce strongly supports the organization, workers tend to value the relationship and respond
positively. McGregor observed that management made work rules governing access to facilities and adher-
ence to job descriptions as if the workers needed close supervision or could not be trusted. In most cases
the Theory X assumption became a self-fulfilling prophecy. Knowledgeable, capable workers acted as if
they needed to be told what to do when in fact they knew very well what needed to be done, many times
better than management. McGregor exposed hidden potential that organizations are missing due to their
unwarranted assumptions.

4.3.3 Maslow’s Hierarchy of Human Needs

Abraham Maslow was an American psychologist who theorized the five levels of the “hierarchy of human
needs” (1943), which are shown in Figure 4.2. He studied exemplary “healthy” people such as Albert Ein-
stein, Jane Addams, Frederick Douglass, and Eleanor Roosevelt and developed a theory of psychological
health predicated on fulfilling innate human needs in priority, culminating in self-actualization.

Figure 4.2. Maslow’s Hierarchy of Human Needs

self-
actualization
morality, creativity,
spontaneity, acceptance,
experience purpose,
meaning and inner potential

self-esteem
confidence, achievement, respect of others,
the need to be a unique individual
love and belonging
friendship, family, intimacy, sense of connection

safety and security

health, employment, property, family and social stability

physiological needs
breathing, food, water, shelter, clothing, sleep
39
Engineering Management Handbook

The first is the physiological level. Maslow observed that unless the physiological needs are met, no
other needs motivate an individual. Once these needs are met, then the individual seeks to meet safety
and security needs. When any need is substantially (approximately 85%) met, then individuals seek the
next higher level.
The higher level needs are more long-term than physiological needs. A good job and adequate hous-
ing normally meet the safety and security needs. After those needs are met, Membership (love and belong-
ing) needs will be sought. Because employment meets the Safety and Security needs, the new employee
will likely seek to join a group. A union will be attractive to many individuals. Others may be satisfied by
being a part of a close-knit project team or by participating in company-sponsored sports leagues.
After Membership needs are substantially met, we are motivated to seek Esteem needs; first self
esteem, then public esteem. At this point, it is not enough to be a member of an organization; we want to
be recognized as a leader or as a superior member in some way.
Finally, after Esteem needs are met, we desire to achieve Self Actualization. At this level we are con-
tributing not only to the organization but also to the good of the industry, mankind or some other higher
level good. We work to contribute and are recognized as an expert in some field.
According to Maslow, workers are motivated to achieve the next level in the hierarchy. The organi-
zation must recognize this and initiate efforts to assist this process. The organization benefits when its
members are advancing up Maslow’s Hierarchy. In 2011, researchers from the University of Illinois put
the hierarchy to the test. They found that fulfillment of needs strongly correlated with happiness. Between
2005 and 2011, via the Gallup World Poll, they surveyed people from 155 countries representing every
major region of the world. They concluded that while Maslow’s “hierarchy of needs” suggests that basic
needs must be fulfilled before higher needs are pursued, their study indicated that people benefit from sat-
isfying any of these needs in any order. They further reported that self-actualization and social needs were
important even when basic needs were unfulfilled. There are many cautions for management by under-
standing the Hierarchy. Management is most likely at one of the higher levels. Most workers are at a lower
level and seeking different needs than management. Workers may be seeking to fit in at the membership
level whereas management is dedicated to the organization at the self-actualization level. Management
must recognize where workers are on the hierarchy and assist them in reaching the next level. This should
promote better understanding throughout the organization. Positive actions by management should come
from this increased understanding.

4.3.4 Herzberg’s Motivators and Hygienes

Frederick Herzberg (1968), a noted industrial psychologist and pioneer of job enrichment, did research
on job satisfaction and published his findings initially in 1959. He used accountants and engineers in
his original study. He asked participants if they would think of a time they were very satisfied with their
jobs and identify what they considered were the causes and contributing factors to that satisfaction. He
repeated that question two more times. Then he asked for the factors associated with a time of significant
dissatisfaction. He also repeated that twice. He and his researchers recorded the responses and grouped
them according to similarities or “thought units.” Herzberg found one set of factors that primarily dissat-
isfied workers and another set that acted as satisfiers.
The satisfiers that Herzberg later called motivators were found to be:
• Recognition
• Achievement
• Possibility of growth
• Advancement
• Responsibility
• The job itself

The dissatisfiers later called hygienes were found to be:

• Working conditions
• Company policies
40
 Managing Knowledge Workers

• Relations with the supervisor

• Relations with peers
• Pay

Dr. Herzberg determined that because only motivators motivated employees, the best that could be
expected from hygienes was neutrality. Hygienes are primarily dissatisfiers but if are at a reasonable level,
they may be able to lead to neutrality in employee motivation.
If management observes a problem in employee motivation, consideration might be given to a higher
focus on motivators such as more equitable recognition or the opportunity to advance—that is to learn
how to accomplish more challenging tasks or to increase responsibility. Additional hygienes are short-term
and will likely make matters worse.
Herzberg observed that management frequently attempts to use hygienes to motivate the workforce
but an increase in hygienes only raises the anticipation of further increases. Costs rise but motivation and
productivity do not. The motivators are more difficult for management to apply but are not as expensive
as hygienes. He further observed that hygienes must be maintained at an appropriate level to prevent
dissatisfaction but they cannot motivate.
The Herzberg study has been replicated many times with similar results for subjects in different pro-
fessions, countries, and cultures. A study of blue-collar workers showed similar overall results but hygienes
were of more importance and motivators were of slightly less importance than in other Herzberg studies.

4.3.5 McClelland’s Need to Achieve

Harvard professor David McClelland (1966) studied workers involved in a plant shutdown in Erie,
Pennsylvania. A few of those laid off immediately set about to find jobs in nearby towns. They used their
connections to explore jobs in the closest cities. Most found equivalent jobs within six weeks.
The majority checked with their union several times; inquired if another company would buy the
company and reopen the factory and read the local want ads. They gathered in small groups to discuss the
situation to see if anyone knew of available jobs. The majority of this group was still unemployed after six
months.
McClelland studied and interviewed both groups. The first group was described as follows:
• They set challenges for themselves.
• They didn’t take chances, preferring to take action to solve problems rather than leaving them to
chance.
• They preferred to receive concrete feedback on how they were doing.

These workers were labeled nAchievers (nAch) because they exhibited a need to achieve. The second
group was described as follows:
• They stayed home for a while.
• The checked the newspaper for jobs similar to the ones they lost.
• They checked with state and federal and state employment agencies.
• They met in small groups to see if anyone had heard that the plant was reopening or if another com-
pany had bought it.

McClelland labeled this group as nAffiliators (nAff) for their need to affiliate. There was a group
discovered in another study—the nPower (nPow) group. They were motivated by the need for power
independent of achievement.
McClelland discovered that organizations tend to take on the characteristics of its workers. Some are
achievement oriented while some are more affiliating organizations. Organizations need to examine their
recent recruits to determine what kind of employees they are attracting. Organization productivity and
success are products of its workforce but may not be achievable if the organization has the wrong kind of
employees—nAffiliators, and fewer nAchievers.

41
Engineering Management Handbook

McClelland has had success in training company workforces to become nAchievers. Apparently, peo-
ple can be trained to become nAchievers.
McClelland further suggests that these concepts can be used to describe whole countries. There is
little doubt that the US was, at one time, populated by nAchievers. One can but wonder if that prepon-
derance of achievers is still in evidence.

4.3.6 Pink’s Motivational Concepts

After all of the preceding works of McGregor, Maslow, Herzberg, McClelland, and Skinner were com-
pleted; Daniel Pink (1995) continued research into motivation. His studies concluded that motivation is
stimulated by either external or internal forces.
External forces include incentive plans where workers are paid by the piece for their production.
Management pressure to produce is also an external factor. He found that as long as jobs are relatively
simple and required a minimum of mental activity, external motivation works as intended. But when a
modicum of mental activity is required by the worker, external motivators are ineffective.
He described work as being algorithmic or heuristic. Algorithmic work follows detailed instructions
that require discipline but little originality. Heuristic work requires mental activity to determine how to
proceed to accomplish a complicated task. This type of activity requires intrinsic motivation.
Pink (1995) found intrinsic motivation factors include autonomy, mastery and purpose. Skilled
knowledge workers require strong participation in determining the work to be done. Workers are more
committed to projects they helped define and plan.
Mastery includes the opportunity to improve skills required to do complex work to accomplish significant
goals. Purpose relates to the meaning of the work. The knowledge worker must believe in the value of the
project and that value must mesh with the worker’s own values. Pink cited many examples of successful
organizations using his concepts.

4.3.7 B. F. Skinner’s Operant Conditioning Theory

B. F. Skinner (1953) won the Noble prize for science in 1963 for his work on behavioral research. He
termed the results of his research The Operant Conditioning Theory.
His theory is as follows:
• Behavior that is rewarded tends to be repeated.
• Behavior that is ignored tends to be extinguished.
• Behavior that is punished generates a negative, fragmented response.

According to Skinner’s theory, if a manager sees a behavior that is favorable to the organization, the
behavior should be rewarded. The reward need not be financial, but that is not excluded. A favorable
comment, a write-up in the company newsletter, a mention before employees in the same department,
etc. can be used to good effect by the alert manager.
The second statement of the theory is significant. If a manager ignores positive accomplishment, he or
she runs the risk of “extinguishing” it. Negative behaviors may be ignored and thereby discouraged as long
as positive behaviors are rewarded. This does not mean ignoring violation of rules or failure to follow pre-
scribed methods or procedures. They are dealt with according to policy. It is assumed that many negative
comments and attitudes are an attempt to get attention. If the attention is not given, the behavior is likely
to be “extinguished.”
Behavior that is punished generates a negative, fragmented response. This is interpreted that the per-
son being punished perceives that the punishment is not deserved, above what others doing similar things
get. This type of punishment causes a backlash, perhaps not immediately but sooner or later. That is not
the intent of the action (punishment) but such is likely to happen. The manager has to always make sure
that the offense merits the punishment. The offender should expect the action taken.

42
 Managing Knowledge Workers

4.3.8 Multiple Generations in the Workplace

For the first time in history there are five generations working side by side in the workplace. Generation
Z, the newest and youngest generation, has begun working as summer and part-time employees. They
join the oldest generation, the Traditionalists, who continue to enjoy healthy lives and productive careers.
This age phenomenon adds to the complexity of managing people and teams. Since each generation is
influenced by different life experiences, managers need knowledge of the different generations (or gener-
ational intelligence) to effectively lead and motivate people. Here is a brief summary of the five genera-
tions.
1. Traditionalists—Also known as the Silent Generation was born between 1900 and 1945. They
comprise 2% of the workforce (Pew Research Center).
• They have experienced the Great Depression and World War II
• They prefer face to face meetings in structured workplaces, have a respect for rules, and seek hard
work with bright people
• They are loyal to their employer, tend to live frugal lives in the “burbs” and tolerate technology
though it is sometimes hard to grasp
2. Baby Boomers—Comprise 29% of the workforce and were born 1946 to 1964.
• They grew up during the Vietnam War, Woodstock, assassinations, landing on the moon, Civil
rights and the 1960s social changes
• These workaholics prefer adrenaline charged assignments, teamwork, innovation, and few rules
• They are optimistic in nature and work to live instead of live to work like their co-workers in
Generation Y and X
• Calculators and calendars are second nature including note cards and note pads
• It is estimated that 70 million baby boomers will retire over the next decade (Pew Research Center)
3. Generation X—Currently they are the second largest generational workforce at 34% of workers
and were born between 1965 and 1980.
• They experienced government corruption, environmental disaster, the fall of the Berlin Wall, the
Gulf War and the global AIDS epidemic
• They are self reliant latch key kids who are results oriented and fun
• They are realists with a strong sense of personal values many having experienced the good and
bad in relationships from divorced parents and mothers entering the workforce in droves
• They enjoy independence and operating as a free agent and often gravitate to being an entrepre-
neur rather than an employee
4. Generation Y—Also known as Millennials they are now the majority population in the workplace
with more than 36% and were born between 1981 and 1995.
• This group is tech savvy, socially conscious and were influenced by doting parents
• They are competitive, confident, diverse, and concerned with community service
• They are motivated by worklife balance, specific instructions, and work best when they get
R.E.S.P.E.C.T.
5. Generation Z—Also known as Linksters, 911’s or the Facebook Crowd and were born after 1995
and comprise 1% of the workforce.
• This young generation is very optimistic, has high expectations, is incredibly tech savvy, and are
social media wizards
• They are motivated by new technology, social activism, green causes and specific instructions
• They have the ability to text fast and efficient and program new technology before any of the
other generations

Each generation brings its own view of the world, which creates both threats and opportunities for
organizations. Effective managers will learn to work with these diverse groups by understanding work
styles, considering generational values, sharing perceptions, finding commonality, and learning from each
other.

43
Engineering Management Handbook

4.3.9 Summary
Maslow’s Hierarchy of Human Needs, McGregor’s Theory X and Theory Y, Herzberg’s Motivators and
Hygienes, and McClelland’s Achievers and Affiliators may at first glance seem to be independent concepts.
They are different approaches that are very complementary.
For example, Maslow’s Self Actualization and Esteem Needs are closely related to Herzberg’s Motiva-
tors. Theory Y is a natural way of thinking about such employees who tend to be nAchievers.
Those having membership and security needs tend to focus on hygienes, to be nAffiliators and per-
haps assumed to be described by Theory X. These overlaps are shown in Table 4.1.

Table 4.1. Overlapping Concepts

Maslow McGregor Herzberg McClelland

Self Actualization/Esteem Theory Y Motivators nAchievers
Membership/Security Theory X Hygienes nAffiliators

In order to motivate knowledge workers, Theory Y must be assumed; self actualization must be en-
couraged with opportunities; there must be a focus on motivators and achievement.
In order to limit dissatisfaction, membership activities should be assisted; Theory X assumptions must
be avoided and hygienes should be provided at as high a level as can be reasonably afforded.

4.4 People Orientation—Team Management

The “people” part of management is too big to attempt in one chapter. The focus of this module is man-
aging knowledge workers in groups or teams. The background for this module is a meta-study by Chris
Argyris (1957). He reviewed literally hundreds of management studies that linked management practices
with human behavior.
Most organizations use some version of the standard management practices described in the Man-
agement Process School of Management Thought described in the first module. This School espouses the
chain of command, unity of command, division of labor, vertical communication channels, authority in
accordance with responsibility, etc. Argyris (1957) wrote perhaps the most accurate critique of these man-
agement principles. First, he researched the common characteristics of personality development:
1. Man develops from a passive infant to an increasingly active adult
2. Goes from a state of dependence to independence
3. Changes from simple behavior to complex with maturity
4. From shallow interests, man develops deep commitments
5. Goes from short time frames to long time frames—more affected by the past than the future
6. Develops from family subordinate to peer or leader
7. Goes from a lack of awareness of self to the development of self control.

Argyris further identified four common classical organization concepts and compares the result of
using them with the traits of normal personality development listed above.
• Division of labor—The individual sells skills rather than total abilities
• Chain of command—This tends to make individuals dependent, passive
• Unity of direction—This is leader oriented, not a function of workers
• Span of control (usually 4 to 8)—Adds levels to the organization, thus increases dependence

Argyris hypothesized three results of using classical organization concepts:

1. There is a lack of congruency between normal personality development and classical organization
concepts.
2. This lack of congruency generates frustration, short-term perspective and conflict.

44
 Managing Knowledge Workers

3. The result will be inter-subordinate hostility, rivalries, and a focus on parts of the organization rather
than the whole.

If there is any truth to these hypotheses, and many believe that there is, there must be management
concepts that use the whole ability of individuals that will not generate such problems. The concepts that
use total abilities are discussed in the next sections.

4.4.1 Likert—An Integrating Principle

Rensis Likert (1961) was an international management consultant, theorist, and author. Three of his
noteworthy concepts will be discussed in this section.
• Principle of Supportive Management
• Team Management
• Four Systems

He documented the concepts used by the most successful organizations and continuously compared
them with those of less successful organizations.
He concluded that high producing organizations and their managers managed differently than man-
agers of low producing organizations. Managers using classical management theories were less successful
than those managers who managed in a way that will be discussed.

4.4.2 Characteristics of High Producing Organizations

Likert studied the management of many organizations and characterized how they operated and their
success over a period of time. His findings are noted in a concise form below.
• There are favorable attitudes of members of an organization toward superiors, toward the work, to-
ward the organization. There is mutual confidence and trust throughout the organization.
• There is a high sense of involvement in the achievement of high goals and there is a sense of dissatis-
faction if goals are not met.
• The organization effectively harnesses all of the major motivational concepts including:
• Ego motives
• Security motives
• Creativity and curiosity
• Economic motives

Other characteristics of high producing organizations are:

• The organization consists of a tightly knit, effectively functioning social system.
• Employees want to work together, solve problems and make the organization successful.
• The system is made up of interlocking groups with a high degree of group loyalty and with favorable
attitudes and trust between subordinates and superiors.
• Measurements of organizational performance are primarily used for self guidance rather than for
super-imposed control. (This is more of a Theory Y approach within an nAchieving workforce.)

4.4.3 Characteristics of Low Producing Organizations

• Motivation is achieved by the exercise of control through authority. (Traditional management)
• Jobs are organized, methods are prescribed, standards are set, performance goals and budgets are set
by management. (Remember Argyris’ findings on worker dependence and the result?)
• Compliance is sought through the use of hierarchical and economic pressure. This is a Theory X
assumption that this is the only way to get workers to produce.

In short, those managers who demand success don’t get it. Those managers who allow employees to
be successful are in successful organizations.
45
Engineering Management Handbook

High Producing Managers

Likert also looked at individual managers and assessed their effectiveness. Characteristics of the high pro-
ducing managers are shown first.
An employee in an productive organization holds the following perceptions toward his or her superior:
• He or she is supportive, friendly, helpful, rather than hostile.
• He or she shows confidence in my integrity and ability.
• He or she has high expectations of subordinates.
• He or she coaches and assists employees whose performance is below expectations.

This type of manager is with his or her employees rather than just being above them. This manager is
heavily involved with both the work and the employees.
The manager’s work (in high producing organizations):
• Plans and schedules work, trains employees, supplies subordinates with required material, tools and
information required for them to be successful
• Provides technical competence when needed
• Develops subordinates into a working team, uses participation and group leadership practices.

The Integrating Principle

This concept is somewhat vague but that is similar to the way Likert wrote it. It is still possible to grasp
the central concept.
Subordinates react favorably to experiences that they feel are supportive and contribute to their sense
of importance and personal worth. Employees react unfavorably to situations that are threatening and
decrease their dignity and feeling of personal worth. The employee perception must be positive in such
work experiences.
The leadership and other processes of the organization must ensure, that as much as possible, that in
all interactions and relationships, each member, in light of his background, values and expectations, views
the experience as supportive and one which builds and maintains his or her sense of personal worth and
importance.
The worker must feel that he or she is making a worthwhile contribution to the organization and that
contribution is recognized by the organization.

4.4.4 Team Management

High producing organizations as described by Likert communicated differently than low producing ones.
Likert observed and wrote of this and characterized the pattern of communication as Team Management.
Each manager leads a team but is a member at the next higher level. This manager is thus a linking pin
between levels. That is only true if the group functions and communicates as a team. Most work groups
do not do that. Both normal work groups, which operated with managers working one on one with sub-
ordinates, and team managers are depicted in Figure 4.3.

46
 Managing Knowledge Workers

Figure 4.3. Traditional Organization Structure

C
B D
C

The Traditional Organization Structure

• The boss has a one-on-one relationship with each subordinate.
• Each subordinate attempts to use whatever means available to extract more resources from the boss
than other subordinates receive.
• Communication from subordinate to boss is highly filtered. The boss hears only what the subordinate
wants the boss to know in order to receive favor for his or her unit.
• There is mistrust between subordinates who each consider that other subordinates are better treated.
• The good of the organization as a whole receives little consideration. Decisions are made in a vacuum
with each unit competing for resources.
• Each unit staffs for the maximum contingency. There is little sharing of resources between units.

This is the way unenlightened managers deal with their employees. This is frequently true organiza-
tion wide. They know no other way of supervising.
A simplified representation of a team-based organization is shown in Figure 4.4. Characteristics of a
team-based organization include:
• The good of the organization as a whole is easy to relate to.
• Communications are with the whole group, filtering is not possible.
• Vigorous debate focused on the issues generates better decisions.
• Sharing of resources is looked upon with favor as it allows unnecessary unit cost to be reduced by
loaning employees to units in greater temporary need.
• Decisions are better supported. Even those whose recommendations are not followed had input
and know the other positions and can generally support the decision.

47
Engineering Management Handbook

Figure 4.4. Team-Based Organization

The results of an organizational communications study was released several years ago. Typically there
is communication loss from the top level down.
When top management communicates:
• Middle management receives 67%
• General manager receives 50%
• Supervisor receives 33%
• Worker receives 20%

This indicates that those at the base of the organization receive very little accurate information that
emanates from the top. Likert’s Team Management concept seeks to improve on this kind of organization
communication. Another significant question is: “What are the similar percentages going from the bot-
tom of the level to the top?” That is easy. It doesn’t happen, so it is zero. Team Management can improve
that situation also.

4.4.5 Likert’s System IV

Rensis Likert (1961) developed management systems through observation and determined that only Sys-
tem IV achieves normal productivity goals consistently. He developed the model shown next.

Likert’s Four Systems

• System I: Exploitive - Authoritative
• System II: Benevolent - Authoritative (we have your best interest at heart)
• System III: Consultative - Democratic
• System IV: Participative - Democratic

Likert’s systems are evaluated in six areas: (see Figure 4.5)

1. Leadership processes—The extent to which superiors have confidence and trust in subordinates.
2. Character of motivational forces—This varies from physical security and economic needs to use of
ego and achievement needs which come from group achievement.
3. Character of Communication Process—The amount and direction of communication aimed at
achieving organizational objectives.

48
 Managing Knowledge Workers

4. Character of Interaction Influence Process—How do different levels of an organization work together

to solve problems and achieve objectives.
5. Character of Decision-Making Process—At what level in the organization are decisions made? Pro-
ductive organizations make them throughout the organization.
6. Character of Goal Setting—Where are goals established and from what level do orders normally come?

Figure 4.5. Likert’s Basic Model

Causal Variables Intervening Variables End Result Variables

Management systems Attitudes Productivity, profits

No one has actually surveyed the population of current organizations, but it is widely believed that
most organizations are somewhere in System II. A few organizations can be described as using System III.
Organizations using System IV are rarely found.
Likert believed that in assessing the value of an organization that the value of the human asset must
be assessed. A layoff is a liquidation of a valuable asset just as surely as selling equipment, land, facilities or
inventories; except that the latter can be easily replaced and the human asset cannot.
Valuation of the human asset involves:
• Recruiting costs
• Training costs
• Familiarization costs
• Capability costs
• Development costs

All these are lost when human resources are liquidated. Many of these costs will have to be paid again,
at a higher rate, without the guaranty that the work will be done as well.
Likert’s philosophy: Attitudes and skill generate productivity. He observed that the management
systems that an organization uses drive attitudes. Attitudes generate productivity and profits. In other
words, attitudes impact productivity and profits. System IV obviously has much in common with Theory
Y, Self-Actualization, Motivators, etc.

4.4.6 Blake and Mouton’s Managerial Grid

In the late 1960s, Dr. Robert Blake of the University of Texas studied the management of a major corpo-
ration at their corporate headquarters. The commonly accepted theory of the day was that management
style cold be categorized on a continuum from autocratic to participative. Blake and Mouton (1964)
sought to either validate this theory of develop a new one.
They observed that some managers were very successful and managed productive units. They were
observed to have similar management styles. Other managers that were in charge of less successful units
also had similar management styles. Neither management style fit into the autocratic-participative con-
tinuum. Further observations were made of some successful managers who were transferred to units with
productivity problems. These units improved over a period of time to be similar to the unit the successful
managers had left.
Blake and Mouton concluded that management style was a major influence on productivity. Prob-
lems with a particular group of task difficulty were overcome with the new management style. Next, Blake
and Mouton’s challenge was to describe the style of successful managers in a way that could be adaptable
by others. The Managerial Grid is the theory that they developed to describe the results that they had
observed, which include.
• High performance groups were headed by similar managers
• Some low performance managers focused on performance
• Some low performance managers focused on making employees “happy.”
49
Engineering Management Handbook

These managers:
• Used teams extensively
• Confronted issues to resolve conflict
• Got extensive input from employees
• Developed employee capabilities.

4.4.7 The Managerial Grid

There was not sufficient difference between positions to define all positions on a 9x9 matrix. As shown in
Figure 4.6 there are five basic positions where adequate to demonstrate the major management styles in
common use.

1-1 Avoids decisions and uses “policies” instead of positions. Do such managers really exist? Unfor-
tunately, they do. They hide behind policies and avoid confrontation. They certainly aren’t oriented to
toward production either. They stay in their offices a lot. Conflict resolution is to ignore the conflict.

1-9 The country club manager tries to keep people happy. These managers hope that production will
take care of itself if employees are “happy”. They are attempting to meet goals by manipulating employees.
Conflict resolution is to sweep problems “under the rug.”

9-1 This is the autocrat position. He solves problems by edict. It is production first. People are hired
to get the work done. Conflict resolution is “my way or the highway.”

5-5 This type of manager views people and production equally but is not strong on either. This is a
bureaucratic, status-quo position. There are more managers in this position than all others according to
standardized tests. They tend to solve problems by compromise.

9-9 This is the team manager position. She uses teams to gather and share information and to identify
and solve productivity problems. There is a natural balance between people and production. She works to
solve problems by confronting them.

Figure 4.6. The Managerial Grid

1,9 9,9
concern for people

5,5

1,1 9,1
concern for production

50
 Managing Knowledge Workers

Results
Only managers with strong concerns for both people and work were in high productivity units. The
managers:
• Used teams extensively
• Confronted issues to resolve conflict
• Received extensive input from employees
• Developed employee capabilities

4.5 Summary
Notice that all of the studies that have been discussed reach similar conclusions. Argyris shows that tradi-
tional management doesn’t work very well. As shown in Table 4.2, efforts to get high productivity under
classical principles are not successful. Likert’s system IV had similar constructs and results as Blake and
Mouton’s Managerial Grid 9-9 position.

Table 4.2. Theory of Motivating Knowledge Workers

How is all this related?

Systems III, IV, 9-9 on Managerial Grid
Theory Y, Self Actualization, Motivators, nAchievers
Self Esteem
Systems I, II, 1-9, 9-1, 1-1 on Managerial Grid
Hygienes nAffiliators
Safety, Security

It should also be noted that concepts in this chapter correlate with those in Chapter 2. Managers
making a Theory Y assumption and a focus on motivators will likely use Likert’s System IV and have a 9-9
management style on the Managerial Grid.

4.6 References
Argyris, Chris, The Individual and Organization: Some Problems of Mutual Adjustment, Administrative
Quarterly, vol. 2, June 1957.
Blake, Robert, and Mouton, Jane, The Managerial Grid, Houston: Gulf Publishing Co., 1964.
Drucker, Peter, The Effective Executive, The Definitive Guide to Getting the Right Things Done, Harper Busi-
ness Essentials, 1966.
Fry, Richard, Millennials Surpass Gen Xers as the Largest Generation in U.S. Labor Force, Pew Research
Center, 2015.
Herzberg, Frederick, “One More Time: How Do You Motivate Employees,” Harvard Business Review,
January- February, 1968.
Koontz, Harold, “The Management Theory Jungle,” Journal of the Academy of Management, December
1961.
Likert, Rensis, New Patterns of Management, McGraw Hill, Inc., 1961.
Maslow, Abraham H., “A Theory of Human Motivation,” Psychological Review, 1943, p. 50.
McClelland, David, “That Urge To Achieve,” Think Magazine, 1966 by the IBM Corporation.
McGregor, Douglas M., “The Human Side of the Enterprise,” Management Review, November 1957.
Mintzberg, Henry, Managerial Work: Analysis From Observation, Management Science, vol. 18, no. 2,
October 1971.
Pink, Daniel H., Drive, The Surprising Truth About What Motivates Us, The Penguin Group, 1995.
Skinner, B. F., Science and Human Behavior, New York: McMillan, 1953.
Tay, L., and Diener, E., Needs and subjective well-being around the world, Journal of Personality and
Social Psychology, 2011.
51


52
 Types of Intellectual Property

5
Types of Intellectual Property

Donald W. Merino
Transpacific Advisors

53
Engineering Management Handbook

5.1 Introduction
There are at least four types of intellectual property that are commonly used today. They are copyright,
trademarks, trade secret, and patents. In order to understand the value of patents and how they fit into
the landscape, a review of the various types of intellectual property is required.

5.2 Copyrights
The first type of intellectual property is copyrights. A copyright is a legal right created by the laws of a
particular country. This grants the creator of the work exclusive rights to use and distribute this work.
Typically, this is a limited time right. The right is applicable to any express representation of a creative
work. It can be shared among multiple authors, where each one has the right to use the licensed work.
These are called “rights holders.”
Other rights frequently included in copyrights include control over derivative work, distribution,
public performance and what is called “moral rights”. Moral rights are unique and typically seen in
Europe but are now becoming more common around the world. Basically, a moral right is a right that
preserves the integrity of the work and bars alteration, distortion or mutilation of the work. Much of
the fight over the colorization of black-and-white films was a battle over “moral rights.”Copyrights came
about with the invention of the printing press. The legal concept originated in England in the 17th centu-
ry with the “Licensing of the Press Act” in 1662, which was an act by Parliament. Since then the law has
been further modified and codified.
One of the best examples of where copyright protection is found is in the U.S. Constitution. In
1787, the U.S. Constitution included a clause:
“to promote the progress of science and useful arts” found in Article 1, Section 8, Clause 8 of the U.S.
Constitution. This clause gives Congress the right:

“to promote the progress of science and useful arts, by securing for limited time to authors and inventors
the exclusive right to their respective writings and discoveries.”

This clause in the U.S. Constitution is the basis of copyright and patent law.
What is the justification for creating copyrights? It is to enable the creators of intellectual property to
create wealth to financially support themselves and, hopefully, to continue to create new works. Examples
of copyrighted materials include songs, paintings, books, movies and photographs. One distinction of
copyrights compared to patents for example, is that copyrights do not cover the idea or the information
itself but rather how those are expressed. For example, in a typical story where boy meets girl, boy loses
girl, boy gets girl back, the “Arc of the Story” is not copyrightable but the actual story and characters are.
Since copyrights are protected by law, there are exclusive rights usually attached to them. These in-
clude the right to:
• Produce copies and to sell those copies
• Import or export the work
• Create derivative works
• Perform or display the work publicly
• Sell the rights to others
• Transmit or display the work by radio or video

Because of these rights, copyright holders can become extremely wealthy. For example, it is often
the songwriter who is the wealthiest member of any band. The Beatles member, Paul McCartney, is far
wealthier than Ringo Starr because he wrote many of the famous songs that the Beatles and others have
performed. Every time you hear songs like “Hey Jude” or “Let it Be” on the radio you can be assured that
Paul McCartney is obtaining payment for that broadcast. Interestingly, the richest songwriter today is
Andrew Lloyd Webber who rarely performs at all but only writes the songs that others perform.
The duration of copyrights varies by country. In the United States copyrights have increased in duration
initially starting at 28 years and currently running the life of the author and +70 years after the author’s death.
54
 Types of Intellectual Property

In the case of joint works, a copyright lasts 70 years after the last of the joint owners dies. And in the case of
what is called “anonymous works” or “works made for hire” the term is 120 years from the year of creation.
For many years software inventions were considered un-patentable and instead were protected by
copyright. As the wealth of software companies grew software became patentable. It wasn’t until 1996
that the U.S. Patent and Trademark Office (USPTO) issued guidelines for examining computer-related
patents. Over the last 30 years the number of patents granted per year in USPTO class codes that relate to
computer-implemented inventions has grown from less than 1,000 to over 17,000.

5.3 Trademarks
The next form of intellectual property is the trademark. A trademark is a recognizable sign or design or an
expression that identifies a product or service from a particular source. Most sources agree that trademarks
were first used by blacksmiths when they made marks to identify which blacksmith made which sword.
During the reign of Henry III in 1266, the English Parliament required all bakers to use a distinctive
mark for the bread they sold. This could probably be considered the first trademark legislation.
Modern trademark laws began to emerge in the late 19th century particularly in France when they
passed the “Manufacture and Goods Mark Act.” England in 1862 passed a similar law called the “Mer-
chandise Marks Act.” In the United States Congress first attempted to establish a trademark system in
1870 relying on Article 1, Section 8, Clause 8 of the United States Constitution. The U.S. Supreme
Court struck down this first attempt because it did not agree that a trademark would promote the prog-
ress of science and useful arts. In 1881 Congress instead passed the new trademark act that was pursuant
to the commerce clause powers. This basic act has been modified through the years.
The law considers trademark to be a form of property. These rights are established through actual use
in the marketplace or through registration with a trademark office. Depending on the country, a trade-
mark can be established by either or both means. Some jurisdictions do not recognize trademarks through
use of the trademark. In other countries the holder of the right will not be able to enforce his or her right
through trademark infringement proceedings unless the trademark is registered. In the United States the
trademark rights registration process requires the examination of the trademark for compliance.
Once a trademark is obtained there are a series of rights that are conferred upon the owner. These
rights typically include the right to exclusively use of the mark for products and services created. In
most countries the law also allows the owner of a trademark to stop others from using his or her mark in
relation to products or services that are identical or very similar to his or her product. The test is usually if
there is any sort of confusion on the customer side as to the source of the product. One interesting aspect
of trademarks is that trademarks must be maintained by actual use. In most countries if the trademark is
not used for five years it is considered to be abandoned. Additionally, in many jurisdictions it is required
that the trademark owners defend their trademark from other infringers.
When the author was working at Intel Corporation he had a front-row seat to one of the best ex-
amples of trademark and trademark enforcement. One of the issues for Intel was that, as a component
manufacturer, its ability to distinguish its product was limited. For example, how many of us open the
computer we use and look inside at the chips? Not many, unless we are engineers.
In 1991 Intel created the “Intel Inside” brand program. Many case studies can be found that describe
the details of this program and its success. Intel then set about to convince the computer manufacturers
that if they featured an Intel microprocessor the customer would see value in that. Part of the strategy was
to “co-market” with their customers to highlight the “Intel Inside” brand.
Separately, Intel also created very aggressive trademark enforcement. Intel was able to establish
through its protection process that anything that was “blank - Inside” would create customer confusion
and therefore would need to change its trademark. For example, there was a group in California called the
“Yoga Inside Foundation,” which provided yoga instructions to at-risk juveniles. Intel was concerned that
“yoga inside” would likely cause confusion and/or dilute Intel trademark rights. Ultimately, “Yoga Inside”
changed its name to “Yoga on the Inside” and reached an agreement with Intel to stop legal action.
Why would Intel risk the wrath of the public by being so aggressive? The answer is the value of the
Intel trademarks. The Intel name and the Intel Inside program were considered one of the four pillars that
55
Engineering Management Handbook

kept Intel’s margins so high. The Intel trademark and brand recognition was probably the strongest pillar
of Intel’s business. While there are many ways to measure the value of the brand, Intel has for many years
been one of the top 10 most valuable brands. In 2013, Intel was listed as the ninth most valuable brand
and the value of the brand was in excess of $37 billion. This would make up between 20% and 30% of
Intel’s total market capitalization, a very significant number indeed.

5.4 Trade Secrets

Trade secrets are the next form of intellectual property discussed. What is a trade secret? A trade secret is
an invented formula, practice, process, design or method or information that is not generally known of
which the business obtains an economic advantage from.
There are many examples of trade secrets in our daily life; one of the most famous is the recipe for
Coca-Cola, Kentucky Fried Chicken, and even WD-40. But it is important to note that not all trade
secrets are recipes. Other trade secrets can be the methods and practices that a company uses to make its
product.
In some countries trade secrets are referred to as confidential information. These trade secrets are
generally referred to as classified information in the U.S. because that designation is typically reserved for
governmental secrets. How trade secrets are defined often depends on the country or jurisdiction in ques-
tion. For example, in the U.S., a trade secret is defined under 18 U.S.C. Chapter 1839:
“the term ‘trade secret’ means all forms and types of financial, business, scientific, technical, eco-
nomic, or engineering information, including patterns, plans, compilations, program devices,
formulas, designs, prototypes, methods, techniques, processes, procedures, programs, or codes,
whether tangible or intangible, and whether or how stored, compiled, or memorialized physically,
electronically, graphically, photographically, or in writing if—
• (A) the owner thereof has taken reasonable measures to keep such information secret; and
• (B) the information derives independent economic value, actual or potential, from not being
generally known to, and not being readily ascertainable through proper means by, the public;”
Similarly, the 1996 Trade-Related Aspects of Intellectual Property Rights (TRIPS) agreement on
trade-related aspects of intellectual property rights that define trade secrets as follows:
“Is secret in the sense that it is not, as a body or in the precise configuration and assembly of its
components, generally known among or readily accessible to persons within the circles that normal-
ly deal with the kind of information in question;

Has commercial value because it is secret; and

Has been subject to reasonable steps under the circumstances by the person lawfully in control of
the information to keep it secret.”

There are number of similarities between the two definitions.

In 1970s the US Supreme Court allowed states to freely develop their own trade secret laws. In
response to this many states adopted the Uniform Trade Secrets Act (UTSA). This law has been further
amended and currently 47 states in the US have adopted it as the basis of their trade secret law.
Thus, in the U.S. trade secret law is a law both on a state-by-state basis and at the federal level. At the
federal level the US developed the Economic Espionage Act of 1996 (18 U. S. C. Chapters 1831-1839).
This is a law that has used the example definition of a trade secret above.
Most countries in the world are signatures to the international agreement on TRIPS. TRIPS is an in-
ternational agreement administered by the World Trade Organization (WTO) and attempts to set a series
of standards for intellectual property regulation for all members of the treaty. While the TRIPS agreement
calls for standardization for copyright, patent and trademark protections, it also calls for the protection
of undisclosed information in Section 7 Article 39. While the TRIPS agreement is rather general, it does
form the basis for protection of trade secrets throughout the world.
56
 Types of Intellectual Property

So what does one have to do to create a trade secret? Distinguished from other types of intellectual
property there is no registration requirement for a trade secret. Rather it is up to the company or individual
to keep the information secret and to protect it. When one says that it must be kept confidential, it does not
mean that the information cannot be shared, but that a company must take care in disclosing that infor-
mation. For example, the use of non-disclosure agreements and non-compete agreements helps companies
disclose trade secrets to others, for example vendors and employees, while maintaining their confidentiality.
Often companies need to decide what information should be patented and what information should
be kept as a trade secret. If a trade secret is successfully kept as a secret there is no time limit imposed and
the trade secret can last for an indefinite period of time. But a trade secret can be legally reverse engi-
neered and/or if that trade secret becomes common knowledge due to other people’s research, then it
will no longer be a trade secret. For example, the recipe for Coca-Cola has been kept secret for over 100
years and to date no one has been able to reverse engineer the Coca-Cola recipe. Interestingly, in 2006 a
Coca-Cola employee tried to sell the recipe to Pepsi. To Pepsi’s credit they notified Coca-Cola officials and
the employee was arrested.
So, while recipes are a clear example of a trade secret, what are some of the other examples? Certain
methods and processes can be considered trade secrets. For example, how the New York Times determines
which books will be on its bestseller’s list is a method that the New York Times considers a trade secret.
Additionally, many kinds of business information can be considered trade secrets; for example, how a
company determines its pricing for certain products, a company’s marketing strategy or customer lists.
Also, designs and methods can be considered trade secrets.
When a trade secret is stolen or misappropriated there are number of penalties that can be imposed.
Many states as well as the U.S. federal law include both imprisonment and fines for stealing trade secrets.
Additionally, the federal law and many state laws also call for forfeiture of any profits obtained from the
stolen trade secret. This law applies not only to the person who steals the trade secret, but also to anyone
who tries to buy the trade secret knowing that it was stolen. In many trade secret cases today the person
who is the violator is the person who wants to sell the stolen trade secrets.
One interesting problem that most companies face is the question “should I file a patent on an inven-
tion or should I keep it a trade secret?” There are pros and cons to both courses of action. Much depends
on the product and some depends on the ease of reverse engineering. In the chemical and pharmaceutical
industries most companies elect to patent inventions because reverse engineering is relatively simple. In
the electronics industry most companies chose a mixed strategy. In other words, companies will patent
certain inventions and at the same time keep some inventions as trade secrets. The more complex the
product the more inventions are usually needed to make the product work.

5.5 Patents
What is a patent? According to the World intellectual Property Organization (WIPO), a patent is an
exclusive right granted for an invention. The invention is a product or process that provides, in general, a
new way of doing something or offers a new technical solution to a problem. To receive a patent, techni-
cal information about the invention must be disclosed to the public. The principle of a patent is that the
patent owner obtains from a government agency the exclusive right to prevent or stop others from using
the patented invention. In other words, patent protection means an invention cannot be commercially
made, used, distributed, imported or exported by someone without the patent owner’s consent. Patents
are territorial rights that are the exclusive rights applicable in the country or region where a patent has
been filed and granted. Generally, a patent is granted for a limited period of time, mostly 20 years from
the date the application is filed.
Why do countries grant patents? In general it is because patents represent a bargain between the govern-
ment and the inventor. That bargain is: the inventor is willing to donate his or her invention to the public;
the government, in return, will grant a monopoly right for the invention. Why does this make sense? It
makes sense because throughout history there have been technologies that have been lost to mankind. These
include Stradivarius violins, Damascus steel, Roman cement and a number of herbal drugs. Let’s look at a
few of these cases.
57
Engineering Management Handbook

Stradivari violins are considered some of the best musical instruments ever built. Approximately 1000
of these were produced by the Stradivari family between 1650 and 1750. Today many of these violins are
worth millions of dollars and there are only around 600 of these instruments left. The name Stradivari is
one of the most prized brand names even today. The problem is that the technique for building a Stradi-
vari violin has been lost.
Another example is Roman cement. Modern concrete was developed in the 1700s and is a simple
mixture of cement, sand, water and rocks. But this recipe, invented in the 1700s, was not the first time it
was invented. In fact, concrete was widely used by the Romans over 2000 years ago. The Roman mastery
of concrete allowed them to build many of the famous structures that we associate with the Romans like
the Coliseum, the aqueducts and the Roman baths. Like many technologies of the Greeks and Romans
this technology was lost during the dark ages. Why it was lost we will never know; some believe it was
a trade secret of stonemasons. What is the most interesting is that Roman cement has certain qualities
that are different and better when compared to traditional cement that we use today. Structures like the
Coliseum in Rome have managed to last for thousands of years while many modern structures are known
to wear down much faster. Many believe that this is the result of different chemicals the Romans added to
their cement, including things like milk and blood. It is believed that these different chemicals allow the
material to better expand and contract with the heat and cold. Unfortunately, we will never know because
the written recipe of the method is lost.
The history of patents can be traced back to the concept of “Letters Patent.” A “Letters Patent” was a
royal decree that granted something to somebody. Throughout history, Letters Patent were used to grant
property to individuals. Additionally, in the 1300s Edward III decided to grant “letters of protection” to
various artisans to encourage them to come to England and develop their skills within England.
The first evidence of a “letters of protection” appeared in 1331 when King Edward III granted one
to John Kempe, a Flemish weaver, as part of the effort to encourage foreign artisans to settle in England.
Apparently, other craftsmen were encouraged to immigrate to England and were offered similar privileges
that included clockmakers from Delft and craftsmen in the metalworking field who could help manufac-
ture cannons and gunpowder. Another example was the grant by Henry VI in 1449 to John of Utynam,
a Flemish man, who was skilled in the art of making stained-glass. Other examples outside of England
include a patent awarded by the Republic of Florence to an architect for a barge and hoisting gear that
was used to carry marble along the rivers. That patent was a three-year patent.
By the 1450s the growing city state of Venice began issuing patents for new and inventive devices; the
period of protection was for 10 years and was mostly in the field of glassmaking. As these Venetian crafts-
men began emigrating to new countries they sought similar patent protection in their adopted countries.
The king of France introduced the concept of publishing a description of the patent a century later.
The English patent system evolved from those humble beginnings into the first modern recognizable
patent system. In the 16th century it was common for the British crown to grant letters of patents or mo-
nopolies to their favorites or to people who were prepared to pay for them. The power to grant monopo-
lies was used to raise money for the crown and was widely abused as the king granted patents to all sorts
of common goods like salt and starch. After a certain amount of public outrage, James I of England was
forced to revoke all existing monopolies and declared that the grant of “Letters Patent” could only be used
for “projects of new invention.” This was incorporated into the “statute of monopolies,” which was passed
in 1624. While the statute has been considered a key foundation of patent law, it also marks the transition
of England’s economy from a land-based agrarian feudal system to that of industrial capitalism.
Through the process of judicial interpretation of the law important developments emerged in the
18 century. During the reign of Queen Anne patent applications were required to supply a complete
th

specification of how the invention worked. This complete specification would be available to the public.
Legal battles in 1796 occurred over the steam engine. James Watt was a Scottish inventor and mechanical
engineer who made significant improvements to the Newcomen steam engine. He had realized that the
current engine designs wasted a great deal of energy by repeatedly cooling and heating the cylinder. Watt
introduced a design enhancement that used a separate condenser and this radically improved the power
efficiency and cost-effectiveness of steam engines. Eventually, he got his engine to produce rotary motion
which greatly increased the use of the steam engine beyond just pumping water. Edward Bull, the origi-
58
 Types of Intellectual Property

nal manufacturer that Watt used, started making his own design of the steam engine and then challenged
Watt’s patent on enforceability when Watt tried to stop him from producing his design. Bull believed that
Watt had not invented the steam engine but had just improved the existing steam engine and the ques-
tion whether or not an improvement could be patented became the issue of the case. The judges in 1799
issued a decisive opinion in favor of Watt and the concept of patenting an improvement was accepted.
As discussed in the section on copyrights the “patent and copyright clause” of the U.S. Constitution
was proposed in 1787 by James Madison in the Federalist papers (Federalist No. 43). Madison wrote:
“the utility of the clause will scarcely be questioned. A copyright of the author’s has been solemnly
adjudged, in Great Britain, to be a right of common law. The right to useful inventions seems with
equal reason to belong to the inventors. The public good fully coincides in both cases with the
claims of the individual”.

The first patent act of the U.S. Congress was passed April 10, 1790 and is titled “An Act to Promote
the Progress of Useful Arts.” The first patent was granted July 1790 to Samuel Hopkins for producing
potash. The act called for the Secretary of State, the Secretary of War and the Attorney General or any
two of them to decide if the invention is useful and important and the cause of the letters of patent to
be issued. Additionally, in this act it set up the need to have a specification in writing and a model to be
delivered and filed in the office of the Secretary of State. The requirement of the model was dropped later
in the century. The act called for the monopoly to last for 14 years once issued. From these humble begin-
nings the patent system was borne and a separate patent office to examine patents was created in 1802.
Patent rights became more international upon the signing of the “Paris Convention for the Protection
of Industrial Property” in 1883. This convention is still in force. As of September 2014 it had 176 mem-
ber countries. The convention called out three main ideas: national treatment of intellectual property,
priority right and common rules.
The first of these is “national treatment,” which means that when an application is filed for a patent in
a foreign country, the applicant and application will receive the same treatment as if they lived and were
born in the country that they are seeking the patent in. For example, if an American citizen files a patent
in Germany, the German government cannot treat that American citizen and his patent application any
differently than it would treat a German citizen. Also, if the patent is granted, the owner will benefit from
the same protections and legal remedies as if the owner were a national in the country where the infringe-
ment occurred. The next element of the convention is the “priority right.” Here the convention calls for
the priority right (or priority date) as the first filing date that would have the same priority date in another
country so long as the application is filed within 12 months of the patent.
From this first convention a number of other treaties, international treaties and agreements have been
established. The “Patent Cooperation Treaty” (PCT) signed in 1970 establishes an international patent
filing system that makes it possible to seek patent protection for invention simultaneously in a number of
countries. (Currently, there are 148 countries that are signatories to the treaty.)
The “Patent Law Treaty” (PLT), signed in 2000, establishes common and maximum requirements
regarding many procedures and formalities related to national and regional patent applications and patents.
(Currently, there are 59 countries and the European Patent Organization who are signatories to the treaty.)
At this time there is a proposed international patent treaty called “The Substantive Patent Law Treaty”
(SPLT). This treaty, in contrast to the “patent law Treaty,” goes beyond formalities and seeks to harmonize
requirements such as novelty, inventive step, non-obviousness, and sufficiency of disclosure, utility of an
invention and claim drafting and interpretation. As of this writing this treaty is on hold.
The “Budapest Treaty” signed 1977 (currently there are 79 countries and the European Patent Organiza-
tion that are signatories to the treaty) concerns the international disclosure of biotechnological inventions. It
stipulates that for the purpose of patent the applicant must deposit the microorganism with an international
“depository authority.” This will ensure that there are examples of the organisms for future generations.
These treaties and others are administered by the World Intellectual Property Office (WIPO).
As was stated earlier, a patent is an exclusive right for invention. This exclusive right to the product or
process is only available if it is a new way of doing it or if it offers a new technical solution to a problem.
To receive a patent, the invention must be disclosed to the public in the patent application. Once a patent
59
Engineering Management Handbook

has been obtained the patent owner has the permission to license other parties to use the invention. The
owner may also sell the rights to someone else. If this is done then the new owner of the patent has the
same rights as the original inventor.
Once a patent expires the protection ends and the invention enters the public domain. In other
words, after the patent expires anyone can commercially exploit the invention without fear of infringe-
ment. During the period of protection it is the patent owner who has the right to decide who may or
may not use the patented invention. Patents can be granted in many fields of technology—everything
from computer chips, nanotechnology, chemical compounds as well as plants and everyday kitchen
devices. Patent protection is limited to a period of 20 years from the filing date of the application. Patents
are territorial rights; in general, the exclusive right is only applicable to the country or region where the
application has been filed and granted and only in accordance with the laws of that country or region. To
enforce his or her rights the patent owner has to take someone to court. In most systems a court of law
has the authority to stop patent infringement, but it is up to the patent owner to monitor, identify and
take action against infringers.
In order to obtain patent protection the inventor needs to meet certain key conditions. While it is
not possible to compile an exhaustive list there are five key conditions that typically must be met. First,
the invention must show novelty. That is, it needs to show some new characteristic that was not known
before and it must be different from the “prior art.” The invention must be “non-obvious”; it needs to be
something that someone who has ordinary skill in the art would not have known. The invention must be
useful. It has to go beyond a mere theoretical phenomenon and the subject matter of the invention must
be disclosed in a manner that is clear and complete and would enable someone with ordinary skills in the
art to replicate the invention. And lastly, a patent must be patentable under the law of the country. In
some countries scientific theories, mathematical methods, plant or animal varieties or computer programs
are not patentable, but in other countries they are.
There is no universal international system for granting patents. Rather, patents are granted by nation-
al offices or by regional offices that carry out that task for a number of countries. An example of a regional
office is the European Patent Office (EPO). Under these regional systems an applicant will request pro-
tection from one or more member states of the original organization. The regional office accepts a patent
application, examines the patent and if all criteria are met, it ultimately grants the patent.

5.6 Obtaining a Patent

How do you obtain a patent? The first step in getting a patent is to determine if you have sometime new
and novel. So, typically, you would do a search to see if the invention has already been patented or dis-
closed. This is called a Prior Art Search. Once you determine that you have something that can be patent-
ed, then you need to fill out a patent application. Many patent offices actually provide specific forms to
fill out and in some patent offices you can even fill out a patent application online. In the patent applica-
tion you generally must describe the title of the invention as well as what technical field the invention is
part of. You will need to include a background and a description of the invention in clear language and
enough detail that a person with an average understanding of the field could use or reproduce the inven-
tion. Many of these descriptions are accompanied by visual material such as drawings or diagrams. Most
importantly you must clearly and concisely define the matter that you are hoping to patent. This is called
“the claims” of the patent application. More than anything else it is “the claims” that will determine the
scope of your invention. Many great inventions have been “mis-claimed” and the resulting claims are far
narrower than the invention deserves. This frequently leads to patents that are far less valuable than they
should be.
Once a patent application has been completed, the next step is for the patent office in the country or
region where the application is filed to examine the patent. One of the first steps in the examination pro-
cess is to determine if the invention has already been patented or invented. The patent office will conduct
its own prior art search to augment the prior art search of the applicant. The patent office will determine
if the inventor/applicant had missed anything in the disclosure to the patent office. Next, the application
is examined by a patent examiner. The patent examiner acts as an advocate for the public. His job is to en-
60
 Types of Intellectual Property

sure that the application develops into a clear and complete record. He tries to act cooperatively with the
inventor to investigate the patentability of the idea according to patent laws. Ultimately, the examiner will
serve as a judge as to the patentability of the inventions claimed in the patent application. Based on that
the examination process is there to make sure that the examiner can understand the invention set forth in
the specification and determine if the application and specification is adequate to define the “metes and
bounds” of the claimed invention.
Additionally, the examiner will determine if the patent application is novel, useful, non-obvious and
patentable. The examiner will communicate with the applicant by writing Office Actions (OA), which
identify and analyze the patentability of claimed inventions. The applicant has the ability to respond to
these Office Actions and argue his case with the patent examiner. This back and forth is called “patent
prosecution.” In the end, the examiner is trying to answer certain questions about the application: what
subject area is most related to the applicant’s invention; what are the existing inventions the applicant
identifies; what problems did the applicant identify with the existing inventions; how does the applicant
propose to solve the problem; how does the applicant implement the solution and do the claims incorpo-
rate the applicant’s solution.
In the U.S. Patent Office, the applicant needs to decide what type of application to file.

5.7 Design Patents

A “design patent” is an ornamental characteristic of a product. One of the best examples of a design pat-
ent is the form of the Coca-Cola bottle D48, 160. Other countries have a similar concept called a regis-
tered design or industrial design. With a design patent an object with a design that is substantially similar
to the design claimed cannot be made, used, copied or imported into the United States. The copy doesn’t
have to be exact; it only has to be substantially similar. A case in point here is the Apple vs. Samsung case
that Apple won because Apple was able to show that the face of the Samsung GalaxyS 4G was substantial-
ly similar to Apple’s iPhone design patent D593,087.

5.8 Plant Patents

The second type of patent is a “plant patent,” which describes a new variety of asexually reproduced
plants. In the United States, the Plant Patent Act of 1930 was enacted as part of the Smoot-Hawley Tariff.
This was inspired by the work of Luther Burbank, the famed botanist. The legislation made it possible to
patent new varieties of plants. Plants can also be protected internationally under the International Union
for the Protection of New Varieties of Plants. The object of the convention was to protect new varieties
of plants with an intellectual property right. These rights are known as plant breeders’ rights and give the
breeder exclusive control over the propagating materials including seeds, cuttings, tissue cultures, etc. and
the harvest material of a new variety for number of years. There are more than 72 party members to this
convention.

5.9 Utility Patents

The last type of patent to discuss is the “utility patents.” In general, the utility patent protects the way an
invention is used and/or works. It can be granted to anybody who invents a new and useful method, pro-
cess, machine device, manufactured item, system, or chemical compound. Utility is actually a patentability
requirement. The US law 35 U.S. Code § 101 (Inventions Patentable) states: “Whoever invents or discovers
any new and useful process, machine, manufacture, or composition of matter, or any new and useful im-
provement thereof, may obtain a patent.” As recently as the late 1990s few patents were ever challenged on
patentability and this law was used to limit inventions that could never possibly work like perpetual motion
machines. More recently, however, this law has become more controversial and has seen rulings of unpatent-
ability of electronic signals, medical diagnostic or treatment and certain “business methods.”
The concept of utility is mostly an American one. European patent law does not consider utility as one
of its criteria for patentability. Instead, it requires that an invention must have industrial applicability. In
other words, an invention is eligible for a patent if it can be made or used in some kind of industry. This is
61
Engineering Management Handbook

a similar requirement to utility but there is a difference. Generally, to fulfill the requirement of utility for
patents, there are three main issues to review: the operability of the invention, the use of the invention that
must be beneficial, and the practical use of the invention. Operability is satisfied by enabling the invention
in the detailed description of the patent. The beneficial use must be that the patent is capable of providing
some benefit. In the past it was believed that beneficial utility established in a patent should not be granted if
frivolous or immoral or against public policy. But recently the patent office has taken the following position:
“A rejection under 35 U.S.C. 101 for lack of utility should not be based on grounds that the invention is
frivolous, fraudulent or against public policy” (Manual of Patent Examining Procedure 706.03(A) III). The
last issue is practical use; in other words, the invention must have some real-world use.
With utility patents there are two different types of applications that can be filed in the United States.
The first is the traditional non-provisional application. The second is the provisional application.
Since 1995 the USPTO has offered inventors the ability to file provisional applications for a patent.
A provisional application pendency lasts 12 months from the date it is filed. It cannot be extended and at
the end of the 12 months the provisional application expires. While a provisional application is inexpen-
sive one must understand that in order for it to be in force a non-provisional application will need to be
filed also. There are a few benefits to the filing of provisional but also some risks.
The benefits include a simplified filing at a lower investment that gives the inventor 12 months to
assess the invention and determine if additional investment should be made. Another benefit is that while
the provisional establishes the application filing date for the invention it also permits the usage of “patent
pending” notice for 12 months after the description of the invention is filed.
A provisional application begins the Paris Convention priority year and it also allows an inventor to
begin to promote the invention while having some degree of protection.
The risks are that the benefit of the provisional application cannot be claimed after or if the 12-
month deadline is passed and the provisional application cannot result in a U.S. patent unless the corre-
sponding non-provisional application is filed within 12 months.
Provisional application cannot be filed for design patents and provisional applications are not examined.
Oftentimes provisional applications have not completely disclosed the invention and therefore the parts of
the non-provisional application cannot claim benefit to what is not disclosed in the provisional application.
Inventors must understand that the provisional application will not mature into granted patent without fur-
ther submissions and cost by the inventor. Some unscrupulous invention promotion firms have misused the
provisional application process leading inventors to believe that they can obtain a patent inexpensively. These
firms instead take the money from the inventor and leave the inventor without a patent.
Different from a provisional application is a standard application. The standard application requires
all the necessary parts of the patent including a written description of the invention as well as the claims.
It should include all the information required to grant the patent. The application may or may not result
in a grant of the patent; it depends on the outcome of the examination of the patent office. Here we are
talking about application filing, preparation and prosecution, sometimes called “prep and process.”

5.10 Major Elements of Patent Application

Let us review some of the major elements of the patent application. As previously mentioned, the patent
specification is the detailed description of the invention and will set out the scope of the patent. Gener-
ally, this section includes a background or an overview of the invention, a description of the invention
and any drawings. It also includes the claims that are very important. Other things typically included in
application are any known “prior art” that the inventor knows about, the filing date, the priority claim,
and an abstract of the invention. For example, rule 5 of the PCT states:

G. The description shall first state the title of the invention as appearing in the request and shall:
i. Specify the technical field to which the invention relates;
ii. Indicate the background art which, as far as known to the applicant, can be regarded as useful for
the understanding, searching and examination of the invention, and, preferably, cite the docu-
ments reflecting such art;
62
 Types of Intellectual Property

iii. Disclose the invention, as claimed, in such terms that the technical problem (even if not expressly
stated as such) and its solution can be understood, and state the advantageous effects, if any, of
the invention with reference to the background art;
iv. Briefly describe the figures in the drawings, if any;
v. Set forth at least the best mode contemplated by the applicant for carrying out the invention
claimed; this shall be done in terms of examples, where appropriate, and with reference to the
drawings, if any; where the national law of the designated State does not require the description
of the best mode but is satisfied with the description of any mode (whether it is the best contem-
plated or not), failure to describe the best mode contemplated shall have no effect in that State;
vi. Indicate explicitly, when it is not obvious from the description or nature of the invention, the
way in which the invention is capable of exploitation in industry and the way in which it can be
made and used, or, if it can only be used, the way in which it can be used; the term “industry” is
to be understood in its broadest sense as in the Paris Convention for the Protection of Industrial
Property.

In some patent offices, patent applications can also be filed as continuations to previous applications.
These are convenient methods to include material from previous applications in a new application. In
some cases the new application will take the priority year from the earlier patent. These are called “con-
tinuations.” Additionally, in the U.S., there is a method called a continuation-in-part application that
allows the applicant to add new material to the application. In this case an applicant would add subject
matter not disclosing the original patent but will repeat significant portions of the patent specification
and will share at least one inventor with the original patent. This is the way to claim enhancements that
were developed on the original invention. One of the odd situations is that in a “continuation-in-part” the
applicant is likely to end up with two priority dates—one for the original patent and another priority date
for the added material. The courts will use these two dates to determine the priority date of the patent and
therefore what prior part is applicable.
In some patent offices it is also possible to file what is called a “divisional patent application.” This
application also claims the priority of the filing date from the parent application but is a divisional and
claims distinct independent claims that are different from the parent application. Oftentimes division-
als are filed when the patent attorney determines that the specification covers more than one invention.
Additionally, the patent examiner may issue what is called a “restriction requirement” because a patent
can only claim a single invention. This would cause the applicant to file a divisional on all but one of the
inventions disclosed. It should be noted that continuations and continuations-in-part are a USPTO phe-
nomenon and generally not available in other jurisdictions. Divisional patent applications on the other
hand are often found in other countries.

63
64
 What is a Patent?

6
What is a Patent?

Donald W. Merino
Transpacific Advisors

65
Engineering Management Handbook

6.1 Where Patents are Held

Patents are granted on a country-by-country basis. Additionally, when patents are discussed it would be
remiss to not introduce the concept of a patent family. A patent family consists of the patents that relate
to the original invention. When deciding to file a patent one must also decide in which countries to file
that patent. As recently as the mid-1990s the main focus of most major companies were U.S. patents.
Very little thought in the electronics industry was given to non-U.S. patents. At that time, China was
a nascent market and was just beginning its economic rise. In 1997 most companies did not believe that
Chinese patents would ever be enforceable and there they were considered not valuable. At that time most
companies preferred to focus on the United States and somewhat also on Europe. The reason for this was
due to market considerations and the legal landscape in those regions. In 1997 the United States Court
system was considered a reasonably predictable system that enabled the patent holders to receive fair com-
pensation for their patents as well as the possibility for injunctive relief. Europe, at that time, was somewhat
of an afterthought for most electronics companies because, while the European Union (EU) as an entity was
a large market, it was subdivided into many countries (Germany, France, England, Italy, Spain, and the Low
Countries). Japan was also sometimes considered but usually as an afterthought. While Japan had a small
sales market compared to the U.S. (approximately 1/5 the size of the U.S. market) there were many Japanese
manufacturing companies and a substantial manufacturing base in Japan. Korea was an even smaller market
than Japan and had fewer manufacturing companies. Additionally, in both the case of Korea and Japan, it
was felt that the “home-field advantage” was significant for the manufacturing companies. In other words,
most people believed that a non-Japanese or non-Korean company would be treated fairly in the court
system if they were seeking infringement claims against a company based in that country. Since a patent can
be enforced for the manufacturer’s sale and use of the invention, it was felt that most jurisdictions were either
just too small a market or had “home-field advantage” for the local manufacturing companies.
During this timeframe many patent families had relatively few foreign counterparts. Most people
focused on the United States since that was four to five times the size of any other local jurisdiction. Also,
depending on the technology market, many companies wanted to file where their foreign competitors
were based. This was Germany and/or Japan and, as a result a patent might be filed in those countries.
Rarely was it the case that more than 3 to 5 jurisdictions would be covered. Many of the European com-
panies as early as the late 1990s had a pretty aggressive strategy for filing patents in the EU and would
mainly file in what was considered the big three European countries—England, Germany and France. By
2010, most major companies were filing significant numbers of patent applications in China and other
major countries in Asia due to the economic growth of that region. But with all of that said, even in 2015
finding broadly filed portfolios with good worldwide coverage was difficult at best and many portfolios
are only U.S. patents. Even in Asia you often find companies that file patents in their home jurisdiction
plus the U.S. and China.
However, there are signs of this changing with the new applications companies are filing. A combina-
tion of factors has led to this change. In the United States we have seen a systematic weakening of rights
for the patent holder. The United States has also gone through quite a significant change in how damages
are calculated, lowering the potential outcome of a successful litigation. Lastly, the United States has made
injunctive relief extremely hard to obtain. In the 2015 market some of the most valuable patents were
European patents and, in particular, German patents. Conventional wisdom is that the German courts are
friendlier to patent holder rights and that injunctive relief is available in German courts. Compounding
this issue is the cost of litigation. In the United States, litigation is both time-consuming and costly due
mostly to discovery that does not occur in many jurisdictions. Also it is reasonable to expect that a patent
litigation will cost between $5 and $10 million and take up to five years. Conversely, in Germany the cost
of litigation is much less expensive, approximately $1 million for a case and relatively quick, between one
and two years. Additionally, China appears to become a very important market for patents. First, China
is a very large market and is beginning to rival the U.S. in the sale of high-end electronics, computers,
smartphones and networking equipment. Second, much of the world’s manufacturing base has moved to
China. While Chinese patent law and patent courts are relatively new it does appear that the courts are
moving in a direction to protect the rights of patent holders. Additionally, the Chinese government has
66
 What is a Patent?

made creating patents a priority and urges companies and individual inventors to invent and file patents.
While not a perfect market, many people believe that China will continue to strengthen its patent laws in
court and ultimately become a location where getting patents will become imperative.
The problem in architecting any portfolio is that there is no one simple solution. One needs to con-
sider a case-by-case basis filing strategy. A company needs to look at what its goals are, what market it is
in and who its competitors and or IP threats are.

6.2 What are the Laws and Rules in the U.S.?

U.S. patent law is a combination of three different elements. First, the U.S. Constitution allows Con-
gress to pass patent laws. Congress writes those laws and then the courts interpret those laws. In order to
understand patent law in the United States it is important to understand where it comes from, what it is
and how it is interpreted. The USPTO (United States Patent and Trademark Office) publishes the Manual
of Patent Examining Procedure (MPEP). This manual describes the procedures that the patent office must
follow when examining a patent application. The first MPEP was published in 1920; it is still used by
patent attorneys and patent agents to make sure that they are following the appropriate regulations. In
order to become a qualified patent attorney or a patent agent one must take an examination given by the
USPTO that tests the knowledge of the applicant of the MPEP and the underlying laws and regulations.
A copy of the MPEP can be found on the USPTO website and downloaded, but beware, it is very dense.
For a non-patent lawyer it is important to know that the MPEP exists but it is primarily a document for
the lawyers who are trying to obtain patents for their clients.
U.S. patent law was created in the United States Constitution in Article I, Section 8, Clause 8. This
is known as the Patent and Copyright Clause. Section 8 of the Constitution lays out what is called the
Enumerated Powers of Congress. This section starts with the phrase “The Congress shall have power” and
then lists the powers that the Congress shall have including the collection of taxes, duties, imports and
excises, to pay the debt and provide for the common defense. The eighth clause is the clause that we are
most interested in as it gives Congress the power:

“To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and
Inventors the exclusive Right to their respective Writings and Discoveries.”

What is interesting and often misinterpreted in this clause is that it grants the power to Congress to
do these things it does not require that Congress actually do is these things. In order for there to be patent
laws the U.S. Congress needed to take affirmative action and pass laws. The substantial law in the United
States is found under Title 35 of the United States Code. Title 35 has five parts or sections, four of the
parts are related to patents and one section is related to industrial designs. The first part establishes the
United States patent and trademark office. As part of this section the Congress allows the United States
patent and trademark office to set the procedures for granting a patent.
The second part is titled Patentability of Inventions and Grant of Patents. Key in this part are sections
101, 102 and 103. In section 101 the law describes what is patentable and states:
“Whoever invents or discovers any new and useful process, machine, manufacture, or composition
of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the
conditions and requirements of this title.”

Section 101 has recently been under scrutiny as to what can and cannot be patented. For example,
can software be patentable under section 101? Or can an electromagnetic wave shape be patentable under
this section?
Section 102 covers the condition for patentability; novelty. In particular, this section sets up the idea
of novelty as compared to the prior art. It states:
“(a) Novelty; Prior Art. — A person shall be entitled to a patent unless—
(1) the claimed invention was patented, described in a printed publication, or in public use, on
sale, or otherwise available to the public before the effective filing date of the claimed invention;”
67
Engineering Management Handbook

This section has become one of the bases for determining if a patent is valid. In particular, it requires
of the person be the first to have invented the patent.
Section 103 covers conditions for patentability; non-obvious subject matter. This section states that a
patent must be not obvious to somebody having ordinary skill in the art. Specifically, this section says:

“A patent for a claimed invention may not be obtained, notwithstanding that the claimed inven-
tion is not identically disclosed as set forth in section 102, if the differences between the claimed
invention and the prior art are such that the claimed invention as a whole would have been obvious
before the effective filing date of the claimed invention to a person having ordinary skill in the art
to which the claimed invention pertains. Patentability shall not be negated by the manner in which
the invention was made.”

Some years ago a section 103 objection was considered a rather easy bar for a patent holder to over-
come. More recently the courts have interpreted section 103 much more aggressively and now 103 objec-
tions are not only common but many times prevail in patent cases either in District Court, the Appeals
Court and/or in the Patent Office.
The next chapter under part 2 describes the law for the application of patents. Of particular note is
section 112, the specification section. This section states that a patent must have a written description
of the invention and must set forth what is called the “best mode” contemplated by the inventor. It also
states that the description has to be in such a way to “enable” a person skilled in the art to make and use
the invention. Often times patents will be challenged based on this section. The challenge is that the
patent is not patentable under section 112 because either the inventor did not describe the “best mode” or
the patentee did not “enable” the invention in the specification. There has been a recent argument around
what are called “paper patents.” These are patents only of ideas for which there are no working models or
prototypes. The argument goes that many “paper patents” should not be granted because they do not en-
able someone to make use of the invention. This has become a common challenge now in District Court,
the Appeals Court and in the Patent Office.
Other chapters in Part 2 include who can review patent and trademark decisions, how patents are
issued, the rules governing plant patents, designs and patent rights inventions made with government
assistance, etc.
Part 3 of U.S. code 35 is titled Patents and Protection of Patent Rights. This part covers a number
of things; most important for us is chapter 28, which discusses infringement of patents. Section 271
describes what it means to infringe a patent, how to file an infringement case and what some of the rules
are about infringement. Chapter 29 of part 3 is titled Remedies for Infringement of Patent, and Other
Actions. This chapter sets out the remedies for infringement of the patent, the presumption of validity
and available defenses. Section 282 states that the defenses for infringement are either non-infringement,
invalidity based on section 101, 102 or 103 or that a patent fails to comply with section 112 which, as we
discussed earlier, is the best mode and enablement section. Section 283 relates to injunctions and states
that courts may grant injunctions on such terms that the court deems “reasonable.” Section 284 covers
damages and states that the floor of damages is a “reasonable royalty” for the use of the invention by the
infringer. Three important chapters in part 3 are chapters 25, 31 and 32, which establish what is called a
reissue procedure, “Inter Parties Review” (IPR) and the post-grant review processes. Chapter 25 allows the
patent owner to reissue effective patents; in other words, the patent owner has the ability to go back to the
patent office and have the patent looked at again by the patent office. This chapter lays out the proceed-
ings for making simple corrections as well as corrections in the title and/or the inventorship. It also allows
a request for supplemental reexamination of a patent. If the reexamination is done within two years of the
issue of the patent the patent owner can apply for a broader set of rights by broadening their claims but, if
the reexamination request is done after two years, then the patent owner can only have the patent reex-
amined and only the same or narrower rights can be issued. Reexamination is usually done for one of two
reasons. First, it is an attempt by the patent holder to broaden the claims of the patent. In this case the
patent owner should review the patent on a regular basis and determine if the specification of the patent
can yield broader claims. Since this can be done up to two years after the patent application issue, the
68
 What is a Patent?

patent owner now has a chance to understand better how the technology is developing and craft a better
set of claims. The goal is to develop claims that would be easier to prove infringement of.
The second case is if the patent owner realizes that there is perhaps additional prior art that was
not cited by the patent office. Thus, he now wants to put the prior art in front of the patent office and
preserve claims that would still be useful for an infringement case. The second case is typically called a
Narrowing Reexam, while the first case is called a Broadening Reexam.
The IPR is a procedure that allows defendant companies to request the patent office to review the
patentability of the patent that they are accused of infringing. This is a relatively new procedure and is a
process that lets the patent office determine the validity of a patent after the patent has already been is-
sued. In the first years of this new proceeding almost 80% of all patents brought to the patent office were
found to have defects of validity and were declared invalid. It will be interesting to see how this process
changes over the years. Many believe that this new process is just a burden for patent holders while others
believe that determining the validity of a patent at an early stage will not only decrease litigation but will
also ensure that litigation only goes forward on valid substantial patents. Once infringers initiate an IPR
they are enjoined from further challenging the validity.

6.3 The Courts

As stated previously, the courts in the United States have the important function of interpreting U.S. pat-
ent law. The courts also decide patent cases and it is because of the requirements of these patent infringe-
ment cases that the courts interpret the laws. In the U.S. there are basically three courts to contend with:
District Court, Federal Circuit Court, and the U.S. Supreme Court.
The first stop for infringement cases is U.S. District Court. The District Court will usually decide
if the patent is valid and if the patent is infringed. (Note: previously discussed was that validity can be
determined in the USPTO via an IPR procedure.) This can be done by both, the judge or the jury. When
judges are hearing patent infringement cases the lawyers will often use arguments that require the judge to
make a determination as to what the law means in the particular case. These rulings on the law are rulings
that are frequently appealed to the next highest court. In a civil case either side may appeal the verdict. In
a criminal case, the defendant may appeal a guilty verdict, but the government may not appeal if a defen-
dant is found not guilty. A litigant who files an appeal, known as an “appellant,” must show that the trial
court or administrative agency made a legal error that affected the decision in the case.
Prior to 1982 the Court of Appeals from the District Court was the local Circuit Court. Circuit
courts were defined by geographic boundaries. In other words, the circuit courts would decide cases
and law based on rulings of District Courts in their jurisdiction. In 1982 Congress passed the Federal
Courts Improvement Act, which merged the United States Court of Customs and Patent Appeals and the
Appellate Division of the U.S. Court of Claims. They created the U.S. Court of Appeals for the Federal
Circuit. This is known either as the Federal Circuit or by the initials C.A.F.C. This court hears the appeals
from all the District Courts on patent matters as well as appeals from certain administrative agencies and
appeals that arise under certain statutes. The Federal Circuit has jurisdiction over appeals from the U.S.
Court of Federal Claims, U.S. Court of Appeals for Veterans Claims, the Board of Contract Appeals, U.S.
International Trade Commission and the United States Patent Trial and Appeals Board as well as the U.S.
Trademark Trial and Appeals Board. One of the unique aspects of this is because the Federal Circuit hears
all appeals of patent cases their rulings having a binding precedent throughout all the District Courts.
This is different than a typical Federal Circuit whose decisions are only binding precedent for the District
Courts within the Circuit. Finally, after the Federal Circuit the next highest court is the Supreme Court.
One of the important aspects of appeals courts is that they hear appeals on lower court opinions on law
but not opinions on facts. In most cases the judge determines the law while the jury determines the facts.
The case law around patents will be discussed but not in detail. This subject is, in itself, a whole
book. Also for most practitioners understanding the case law is something that is probably best left to the
lawyers. With that said it is important for a person in the patent business to be aware of what some of the
new case law is and how that affects the overall business. For example, probably the biggest change to pat-
ent law in the last few years was the Supreme Court’s eBay Inc. vs. MercExchange, L.L.C. decision. This
69
Engineering Management Handbook

was an important case because the Supreme Court unanimously decided that an injunction should not
automatically be issued on finding a patent infringement. It basically gave the District Court judge much
more latitude to decide not to issue an injunction than was previously the purview of the District Judge.
The court described a four-factor test to determine if an injunction should be issued. The factors are that
the patent holder must demonstrate:
1. That the plaintiff suffered irreparable injury;That the remedies available in the law such as monetary
damages are inadequate to compensate for the injury;
2. That, considering the balance of hardships between the plaintiff and defendant, a remedy in equity is
warranted; and
3. The public interest would not be disserved by a permanent injunction. … These familiar principles
apply with equal force to disputes arising under the Patent Act.

This was a pretty radical departure from what most people thought the law was and it also radically
affected patent valuations in the marketplace. In the past most companies and individuals felt that if they
had a valid and infringed patent they could enjoin the other side from selling its infringing products. Be-
cause of the possibility of injunction most companies considered this a severe penalty that they wanted to
avoid. This led to numerous settlements of patent cases just before trial as few companies wanted to risk
the possibility of an injunction being issued. With this threat removed most companies, unless they have
a directly competing product, only have to worry about monetary damages. Therefore they feel that time
is on their side and that even if they lost a District Court case they can appeal it to the Federal Circuit
and only delay the payment. It is obvious how this change in law had a direct impact on patent values
as the payment time was lengthened. It also shows the importance of knowing the current case law and
what cases are being decided that can drastically change the business environment for those involved with
patents.

70
 What is a Patent?

6.4 Reading a Patent

Figure 6.1 illustrates the front page of a U.S. patent.

Figure 6.1. Page of a U.S. Patent

For those who are unfamiliar with patents, the parts of a patent will be discussed. Note that how
patents look changes depending on the source you are viewing it from. This example shows how the
patent looks when sent to the inventor or printed from the USPTO image database. If one uses an online
database, the same information appears but frequently the information shows up in different areas. For
example, on the USPTO website, the claims are not written at the end of the patent but rather right after
the bibliographic information.
71
Engineering Management Handbook

Below are the numbers of the patent in Figure 6.1. These will be used to identify the sections.

(12) Type of Document: For an issued patent, this will just read “United States Patent” (or, if appro-
priate, “United States Design Patent”, “United States Plant Patent” or “Patent Application Publication”).
”Reissued Patent”: This patent is based on another patent, which was previously issued. Earlier in the
chapter I discussed the process for reexamination and reissue was discussed. The Reissue Patent has been
examined a second time because there are usually modifications to the claims.

(10) Number: The patent number. This is a serial number of the patent – patents are issued and given
the consecutive number in the series. Patent 6,000,000 was issued December 1999; Patent 7,000,000 was
issued February 2006 and patent 8,000,000 was issued April 2011. Note that there is also a prefix. The
prefix tells a little more about the patent. Sometimes there are prefixes to the number prefixes before the
number, which indicates the kind of document:

•B - Reexamination Certificate, issued after a patent was issued and has been examined again by re-
quest of the patentee. The numeric portion of the number is the number of the patent to which the
reexamination certificate refers. (For design, plant, reissue patents, the Reexamination Certificate
will include the normal designation letter - BD for design, BP for plant, etc.)
•D or Des. - Design Patent - 14-year term, covers ornamental appearance of a useful object•PP or
Plt. - Plant Patent - covers certain plants•RE - Reissue patent (RD for reissued design patent, RP
for reissued plant patent)
Documents also have a letter or letter/number after the number. These appear on the face of the
patent only after January 2, 2001; these suffixes have meaning and tell us a little more about the
patent. Here are a few of the common suffixes:
•A1 - Published Patent Application - (if application is published more than once, A2 for second,
etc.)
•B1 - Utility Patent, not previously published
•B2 - Utility Patent, previously published as an application
•C1 - Reexamination Certificate (if more than one certificate, then C2, C3...) (B1 ... is used for
pre-2001 Reexamination Certificates)
•P1- Plant Patent (before 2001)
•P1 - Published Plant Patent application (after 1/2/2001 - additional publications are P4, P5...)
•P2 - Issued Plant Patent without pre-grant publication (after 1/2/2001)
•P3 - Issued Plant Patent that was previously published (after 1/2/2001)
•S - Design Patent

(45) Date of Patent: The date the patent was issued by the USPTO. This is important because only
after this date is the patent enforceable; sometimes this is the date that the term of the patent is measured
from. These dates always fall on a Tuesday.

(54) Title: This is the full title of the patent. Sometimes the title is very clear and one can quickly tell
what the invention is. But sometimes the title is much more obscure and understanding the technology is
very difficult for a generalist.

(75) Inventors: All of the inventors will be listed on the patent. A practicing patent attorney said that
if there were more than three inventors he felt it was important in a litigation to interview each inventor
and ask what he contributed to the invention. It was his feeling that often companies will add names to a
patent based on the group of people who were working on the project and therefore misrepresent the true
inventor. This could have dire consequences in litigation.

(73) Assignee: If the patent is owned by an entity it is listed here. There will be no assignee field if the
assignee is the inventor. It is important to note that the assignee name is filled in when the patent issue fee
72
 What is a Patent?

was paid and, therefore, if there is a change of ownership after that time, the cover of the patent will not
change. There is a separate database at the PTO that shows who the current assignee of the patent is but
it is also important to know that it is not required assignees register their new assignment in the patent
office. For example, when one company buys another company they it transfer all the patents legally in
the contract for the sale but may not record the assignment in the patent office. This occurs many times.
(*) Term extension notice: the term extension notice is relatively new and it will indicate if there are
additional days of life to the patent. Basically, the patent office does not penalize the applicant for
time the patent application spends in the queue at the patent office. This has been as much as three
additional years; knowing the life of the patent is critical in determining the value.

(21) Application Number: The identifying number of the application on which this patent was based.
The serial number is always six digits, assigned sequentially as applications are received by the USPTO,
prefixed by a two-digit series number. When the number reaches 999,999, they start a new series. There
are two unique series that should be mentioned: series that begin with 90 represent patents that have
been reexamined under Ex Parte Reexamination procedure and series that begin with 95 indicate patents
reexamined under Inter Parties Reexamination procedure.

(22) Filing date: the filing date is the date that the patent application was filed. Note the time the ap-
plication was originally filed if the patent is a continuation and this may not be the “first filing date.”(65)
Prior Publication Data: If this patent was published while it was a pending application, the publication
number and date will be listed here.

(60) Related U.S. Application Data and (30) Foreign Priority Data: If this application is related to
any other applications or patents, they will be listed here. This field will often tell you what the “first filing
date” was.

(51) International Patent Classification: Patents are classified based on the IPC for ease of searching.
Sometimes patents have multiple IPC numbers. All patents are classified by subject matter for ease of
searching. The classifications in which a patent is indexed are listed in these sections.

(53) U.S. CL: The USPTO uses its own U.S. Patent Classification System (USPC) in which all in-
ventions are first put in a class having a three-digit number, then in a numbered subclass under the class.
The subclasses are arranged in hierarchical form but not necessarily in numerical order.

(58) Field of Search: These are the U.S. classes/subclasses that the examiner searched when he or she
reviewed the patent.

(56) References Cited: This is the list of prior art that was cited in this case. Some of the prior art may
have been found by the examiner when he or she did the patent search or the prior art may be listed by
the patentee when the patentee filed the application. Both U.S. and foreign patents may be listed as well
as non-patent literature. In the U.S. and other countries such as Japan and Canada there is a “duty to
disclose.” It is found in 37 C.F.R. 1.56. Duty to disclose information is material to patentability.

“A patent, by its very nature, is affected with a public interest. The public interest is best served, and
the most effective patent examination occurs when, at the time an application is being examined,
the Office is aware of and evaluates the teachings of all information material to patentability. Each
individual associated with the filing and prosecution of a patent application has a duty of candor
and good faith in dealing with the Office, which includes a duty to disclose to the Office all infor-
mation known to that individual to be material to patentability as defined in this section.”

The number of references cited will sometimes indicate the importance of the patent. In other words,
if the references cited are very long, the inventor and the inventor’s patent counsel thought that this
73
Engineering Management Handbook

pattern is particularly valuable. With that said it is not fair to say that because there are few references the
patent is not valuable. There are many valuable patents that have very few references. Conversely, there are
many patents that are not valuable that have a great number of references.

Primary Examiner, Assistant Examiner: These are the USPTO examiners who examined the patent.

(74) Attorney, Agent or Firm: When the Issue Fee is paid for the patent, one or more patent attor-
neys, patent agents or law firms may be listed on the cover sheet.

(57) Abstract: A brief summary of the invention, with the emphasis on “brief ” (less than 150 words).

Number of claims and drawing sheets: Lists the number of claims and drawing sheets in the patent.
This is useful to determine if the copy of the patent is complete.
Representative drawing: The examiner will pick one of the drawing figures and put it on the first
page. This is usually figure number one but other figures can be picked.

6.4.1 Sample Drawing

Shown in Figure 6.2 is a sample drawing for a U.S. patent.

Figure 6.2. Sample Drawing for a U.S. Patent

74
 What is a Patent?

Most U.S. patents have drawings. But some chemical patents do not have drawings. The drawings are
numbered from “fig(ure) 1” up and sometimes a figure will be divided into several subfigures.
The subfigures are identifiable because there is a letter suffix to the figure number.
(fig. 1A, fig. 2B, etc.). It is sometimes necessary to show the “prior art” as a figure. These figures will
be labeled as “prior art” so that one knows by looking at the patent that it is not part of the patented
invention. You will notice on each of the figures that there are often reference numbers on the label. These
are used so that the reference numbers can easily be called out for the specification of the patent. Fre-
quently, there are several kinds of drawings for mechanical patents that will be a 3-D view, cutaway view,
or an exploded view of the device. Cutaway views are used for semiconductor process patents. A cutaway
view can show the layers of the semiconductor or the structure of a transistor after the process. In many
electrical patents circuit schematics as well as block diagrams will be shown as figures. Block diagrams
are used to show the system in general terms and how they work in relationship to each other. Sketches
as well as flowcharts are often shown. Method patents often have flowcharts that show the steps of the
method.
After the drawings the “specification” of the patent appears. The specification is the written part of the
patent. It has a number of parts:

6.4.2 Typical First Two Pages of the Specification

Figure 6.3 shows the typical first two pages of the specification.

75
Engineering Management Handbook

Figure 6.3. Typical Pages of the Specification

76
What is a Patent?

77
Engineering Management Handbook

Reading down the first column of the first page there are a number of sections:

(A) First is the Title of the Invention: (See 37 CFR 1.72(a).) (B) Next is Cross-Reference to Related
Applications: (See 37 CFR 1.78.) For the sample patent shown this part is not presented but if the panel
is related to other patents and or earlier filed applications it will be stated right after the title. This will
include if a provisional application has been filed or if the patent is a continuation or continuation of part
of other applications or if the patent is a divisional of another application. Often foreign priority applica-
tions are listed here also but this is not required.

Sometimes, if the invention was developed using federal research and development money, there will
be a Statement Regarding Federally Sponsored Research or Development:

(C) Next is the Background of the Invention: Most specifications set forth the background of the
invention into different parts.

(D) Following the Background of the Invention is the Field of the Invention: The field of the inven-
tion is usually a very broad description of the area of technology of the invention. Sometimes reading the
section will give a clue to what the patent is actually useful for.

(E) Then there is the Description of the Related Art: The description of related Art section talks about
some of the prior art that was known before the invention occurred. This description may have references
to specific patents and/or other documents. For example, if the patent was developed as part of a stan-
dard-setting organization, the standard number would be referenced here.
Often this Background of the Invention is rather short. This was often done because patent attorneys
feared that the Background of the Invention could be used to invalidate the patent or limit the scope of
the claims and litigation.

(F) Next is the Brief Summary of the Invention: This is a summary of the invention (see 37 CFR
1.73). The summary should give you the idea of the invention and hopefully is useful in directing people
to understand what technology the patented invention covers. Sometimes this is the case but many times
it is not and the summary of the invention is as dense and incomprehensible as the abstract of the inven-
tion. The summary should be broad; in fact, it should be broader than the broadest claim.

(G) Then there is a Brief Description of the Drawing: This is typically a one-sentence description of
the figures.

(H) The last major section before the claims is the Detailed Description of the Invention this typical-
ly is the largest section of the patent: this is the description of the preferred embodiment of the invention
(see CFR 1.71). What is most important here is that the description needs to be able to accurately de-
scribe the invention and ensure that the invention is actually enabled. Frequently the detailed description
of the invention will end up defining some of the terms that are used in the claims.
In this section of the specification each of the figures will be explained. Sometimes a detailed descrip-
tion will include the method for making the invention or the method for using the invention. Often there
will be more than one example. This section of the specification is used to describe the various embodi-
ments of the invention in great detail.

78
 What is a Patent?

6.4.3 Claims Section

Figure 6.4 shows the Claims Section.

Figure 6.4. Claims Section of a Patent

In a printed patent the claims usually come last. With online databases, they are usually shown first
immediately after the bibliographic information in the abstract. As mentioned before, the claims are the
most important part of the patent because they define the metes and bounds of the patent grant. One
way of thinking about patent claims is to use a property analogy. The patent claims represent the descrip-
tion of what is the piece of property that you own. Understanding these claims is key in determining if a
79
Engineering Management Handbook

product or process infringes the patent. This is oftentimes not an easy thing to do and we will discuss this
in more detail later. A few points about claims:
• If one claim is infringed the patent is infringed.
• All elements of the claim must be used by the product or process in order to be infringed.
• Many of the elements of a claim are part of the prior art. Only one element of the claim needs to be a
novel one.

6.5 What Can You Do with a Patent?

Now that you have a patent, what do you do with it? There are many inventors with the misconception
that a patent grants them the right to build something. What most people do not understand is that,
basically, a patent is a “negative right”—in other words, it is a right to exclude people from practicing
your invention. As we discussed earlier, recent rulings, in the U.S. in particular the eBay case, have made
the “right to exclude” harder to obtain. So perhaps the “right to exclude” is a bit broad but at least we can
say that a person needs to be compensated for his invention if someone else uses it. The idea that a patent
does not grant the inventor the right to build something may be difficult to understand. Let’s look at
this hypothetical. Assume that you have an invention for a new innovative chair. The chair has four legs,
a seat, a back and armrests. But your invention is the tilt of that chair. Your innovation is not so much
in the chair but in the mechanism of how the chair tilts. So in order to build a chair that tilts one would
also need to have the rights to build a chair. Those patents to build a chair may be owned by someone
else. The fact that you have a patent on the tilting mechanism does not give you all the rights to build
chairs. While this is a rather simple example for most people, it is important to see this in the context of
the complexity of modern products. The vast majority of patents are improvements to others’ ideas. It has
been said that inventors stand on the shoulders of giants. In other words, to create the next brilliant in-
vention, one often needs many previous inventions in order to make the product. The first microprocessor
needed the basic invention of the transistor and it also needed the first patent of an integrated circuit. In
fact, there was significant litigation between Intel and Texas Instruments as to who actually invented the
first integrated circuit.
So, if you can’t build something with a patent, then what can you do with the patent? The short an-
swer is you can stop someone and/or have someone pay you for the rights to use that invention. Frequent-
ly, startups wonder if they should get patents or not. Sometimes they think that their new products are so
unique that there is no competition and other times it is that they just don’t want to worry about the cost.
Most startups should begin a patenting program sooner rather than later, obtaining a patent should be
part of everyone’s business plan not because it grants you a right but because of the negative right that is
granted to you.
One of the things that often happens with patents is that patents are already licensed. In a startup
situation there are frequently other competitors who might not be direct but more tangential competitors.
They don’t offer the exact same product but similar products that use similar methods. Having a number
of patents that relate to your technology area is critical when it comes to licensing. If you are able to get
patents that somebody else uses and, in particular, that someone else is a person who wants you to pay a
license fee, you have the ability to trade licenses. This is called “cross-licensing” in the industry. What it
means is that I will license you my patents if you will license me your patents. Most licensing profession-
als believe these are the most numerous types of licenses that occur in industry today. While the number
of cross licenses agreements may be fewer than the number of total licenses agreements, the number of
patents covered by a cross license are significantly greater than the number of patents covered by non-
cross licenses. Actually, many cross licenses in the electronics industry cover the entire patent portfolio of
the companies. Most major companies require a license back if they are going to grant the license. The
reason is that at the point of the negotiation license they have the maximum leverage. What no one wants
to do is to go back to their boss and say “by the way I just licensed our patents to company X” but now
company X is suing us for patent infringement. This would be a career-limiting situation.
When talking about licensing there are typically two types of licenses that most companies grant.
They are either nonexclusive licenses or exclusive licenses. A nonexclusive license can be thought of as
80
 What is a Patent?

granting someone the right to use your invention but you are also telling the person that you will grant
others the same rights. To put this in a property context imagine that you have a plot of land. You may
grant people the right to travel over your land to get to the beach on the other side. You may even decide
to charge them for that right. But you will grant that right to many different people. You may also grant
the right to many different people at the same time. Imagine a town that owns the beach and charges
people a certain amount of money to park near the beach. This is a nonexclusive right to use the beach
parking facilities.
The other option is an exclusive license. With an exclusive license one only grants the rights to use the
invention to one person or company. That entity has the “exclusive” rights to use the invention. Back to
the example: If you wanted to be the only person to have rights to park at the beach and no one else could
park at the beach, you would then have “exclusive rights.” While this may sound excessive in our example,
there are examples in the property industry were “exclusive rights” are commonly found. For example, if
your property has certain natural resources on it, minerals from mining or timber for harvesting then you
may grant an entity “exclusive rights” to mine the minerals or harvest the trees. In a technology setting
exclusive rights frequently depend on the specific technology. Exclusive licenses are somewhat rare in the
high-tech industries of computer science and electronics. Many of these products require tens of thou-
sands or hundreds of thousands of patents to work and, therefore, granting an exclusive license is not
necessarily beneficial. In other industries like pharmaceuticals, where a specific formulation of the drug
might be covered by one or two patents, exclusive licensing is much more common.
Other than licensing, what else can one do with a patent? The other two options are: selling the
patent or abandoning the patent. To abandon the patent, not paying the maintenance fees that are due on
the patent accomplishes this. Many large companies in the electronics industry routinely abandon a large
number of their patents. These companies will periodically look at their portfolio to see if the patents they
are keeping in force are still useful.
Patents that are neither in the current marketplace nor relevant to the potential intellectual property
competitors should be considered for sale or abandonment. Frequently, because of the market dynam-
ics of the company and who the company’s customers are, it is not feasible for the company to assert its
patents against one of its customers. Since the company has developed a valuable portfolio and one of
its customer’s businesses is not relevant to its business, perhaps there is somebody else who may want
to buy the patent. It would make sense at this time to test the market and see who needs those patents.
Often companies will buy patents because they are entering into new markets where they feel they have
inadequate patent coverage. Oftentimes companies need to buy patents when they have few patents of
their own but have very successful products. Recent history abounds with companies that fall into that
category: Cisco, Broadcom, Google, HTC and Xiaomi have all faced this issue. In each case, the very
successful product company had not developed a strong enough patent portfolio quickly enough to fend
off those who thought they were due license fees. This led to litigation and a need for these companies to
buy patents as well as to file more patents quickly. Since filing a patent takes a long period of time it was
very difficult for these companies to gain protection from an internally generated patent portfolio if the
patents took between three and five years to issue. Additionally, when generating a new patent portfolio
the inventions that are generated often do not become commercially acceptable until many years after the
patent issues.

81
82
 Leading Individuals and Engineering Project Teams

7
Leading Individuals and
Engineering Project Teams

Donna Brazil
United States Military Academy

Darcy L. Schnack
United States Military Academy

83
Engineering Management Handbook

7.1 Introduction
As an engineer chances are very good that you were hired for your technical skills and expertise. You stud-
ied hard in school, you are technically savvy, and you certainly know your area of expertise. You worked
your way up in the organization and now they want you to lead an engineering project team. Initially,
you were excited about this promotion and new challenge, but now after just a few meetings you are
beginning to think twice about that excitement. As you think back to your preparation, you suddenly
realize that while you were promoted because you were a good engineer, no one really trained you to lead.
A great definition of leadership is that “Leadership is providing purpose, direction and motivation
while operating to accomplish the mission and improve the organization” (U.S. Army, 2012). It gives
the leader a starting point – providing purpose, direction and motivation as well as dual end states – to
accomplish the mission and improve the organization. Let’s look at the starting points first and return to
the end states later.
This chapter will begin by introducing the basics of a systematic way to approach leadership. We will
start with understanding yourself as a leader and then look at the characteristics of followers, motivational
issues that might arise when leading individuals, and some issues that are common to all groups. We will
then turn to theories of leadership that take the situation and the task into consideration.

7.2 The Leader

Before you can expect to lead anyone else, it is important to assess where you yourself are as a leader.
Commonly referred to as self-awareness, this can be seen as broad individual self assessment. Quite sim-
ply, becoming self-aware involves developing a clear picture of yourself through self-assessment, peer and
superior feedback, and formal and informal 360-degree assessment tools. Personality inventories, critical
thinking tests, and emotional intelligence quizzes are all examples of self-awareness tools that are available
online and can be used as part of this assessment process. These tools can make you aware of your prefer-
ences, leadership and learning styles, biases, character strengths, and much more. Through the self-assess-
ment process, you can begin to determine what you see as your strengths and weaknesses and what areas
you would like to develop more fully.
One way to think about self-awareness is to imagine yourself as a combination of a number of pos-
sible “selves” (Markus and Wurf, 1987). The makeup of these selves comes from a number of different
sources. Who do you think you are? Who does your boss think you are? Who do your subordinates
think you are? Who does your family think you are? A final self you should consider is what Markus
and Wurf calls your ideal self – the person you would like to be – what characteristics would you like to
own and display as a leader? Through this self-assessment process, you can piece together this informa-
tion to determine where you are in terms of your current self and where you would like to be in terms of
your ideal or desired self. In this way you can identify strengths you would like to build on and gaps that
you would like to address. You can then develop a personal action plan for working to close those gaps.
Often this plan will include a systematic attempt to use new behaviors and an assessment to determine
if they fit better with who you would like to be as a leader. Perhaps through your self-assessment process
you discover that although you believe that you are approachable and open to new ideas, your subordi-
nates and friends tell you otherwise and list occasions where they have felt that their suggestions have
been ignored. You might work hard to listen to those around you and incorporate their ideas into your
next project. Such attempts, if successful can help to boost your self-confidence and desire for further
growth and development.
Just as taking the time to get a complete picture of yourself is important before you set out to lead
your team; this is also a good time to take stock of what biases and preferences you might bring to the
table as a leader. Each of us has a history and a comfort zone of behaviors that we will fall back on as a
default. Identifying these preferences so that we are aware of them is critical to approaching situations
with an open mind. One such preference that is very common is for people to be more comfortable with
others who are similar to them. This similarity can be across a number of dimensions including age, race,
gender, and technical specialty. It is important that you think about this simple preference as a potential
area of bias and what this might mean to your work situations.
84
 Leading Individuals and Engineering Project Teams

A fascinating tool for discovering your preferences is the Implicit Associations Test (IAT) developed
by researchers at Yale, Harvard and other institutions. Available at https://implicit.harvard.edu/implicit/
This tool offers you the opportunity to measure the strengths of your preferences on a number of dimen-
sions from gender and race to religious and political affiliation as well as current social issues such as self
esteem, anxiety and mental health (Project Implicit, 2011). The results do not predict behavior but they
might provide you with personal insight into your preferences. Keep in mind that having a preference or
bias is not the same as acting on that bias, but having thought about them beforehand is critical to mini-
mizing the potential impact. Acknowledging these preferences upfront will make you more self aware
and better prepared to manage and leverage diversity on your team and to try new behaviors in this
new situation.
Some key self-awareness issues to think about from the perspective of a leader:
What are my predispositions toward:
• People of other races?
• People of the opposite gender?
• People of a different sexual orientation?
• People from a different academic or technical discipline?

What is my preferred method of interacting with others?

• Do I tend to keep my ideas to myself?
• Do I prefer to work alone?
• Do I tend to delegate everything?
• Do I tend to micromanage?
• Do I seek consensus on decisions?

What are my beliefs about people in general?

• Do I believe that people are inherently good?
• Do I believe that people are inherently bad?
• Do I believe that I must motivate people through rewards and punishments?
• Do I believe that the best way to have something done right is to give very explicit directions?

As you can see from this short list, there are many facets to being a leader and it is helpful to take
stock of yourself and your preferences and determine if they are the best fit for your particular situation.
If they are not, you might consider how you can develop your capabilities in these particular areas. Tak-
ing time upfront to consider these issues before you are under a deadline or in the middle of a crisis will
certainly be time well spent.

7.3 Leading Individuals

Just as each leader brings to the table different skills, attributes and needs, so does each individual mem-
ber of the group. As a team leader it is your job to bring together this collection of individual skills and
attributes to work toward a common task. A great place to start is in understanding your team members,
their strengths, their weaknesses and what each of them can and seek to contribute toward the goal. No
two people are exactly the same and the skills and desires of two people are the same either. Many of the
predispositions and preferences that you evaluated within yourself will be present in your team members.
Asking them what leader and management style they prefer would be a great first step in making sure you
understand and meet their needs and desires.
As identified in the definition of leadership at the start of this chapter, a significant part of leadership
is providing purpose, direction and motivation to accomplish a task. For engineering management team
members, purpose and direction are easy – skilled technicians are good at that. Providing motivation can
be a bit trickier. There are many theories of motivation that can assist you in leading your team and each
of them requires that you as the leader look at each individual in order to determine if they are motivated
or not and if they lack motivation, then to determine what exactly is it that they need.
85
Engineering Management Handbook

The common way to look at motivation is to focus separately on intrinsic and extrinsic motivation;
intrinsic motivation comes from within the individual or task itself while extrinsic comes from an external
force. We will come back to intrinsic motivation later, but let’s start with extrinsic.
Extrinsic motivation is an external force, normally a reward or threat of a punishment that compels
an individual to accomplish a task. The more they want the reward (or want to avoid the punishment),
the more motivated they are work to accomplish the task. Sounds simple, right? So why doesn’t it always
work? Researchers have discovered a number of explanations that are worth your consideration as you
begin to diagnose the motivation issues of your team members.
Stacy Adams (1965) explained a lack of motivation through the lens of fairness or equity. He sug-
gested that individuals seek to get their “fair share” out of most situations. In a simple explanation, equity
theory suggests that group members look at their inputs (work, effort) and their outcomes (compensation,
praise, self-worth) and determine if their ratio is equal to or better than the other members of the team. If
they feel that their input/outcome ratio is lower than their peers’ then they will determine that the situa-
tion is inequitable and will work to resolve that inequity (Adams, 1965). When team members think that
they are being treated unfairly in a situation, they might lower their effort or in extreme situations, they
might quit altogether. As the team leader, you can work with the members and try to see the situation as
they see it. Sometimes they will identify a valid inequity in the system that you were not aware of. Often,
you will find that you and the team members have different perceptions about the quality and quantity
of both inputs and outcomes and all that is required is talking about the differences so that you all have
a clearer picture of the situation. The bottom line in these situations is to understand that perceptions
matter, and addressing the perceptions of your team members will make them feel valued and will in turn,
increase their motivation.
Another theory that explains possible sources of motivation issues is expectancy theory (Mitchell,
1974). Based on expectancy theory, individuals are motivated to perform a specific behavior to a specified
standard in order to receive a specific reward. This framework is helpful in understanding motivation as
it enables a leader to break a situation down into three components: the specific individual behavior that
you want the member to perform, the standard that you want the performance to reach and the reward or
outcome that the team member will receive for meeting this standard. Motivation therefore comes into
play in any one of three ways: the team member might lack the confidence that he or she can perform
the task to the established standard; the team member might not trust that he or she will actually get the
promised reward or finally that the team member might not value the promised outcome or he or she
believes that the energy expenditure required to meet the standard is not worth the outcome. Using this
framework as you approach the situation of a seemingly unmotivated subordinate, you might first ask
yourself a few questions. What is the task I want completed? What standard have I established for this
task? What will the team member get for his or her effort?
Since a motivation issue can involve any one or more of these components, you should then talk to
the team member to determine which linkage is weak. Your leader action will follow directly from the
weak link. If the team member lacks the confidence to meet the standard, you might break the task down
into smaller subtasks or you might ensure that the team member gets additional training, or if necessary,
you might revaluate the standard. If the team member doesn’t believe that you or the organization will
provide the promised outcome, you must work on trust issues and ensure the team member that you will
in fact make good on your promises. Most trust issues are based on past experience so you will need to
convince the team member that you are different than their past leaders and that you will see to it that the
reward is realized. Finally, if the team member does not value the reward or thinks that it is not worth the
effort, you can discuss what they would like as the reward and try to come to a compromise that will suite
you both.
Equity and expectancy are two ways to look at extrinsic motivation. While most of us desire and
indeed need compensation for our work, many professionals stay in their particular field for intrinsic
reasons. Certainly, we could earn more money, have a bigger house or expense accounts; but we like what
we do, it gives us meaning. When these team members lack motivation, another way to diagnose the
situation is to through the components of intrinsic motivation (Deci and Ryan, 1985). In terms of Deci
and Ryan’s theory, individuals who are motivated intrinsically are thought to find completing the task
86
 Leading Individuals and Engineering Project Teams

enjoyable in and of itself. Intrinsically motivated individuals enjoy tackling a new task and finding a new
way to solve the challenges. They are motivated by being given the opportunity to challenge themselves
and the freedom to determine their own course of action.
Understanding these conditions will help you as the team leader of intrinsically motivated members.
These members enjoy taking on and accomplishing new challenges and being allowed the freedom to
figure it out. These individuals find the challenge rewarding and might feel manipulated when offered
a reward as an incentive for completion. Any rewards for these individuals should be given after com-
pletion of the task and will serve as information – namely that their performance was exceptional and
appreciated.
You are probably thinking that intrinsic motivation and extrinsic motivation are at odds with each
other. In some ways, you are correct and this highlights the importance of your initial diagnosis of the
situation and your team members. Promising a reward to one person will assist in raising motivation,
while for another, it could make him or her feel manipulated and therefore lower motivation. According
to expectancy theory, challenging a team member who feels uncertain about his or her performance might
overwhelm and cause a drop in motivation while an intrinsically motivated team member will excel when
challenged. Obviously, the key to selecting the best actions as a leader start with truly understanding your
team members. It is important to take the time to know what their strengths and weaknesses are as well
as what they value and expect from you as their leader.
Remember, just as you are different than every past leader, your team members are different from
each other. Each comes with a history, with varying levels of experience and with different personal
needs. The better you understand them, the better you will be able to bring them together as a team.

7.4 Leading Teams

Just as humans develop in fairly predictable patterns and go through developmental stages, so do groups
and teams. Understanding Tuckman’s (1965) model of group development and reflecting on the actions
that a leader can take to facilitate a team’s progression through the stages of development can be invalu-
able to you as a leader. The steps of group development include, forming, storming, norming, performing
and adjourning. Let’s take a closer look at each step.

7.4.1 Forming
In this first stage of group development, members are more concerned about personal characteristics and
issues than they are about actually performing the task. This is a time when group members attempt to
figure out how they fit in, who has status, what skills everyone has and so forth. Many leaders come to
the first team meeting with a full agenda planning to jump right into a meaty discussion of the project at
hand. A leader who understands group development and who has thought through the “first encounter”
will facilitate the needs of his or her team by allowing some time up front for the informal interaction that
the team needs. You can also assist the group in working through this stage of development by clarifying
roles and facilitating their desire to share information among each other.

7.4.2 Storming
As groups start to get to know each other and work together, it is normal for them to enter a period of
conflict. In this stage, members are assigned to roles and differences in status begin to emerge. Some
members might believe that they are better qualified to perform a task than the member who was assigned
to it; others might be concerned about where they fit in. Informal leaders might begin to build allianc-
es with other members in order to solidify their position in the group. While it can appear chaotic and
messy, this is an important time in the development of a group. You should not think that you are failing
because the group begins this period of conflict; on the contrary, most teams that never go through this
stage have probably never really been tested and when they do hit rough times, the issues that were never
resolved will come to the surface. You can facilitate the group’s movement through this stage by working
to build consensus, investing the time to assist with role clarity and negotiation, and openly discussing
87
Engineering Management Handbook

conflict issues. If you can work to eliminate or minimize these sources of conflict, you can facilitate the
group’s movement to the norming stage.

7.4.3 Norming
Groups really start to click during the norming stage. They have achieved consensus on how tasks should
be accomplished, they have established norms that are self-enforced and individual status has been iden-
tified and agreed to. There may be some cycling back through storming and norming as new members
or tasks are added but as the norms solidify, the cycles become shorter and the smoother. In this stage
you as the leader can start to focus more on the social and emotional needs of group members and you
might serve the group best by keeping them focused on the task by ensuring their other individual needs
are met. Leaders of groups at this stage need only give guidance and allow the systems that the group has
developed to take over. That said, there might be a tendency in this stage to allow the “systems” to substi-
tute for thinking and decision making. You must be attentive to rigid adherence to a system that has been
agreed on but is no longer functional. You can assist the team’s development by playing or appointing
a devil’s advocate, encouraging deviance from time to time and sharing the leadership decisions of the
group. Groups who successfully negotiate this stage move on to the performing stage.

7.4.4 Performing
In this stage, group members are very comfortable with themselves and each other. They are interdepen-
dent and creative. They are not wedded to any particular structure or system and instead are expected
to suggest improvements and point out potential problems. As the leader you are able to fade into the
background and are completely free to work strategic issues that might facilitate the group’s current task
or future task.
By now you are probably thinking to yourself “well that’s a great theory, but my REAL teams never
get that far.” Well, take comfort in knowing that you are not alone in your experience. Despite the name
of the “performing” stage, groups will perform – and if forced to, will produce something– no matter
what stage they are in. In fact, some groups never get out of the storming stage as they continue to go
about their task.

7.4.5 Adjourning
Few groups exist in perpetuity. Recognizing this and reviewing subsequent literature, Tuckman and
Jensen (1977) updated an earlier model of group development to address the feelings of separation a
group experiences as it disbands. Members may feel a sense of loss for group relationships or distress over
accomplishment of group goals. As a leader, it is important to focus on communication within the group
and to prepare for this stage if the group’s dissolution is anticipated. Take the time to celebrate the group’s
accomplishments and the teamwork that you have all shared. As a leader, understanding the normal stages
of development and the issues faced by group members at each stage can assist you in facilitating the
needs of the group. Quite simply, a group performs better at a higher stage of development. If you are
able to recognize the issues and move your group forward, all the better.
Having discussed the importance of understanding yourself as a leader and the individual and group
characteristics of the followers, it is now time to turn our attention to leading.

7.5 Leading
The issues and discussions above are all absolutely critical functions of a leader and are almost prereq-
uisites to being able to enact the traditional theories of leadership. For these theories to be effective, a
foundational understanding of yourself and your team members is essential.
Perhaps the most useful leadership theories for an engineering management team leader are contin-
gency theories that take into consideration both the characteristics of the team member and the charac-
teristics of the situation. These theories, developed in the early 1970s focus on understanding the level
of structure of the task and the team members’ skill with regard to the task as well as their motivation
88
 Leading Individuals and Engineering Project Teams

toward completing the task. The most well known of these theories is Hersey and Blanchard’s Situational
Leadership Theory (Blanchard, Zigarmi and Zigarmi, 1985). This theory requires that the leader first
understand both the task requirements and the development level of his or her team members and then,
taking these into consideration apply the appropriate amount of task and relationship behaviors. Leader
behaviors that are high on task direction and low on building relationships are appropriate for team mem-
bers who are low in competence but high in their commitment to task completion. As team members
become more competent and perhaps begin to waiver in their commitment to the task, the leader must
begin to ease off on providing direction and begin to focus more on building supportive relationships. At
the far extreme, team members who are extremely competent and highly motivated need little direction or
external motivation.
While the tenants of Situational Leadership Theory might seem simplistic and intuitive, many of us
can recall a leader who failed to recognize that we were at either extreme and insisted on providing inap-
propriate leadership at the critical moment. Either the leader continued to be very direct despite your
skill development or the leader took a delegating approach when you really did not have all of the re-
quired skills. Either mismatch can have serious negative repercussions for both the team member and the
team. According to Situational Leadership Theory, as the team members’ progress from low skill with high
motivation through varying skill with varying motivation to high skill with high motivation, the leader
should at first be directive, then take on a coaching role, move into a fading supportive role and finally
realize that it is time to delegate.
Until this point in the chapter we have been concerned primarily with the first part of the definition
of leadership – namely providing purpose, direction and motivation in order to accomplish the mission.
While certainly required of a good leader, your job is not yet complete. We must now turn our attention
to the last end state of that definition: improving the organization. While you personally might have felt
unprepared for your first leadership position, it does not (and should not) have to be the same for your
team members. Part of your job as a leader should be to develop your replacement.

7.6 A Leadership Development Model

Many Engineering Leader Development Programs (ELDP) focus on a specific skill set or competency
that will enable a young engineer to better negotiate a particular new position or a specific new challenge.
While these programs might be effective in the short term, very few models incorporate development
across a broad spectrum of situations and developmental levels. What follows is a discussion of one such
model that can and should span an entire career. This discussion is based on the leader development
framework developed by the Center for Creative Leadership (CCL) (McCauley and VanVelsor, 2004).
The foundation of this model was derived from the result of hundreds of developmental sessions with
executives, educators, business managers, and military officers. Their work provides a skeleton for under-
standing the impact of various developmental programs and for beginning to integrate these initiatives
into a coherent whole.
The CCL defines leader development as the “expansion of a person’s capacity to be effective in leader-
ship roles and processes” (McCauley and VanVelsor, 2004, p. 2). This definition is especially applicable to
team members in technical fields because the emphasis is on the individual. It seeks to increase capacity,
not meet a preestablished set point and it acknowledges that there are many leadership roles along the
route from follower to chief executive officer. The expansion of a person’s capacity can relate to any type
of development, from technical expertise to leadership skills. The framework is quite simple and is based
primarily on three components: assessment, challenge and support.

7.6.1 Assessment
The assessment component calls for leaders to become self-aware. As your team members begin to take on
more responsibility and prepare to become leaders themselves, they should seek out feedback from others
and should begin to assess themselves in terms of their strengths, weaknesses, preferences and predisposi-
tions. The model calls for the same introspection and self-assessment that we looked at in the beginning
of this chapter. As their leader, you will be in a unique position to provide feedback help to identify
89
Engineering Management Handbook

developmental gaps that they should address. If possible, gathering feedback from peers and subordinates
will round out the assessment picture and give the individual a 360-degree assessment.

7.6.2 Challenge
A second key component of leader development is challenging experiences. Your engineers must be
directed or encouraged to undertake experiences that will challenge them and push them out of their
comfort zone, experiences from which they will grow and develop. Runners will never get faster if they
only run at a comfortable pace. They may stay in shape and maintain good cardio fitness, but they will
never get faster if they do not push and challenge their ability by going faster and faster on training runs.
The same principle holds true for leadership. Engineers will never improve their interpersonal, communi-
cation, managerial, etc., skills if they stick to other aspects of the project that they feel comfortable with.
For example, engineers stick to the design and the production, and never accepts the challenge to speak
with the other group members or the customer, they will never grow in that area. Too often, engineers
remain in their technical comfort zone and do not cultivate other elements of the “whole” leader.
Individuals develop by taking on stretch assignments, situations, and experiences that offer them a
challenge outside of their comfort zone. These are not assignments that are completely outside their area
of expertise – a runner does not attempt to be a better runner by learning to scuba dive – nor would we
necessarily want an engineer student to attempt the stretch assignment of public relations. The challeng-
ing experiences should be based on what you or the individual determined to be a gap in their develop-
ment during the assessment phase. Truly challenging experiences make individuals uncomfortable and
create a disequilibrium that they must work to resolve. They are forced to develop and try new skills
when their tried-and-true favorites do not work. This is true for all areas of development and especially
true for leadership development. Leaders in technical organizations and management teams must be
encouraged and rewarded for seeking out challenging leadership experiences.

7.6.3 Support
Support comes in many forms. Universities, corporations, etc., must recognize the need for this develop-
ment and allow their engineers the time and resources required. In academics, this may require restruc-
turing graded requirements in preexisting courses or developing entirely new course goals and objectives.
In corporations, this might involve formal mentoring, rotational training, professional coaching, and
professional development activities.
Another form of support comes from those surrounding the leader. Leaders must have a person
or group of individuals that they can turn to in order to help them make sense of the experiences they
have had and the feedback they have received. Far too often young engineers live through challenging
experiences and simply throw it them into their files, never to be seen or evaluated again. These valuable
experiences can be powerful but without reflection, no growth takes place and, as a result they are not
significant in their development. The real promise for growth and development is in the processing of
that experience, either alone or with the help of a trusted friend, peer or mentor. In these after- action
reviews that look at the engineer’s actions, inactions, decisions and interactions are rich learning oppor-
tunities that will expand their capacity to do the same or better the next time they are presented with a
similar issue. In our fast-paced, just-in-time culture, it is often difficult to take time out to reflect on our
experiences and seize the developmental opportunity. As a team leader you must recognize this tendency
and purposefully set aside time and resources to enable and assist your team members in making the best
of each growth opportunity.
Along with support must come the freedom to fail. Teachers, peers, mentors, coaches, and superiors
must understand that not all challenging experiences will be met with complete success. What truly mat-
ters from a developmental perspective are the lessons that the individual takes away from the experience
and his or her ability to own that experience and the lessons learned. As a team leader, you must set up
learning and developmental opportunities for your team members and provide them the support to make
all of their outcomes opportunities for growth.
90
 Leading Individuals and Engineering Project Teams

7.7 Closing Thoughts

When striving to improve the organization and the members of the organization, another leadership
theory comes to mind as very applicable. Much of the discussion above focuses on the leader applying
the appropriate leader action that the follower needs for a specific situation. Transformational Leadership
Theory (TLT), on the other hand, focuses on the relationship between the leader and the team members
as well as the long-term development of the follower. TLT was first identified by the political historian
James M. Burns (1978) who sought to explain the power behind great leaders who seemed to transform
their followers in support of a cause. Social scientists built on this original idea and have attempted to
isolate the behaviors of these leaders as well as the outcomes that are engendered in the followers. Bass
and Avolio (1994) suggested that leaders who have a vision of where they want their team to be, commu-
nicate high expectations and confidence in their team members, demonstrate individualized concern and
use innovative and unconventional strategies when interacting with their followers develop team members
who in turn are inspired, empowered and motivated to do more than they thought they could. Transfor-
mational leaders still manage the details and still seek to know themselves and their subordinates. They
will occasionally deal with feelings of inequity and problems with motivation but over time the as they
live and demonstrate the behaviors mentioned above, their team members identify with and internalize
the assignment, the cause, or the task at hand and the leader can fade into the background.

7.8 References
Adams, J. S., “Inequity in Social Exchange,” In L. Berkowitz, Advances in Experimental and Social Psychol-
ogy (pp. 276-299), New York: Academic Press, 1965.
Blanchard, K. Z., Zigarmi, P., and Zigarmi, D., Leadership and the One Minute Manager: Increasing Effect-
iveness Through Situational Leadership, New York: William Morrow, 1985.
Bass, B. M. and Avolio, B. J., (eds.), Improving Organizational Effectiveness Through Transformational
Leadership, Thousand Oaks, CA: Sage, 1994.
Burns, J. M., Leadership, New York: Harper & Row, 1978.
Deci, E., and Ryan, R. M., Intrinsic Motivation and Self-Determination in Human Behavior, New York:
Plenum Press, 1985.
Goleman, D., Boyatzis, R., and McKee, A., Primal Leadership: Realizing the Power of Emotional Intelli-
gence, Boston: Harvard Business School Press, 2002.
Project Implicit, Implicit Associations Test, 2011, Retrieved September 8, 2015, from Project Implicit:
https://implicit.harvard.edu/implicit/
Markus, H. and Wurf, E., “The Dynamic Self Concept: A Social Psychological Perspective,” Annual Re-
view of Psychology, vol. 38, 1987, pp. 299-337.
McCauley, C. D., and VanVelsor, E. (eds.), Handbook of Leadership Development, San Francisco: Josey
Bass, 2004.
Mitchell, T. ,“Expectancy Models of Job Satisfaction, Occupational Preference and Effort: A Theoretical,
Methodical, and Empirical Appraisal,” Psychological Bulletin, vol. 81, 1974, pp. 1096-1112.
Tuckman, B., “Developmental Sequence in Small Groups.” Psychological Bulletin, vol. 63, 1965, pp. 384-
399.
Tuckman, B. and Jensen, M., “Stages of Small-Group Development Revisited,” Group & Organization
Management, vol. 2, 1977, pp. 419-427.
US Army, Army Doctrinal Publication (ADP) 6-22, Washington, DC: US Army, 2012.

91
92
 Managing the Multi-Generational Knowledge Based Workforce

8
Managing the Multi-Generational
Knowledge Based Workforce

Gene Dixon
East Carolina University

93
Engineering Management Handbook

8.1 Introduction
In order to create a productive work environment, generational gaps have to be approached in a way that
benefits employers and employees. To have a positive affect with the differences in behaviors between the three
majority generations currently in the workplace, a general understanding of generational difference is needed.

8.1.1 Overview
Employers and employees of all ages must work proactively across all generations to create an effective
work dynamic. Engineering managers and engineers can benefit from knowing how generational norms
impact the work dynamic. Management’s understanding of the diversity of values and beliefs of genera-
tions will facilitate effective management and create a productive workforce.
Silver (2011) described diversity as a value of different perspectives. For some countries, the
multi-generational workforce reflects a range of employee age that has not previously been experienced, a
demographic remix.
In America, the generational remix means that (Silver, 2011):
• Currently, there may not have enough workers to take care of older Americans
• By 2023, minorities will comprise half of all children; 62% by 2050
• By 2030, 1 in 5 Americans will be over 65
• By 2042, there will no longer a majority race
• By 2050, the Hispanic population is expected to triple
• By 2050 the 18 – 64 age workforce will decline from 63% to 57%

From a broader perspective, Silver (2011) reported that:

• Educational levels are trending down
• More children are being born to unwed mothers
• Marriage rates among young adults (25-34) is in decline
• Multi-generational households are increasing

All of these trends are expected to have some impact on emerging generational norms that will also
impact the workplace.

8.2 Generations
Research studies do not draw arbitrary and abrupt lines between generations (Jorgensen, 2003). For
convenience, generational age brackets are identified to support the research agenda. Jorgensen (2003)
marked generations by particular historical events while Shaw and Fairhurst (2008) defined a genera-
tion as starting with an increase in the birth rate and ending with a birth rate decline. Birth rates often
trend with societal or historical shifts. Events are not momentary; history unfolds over periods of time
and therefore the definitions have considerable overlap. In a sense then, a generation is a demographic
cross-section that possesses commonality related to defining social or historical events.
Common life experiences are theorized to create commonalities of perspectives, attitudes, and
assumptions within a generation (Blythe et al., 2008). Generational groups develop distinct values and
workforce patterns according to Blythe et al. (2008). Common generational values are attributed to
generations: Baby Boomers, those born between 1946 and 1964; Generation X, born between 1965 and
1979; and, Generation Y also known as millennials were born after 1980 (Keepnews, Brewer, Kovner and
Shin et al., 2010). As Baby Boomers age and move out of the workplace, Generation X progress through
the work hierarchy, and the Generation Y/millienalists enter into the workforce.
Increasingly, engineering managers find themselves addressing the values and patterns of a multigen-
erational work environment. This environment requires an understanding of generational differences
in order for the workplace to remain attractive to employees. The work environment preferences of the
various generations and the impacts on motivation, productivity, and other basic workplace cultural and
structural pediments must be understood and leveraged. Engineering managers are often responsible for
94
 Managing the Multi-Generational Knowledge Based Workforce

creating a productive environment, productive processes, and supporting systems that stimulate employ-
ees of all generations to high performance. The organization’s processes and systems provide a framework
for building loyalty and commitment (Dixon and Knowles, 2013).
Specific generations dominate the workplace. They are the Baby Boomer Generation, Generation X,
and Generation Y. Each of these generations display distinct characteristics and make significant positive
contributions toward a global economic landscape.

8.2.1 Baby Boomers

The “Baby Boomers” are a generation defined by events such as the Vietnam War, the assignations of Pres-
ident John Kennedy and civil rights advocate Martin Luther King Jr., and the sexual revolution (Adams,
2000). The toll of these events on the Baby Boomer population contributes to their lack of respect for
authority (Dixon and Mercado, 2011). Baber Boomers tend to be optimistic, as if the planet was theirs,
and have a great sense of teamwork (Zemke, Raines, and Filipczak, 1999). They are dedicated to their
work and are sometimes called workaholics due to their dedication to their jobs (Keepnews et al., 2010).
Baby Boomers are entering the twilights of their careers and are retiring, moving into roles of corporate
leadership or pursuing philanthropic endeavors in their communities (Dixon and Mercado, 2011). Baby
Boomers will continue to influence the workplace through 2020. A summary of some general characteris-
tics of Baby Boomers’ behaviors follows (Dixon and Mercado, 2011):
• Willing to invest themselves in, and serve, the organization,
• Need to distinguish themselves from peers,
• Will not confront issues directly,
• Resistant to change, and
• Team players who believe in lifetime employment.

8.2.2 Generation X (Gen X’ers)

Generation X experienced the oil crisis of the 1970s, the stock market crash of the 1980s, and the effects
of those historical events on their family life during their formative years. The economic impacts of these
events saw them face the experiences of their parents losing jobs, relocation, or lower incomes. This has
created a norm where Gen X’ers are characterized as working to live versus living to work, a baby boomer/
parent norm (Dixon and Mercado, 2011). Being motivated drives their lifestyles (Loomis, 2000) and
they look for career opportunities offering a collaborative work environment. Gen X’ers want challenging
opportunities with flexibility and recognition (Loomis, 2000). Members of Generation X may skeptical,
independent, and energetic, with less loyalty than Baby Boomers (Ansoorian, Good, and Samuelson,
2003). Jobs are viewed as openings for competency building, i.e., they value opportunities for learning
and training over loyalty and pensions (Ansoorian, Good, and Samuelson, 2003; Bova and Croft, 2001).
Hoerr (2007) stated that Gen X’ers respond well to change, are not intimidated by authority, and are less
bound by structure and hierarchy than previous generations. A summary of some general characteristics
of Gen X’ers (Dixon and Mercado, 2011):
• Use teams to support individual efforts and relationships
• Relationships take precedence over careers
• Likely to challenge but expect friendly work relationships
• Education is a necessary tool
• Comfortable with diversity and change
• Also known as Buster or Me Generation or latchkey kids
• First of the technologically adept generations
• Individualistic with a casual disdain for authority
• Dislike being micromanaged
• Value work/home balance
• Emergence of creative class

95
Engineering Management Handbook

8.2.3 Generation Y (Gen Y)

The Generation Y, or the “Millennial Generation,” has experienced historical events including the Persian
Gulf wars and the 9/11 attacks. This generation has parents that are still involved in Millennials’ lives and
who are referred to as “helicopter parents” as they are want to drop in and rescue their millennial at any
time (Coley, 2009). Millennials have grown up with an electronic and wireless network of computers and
smart phones, which they use for texting and personal networking via social media. Their linking behav-
ior is expected to be permitted in the workplace. Millennials see education as a commodity that includes
limitless options (Merritt and Neville, 2003). This generation values personal connections, want to know
all about their contacts, and don’t mind revealing information about themselves (Coley, 2009). Millenni-
als desire intensive support, and expect value-added experiences, clear investment outcomes, and diversity
within their environments (Coley, 2009). Brown (2011) stated that a work-life balance is the Millennial’s
primary concern. A summary of some general characteristics of Millennials include (Dixon and Mercado,
2011):
• Accustomed to working in teams; will assume responsibility for team
• Want clear direction; must be challenged
• Value honesty
• Embrace transformation
• Will leave if not challenged or supported by their work environment
• Will sacrifice personal security for attention
• Needs constant feedback and attention
• Not to be forced, they live on choice
• Move from job to job
• Achievement-oriented, team-oriented
• More radically and culturally tolerant than previous generations
• Prefers urban lifestyle; place matters, not just job
• Environmentally conscience

8.3 Management Impacts

Generational impacts on management systems and styles are trending toward the frontlines of manage-
ment literature. In this section, the characteristics of the three generations are briefly examined.

8.3.1 Baby Boomers

Dixon and Knowles (2013) studied Baby Boomer workplace tendencies in regards to loyalty and follower-
ship and found that they tended to be loyal to their employers while demonstrated the behaviors charac-
terized by followers (Chaleff, 2009). Boomers are recognized for their positive attitudes toward work and
their abilities in building consensus, mentoring, and effecting change (Smola and Sutton, 2002). Mc-
Guire, By and Hutchings (2007) reported on research showing that Baby Boomers have relative high pro-
ductivity relative to their experience, organizational commitment and stability. Gibson et al. (2010) found
Baby Boomers to be comfortable with change, loyal, security oriented, workaholic, and idealistic even to
the point of allowing work life to come before family life (Keepnews et al., 2010). Sixty-six percent plan
to remain active in the work place following retirement (Ansoorian, Good, and Samuelson, 2003).

8.3.2 Generation X
Gen X’ers have high value for professionalism (Blythe et al., 2008), yet tend to be cynical and untrusting
(Ansoorian et al., 2003). Gen X’ers entered the workforce during the popularity of workforce reengineer-
ing and organizational restructuring. As a result Generation X does not expect organizational stability
and demonstrate a high tolerance for career risk (Blythe et al., 2008). Generation X may lack a sense of
traditions and demonstrate a sense of individualism (Jurkiewicz and Brown, 1998) tempered with support
from their network of colleagues (Kuperschmidt, 2000; Karp, Sirias, and Arnold, 1999). Gen X’ers have a
96
 Managing the Multi-Generational Knowledge Based Workforce

need to be mentored (Jurkiewicz and Brown, 1998) and want immediate feedback. They bring practical
approaches to problem solving and expect employers to listen, provide a facilitating culture, and pay fairly.
Organizations that provide opportunities for improving knowledge, skills and work attitudes enable Gen
X’ers mobility (Ansoorian et al., 2003; Chen and Choi, 2008). McGuire et al. (2007), reported that Gen-
eration X values working for themselves and capitalizing on employment opportunities.

8.3.3 Generation Y
As the most technologically literate of the workforce (Blythe et al., 2008), and want their work to be
meaningful and have opportunity to contribute to a higher purpose. Hira (2007) identified the Y-Gen as
high maintenance needing supervision and feedback. Gen Y are capable multitaskers (Shaw and Fair-
hurst, 2008) seeking employment where they can experience: a fun environment, growth opportunities,
a variety of work projects, chances to learn new skills, and flexible schedules that support of a balanced
work-life (Kuperschmidt, 2000; Carver and Candela, 2008). The Gen Y is accustomed to teamwork and
desires supervision and structure. They have an affinity for sustainability. If not challenged and support-
ed, they will job hop (Carver and Candela, 2008). Retirement benefits are important in their job choices
(McGuire et al., 2007).
Retention is a function of commitment (Dixon, Mecado, and Knowles, 2013). In the next section,
the correlation of commitment and generational influences are discussed. When employees are commit-
ted, turnover is reduced.

8.4 Management Strategies for Leaders and Followers

Inter-generational conflicts are recorded throughout history (Tomkiewicz and Bass, 2008). When dif-
ferences in generational norms affect working relationships, the resulting conflict can affect workplace
performance. Generational interdependence correlates positively where generationally diverse employees
share a common end state (McGuire et al., 2007). Intergenerational conflict may be serious during orga-
nizational reengineering when work groups are targeted by seniority. The severity of these conflicts can
be a function of cross-generational distrust and animosity as the struggle for jobs becomes acute. When
times are good, generations are tolerant at least, cooperative at best (Dixon et al., 2013). Generationally
diverse talent pools are an important step in for sustaining organizational cultures (McGuire et al., 2007).
Programs for employee development should relate generational norms and work tasks to strategic initia-
tives. Stretch assignments requiring diversity in skills, knowledge and abilities related to intergenerational
capabilities, knowledge, and skills are powerful methods for increasing commitment across generations.
Anderson (2010) suggested that intergenerational employee development start with younger em-
ployees. This may be impractical as the body of work knowledge is usually held by older generations.
Members of older generations must recognize that the organization’s future belongs to younger engineers.
Members of younger generations flourish on teamwork that lends itself to employee development, partic-
ularly when attention is given to having generational or age-diverse team members. The different set of
network skills that younger generations possess must also be guided toward understanding administrative
processes, building relationships across generations, and following established procedures before openly
advocating for a more hierarchal-free workplace; i.e., know it before you change it.

8.5 Optional Content Commitment

Organizational commitment is a term used to describe an employee’s psychological connection to the orga-
nization (Dixon et al., 2013). Each generation holds different beliefs and values, which vary across the gen-
erations and affect the generations’ norms related to organizational commitment. McGuire, By and Hutch-
ings (2007) indicated that the X and Y generations exhibit less organizational commitment than boomers.
Blau (1985) reported that both age and tenure are positively related to organizational commitment.
Joo and Park (2009) found commitment was related to behavioral investments in the organization
and likelihood to stay (loyalty) with the organization. Carver and Candela (2008) expanded the commit-
ment construct by relating organizational commitment to an employee’s dedication to the values of an
97
Engineering Management Handbook

organization. Commitment has been positively correlated to higher organizational learning and develop-
mental feedback from supervisors (Joo and Park, 2009).
Allen and Meyer (1990) identified three constructs that describe commitment: affective, continuance,
and normative. Affective commitment refers to an employee’s emotional attachment to, involvement in,
and identification with, an organization. Watsi (2005) stated that stronger affective commitment results
from positive work-related experiences. Continuance commitment is related to the costs an employee asso-
ciates with leaving an employer. Employees with strong continuance commitment remain because they feel
they have to do so (Meyer and Herscovitch, 2001). Tenure and benefits (accrued vacation, etc.) represent a
“sunk cost” of employment (Sinclair, Leo and Wright, 2005) that induces loyalty. Normative commitment
describes an employee’s feeling of obligation to remain with an organization as a general sense of obligation
to fellow employees. Normative commitment develops from experiences that emphasizing loyalty to an
employer (Wiener, 1982), what Kondratuk et al. (2004) refered to as “corporate loyalty.”
Work by Meyer et al. (2010) demonstrated that how an employee behaves on the job is influenced
jointly by commitment to the organization and to the occupation. Table 8.1 summarizes the relationship
of the three commitment categories and generally recognized factors of workplace impacts; e.g., higher
levels of commitment result in lower turnover rates.

Table 8.1. Influence of Commitment on Workplace Impact

Commitment Categories Affective Continuance Normative (Kondratuk et al., 2004)

Job performance Positive Negative None (Watsi, 2005)
Job outcomes Positive Positive Positive (Meyer and Allen, 1991)
Turnover Negative Negative Negative (Meyer et al., 2002)
Organizational Citizenship Positive Negative Moderately (Meyer et al., 2002)

8.5.1 Commitment and the Generations

Boomers are characterized as having a sense of ownership in the organization. This sense of ownership cor-
relates positively with all three categories of commitment, affective, normative and continuance as reflected
in the underlying construct definitions related to want to, ought to and have to, respectively. The organi-
zation is seen as a means to an end; the end being a need to demonstrate success in their personal pursuits.
As such, Baby Boomers will have a tendency to migrate to opportunities for accomplishment and therefore
will reflect modest measures of affective commitment. Having seen parents recover from the impacts of
economic depression, Baby Boomers will demonstrate strong normative and continuance commitment as
they seek to maintain employment. In serving the organization, Baby Boomers demonstrate conviction
for a shared purpose that supports high commitment across all three categories. This is also manifested in
a willingness to challenge any deviations from the integrity of the pursuit of that purpose. Support for the
shared or common purpose would be reflected in high measures of commitment. When the shared pur-
pose no longer supports values, boomers are hypothesized to have a willingness to change themselves and/
or the organization for the good of the organization an indication of high measures of loyalty.
Generation X, while reflecting a self-centered approach to work and commitment is has a stronger
need to invest in relationships than careers and therefore measures of commitment will tend to demon-
strate modest levels. Similarly, having been on their own (latchkey generation), Gen X’ers are expected to
form strong bonds with colleagues on a personal basis rather than an organizational basis. As Gen X’ers
consider their employer as a tool to be used for skill development they would have modest measures of
commitment. The Generation X is focused on personal growth and personal relationship stability and
will work to maintain that even if proactivity in seeking a new employer is part of their path toward ful-
fillment.
The youngest generation, the Generation Y, represents a group newest to employment. Gen Y’ers are
used to teams, teamwork, and social networking. Raised in daycare with their peers they quickly assume
98
 Managing the Multi-Generational Knowledge Based Workforce

responsibilities associated with their work group(s) resulting in high measures of affective commitment.
They expect to be managed well and challenged in their work assignments as a rite-of-passage. Gen Y’ers
seemingly demonstrate high performance when properly challenged. Lacking work challenges, the Gen
Y’ers are expected to insist on work conditions that meet their requirements and expectations and not
vice versa.

8.6 Recommendations for the Management Discipline

8.6.1 Understanding
Understanding how generations perceive their careers and life challenges can lead to high performance in
the workplace. Dixon, Mercado and Knowles (2013) offered recommendations for the engineering man-
ager and the engineering management discipline:
1. Take time to learn about candidates for hire or promotion. Asking questions pertaining to workplace
behaviors and commitment constructs could provide clues as to know whether or not the candidate
for hire or promotion is ideal. Determining things that may have had a major impact on someone’s
life could also make known a person’s perceptions and expectations. Picking up (non) appropriate
attributes early could facilitate proper job placement, increase retention, and reduce turnover.
2. Develop younger employees. Give them responsibility and encourage initiative early in their careers.
Many Gen X’ers and Y’ers prefer stretch assignments requiring development of new knowledge and
skills. The generational norm is to leave if not challenged. Providing regular guidance and feedback
along the way increases retention.
3. Recognize commitment levels and capitalize on them. Do not let them go unrecognized.
4. Support employees in their need for knowledge and skills acquisition. Generation X in particular sees
an employer as a means for skill building and tends to use a job as an extended education. If allowed
to continually learn within the organization, they tend to be loyal.
5. Believe in change and embrace transformation. Be able to recognize that Baby Boomers can resist
change and deal with them accordingly.
6. Retain corporate knowledge. Older engineers have obtained substantial business knowledge and skills
that will be lost with attrition or retirement (Mraz, 2009). To prevent losing this body of knowledge,
engineering managers should codify methods and processes. A referenceable body of knowledge can
be used by younger engineers as needed.

8.6.2 Bias
According to Karp (2012) managing generational bias is an issue all managers face. Generational biases
certainly exist and are manageable only when the will and the means are available. Hiding bias is not a
viable solution. Leveraging generational-difference bias as a source of and for energy, drive, and determi-
nation that is useful in harnessing the differences that reflect personal bias. The struggle is harnessing the
differences for the good of the organization and the competitive posture of the business’ strategic focus.
1. The first consideration would be the engineering manager’s ability to manage personal bias with
respect to generational diversity. Engineering managers can struggle with their bias throughout their
career and life-stages. According to Karp (2012) as the manager matures focus changes from personal
achievement, to career development, and culminates with contributing to society on some level. This
latter career stage is the time when senior engineer managers are best able to lead the integration of
multigenerational collections into a cohesive teams. These mature engineering managers can spur
inter-generational cohesiveness when they bring the focus on the performance of the team using their
wisdom, courage, justice and temperance that has moved past their own advancement (Peterson and
Seligman, 2004).
2. Xu and Thomas (2011) conjectured leadership overlaps the construct, engagement. Engagement is de-
fined as the degree to which employees make full use of their cognitive, emotional, and physical resourc-
es to perform role-related work (May, Gibson, and Harter, 2004). Engaged employees is the goal of ev-
ery engineering manager who is responsible for performance measures tend to be highly subjective and
99
Engineering Management Handbook

prone to diverse interpretations; e.g., engineers and engineering. Engineering managers work to create
an environment where engineers feel psychologically safe in the face of generational diversity. This is an
acute need for inexperienced engineers. Two objectives compound the influences of a multigenerational
workforce. (1) Developing new engineers into productive employees and (2) maintaining the morale
and performance of experienced engineers, typically Baby Boomers and Gen X employees. Satisfying
these objectives requires the engineering manager to address the norms and values of the generations in
the context of the workplace environment. This environment requires younger engineers to recognize
that work-place wisdom is held by the older engineers and must be mined or it will have to be recreated.
Networking across the generations will develop respect within the younger engineers for the experienced
engineers and will enable their recognition for engaging as team players.
An understanding of engagement allows the engineering manager from any generation to place
emphasis on the classic team-development methods such as development of the individual and
rewarding work group successes. Enhancing engagement also will require goals and metrics associ-
ated with monitoring task-oriented behaviors. Engineering mangers must also provide appropriate
resources and facilities, challenging tasks, effective task management, displaying integrity and open,
honest communications along with mentoring all engineers (Xu and Thomas, 2011). Engineering
managers must reflect work habits and related attitudes that they expect from their engineers. This is
sets the example that each work activity is part of the organization’s strategic mission, a classic exam-
ple of leading by example.
3. All engineering managers recognize that beyond satisfying regulatory requirements, there is limited
return for mandated training. “Engaged” training–training that enhances satisfies the employees’
need for education and skill development consistent with organizational objectives–will recognize the
differences in generations (Hotho and Dowling, 2010). Engineers interpret training based on their
personal orientations, norms, values and situational context including the influences represented in
the generations. Training is interpreted based on individual and group bias. A classic training failure
is when a one-size-fits-all training intervention is required of employees without recognition of the
individual trainees’ motivation, ability, personality, and work context (Hotho and Dowling, 2010).
Training for development should be developed through discussions with the engineering manager, the
candidate and the training designers (Haskins and Shaffer, 2010) and should focus on the individuals
attributes, capabilities, needs, potential, and return for the organization. The design for developmen-
tal training should focus on desired strategic behaviors, self-awareness, change and change barriers,
within organizational and professional contexts.
4. Any cross-generational integration initiatives should be augmented with dispersion tactics to lever-
age any training initiative across the organization. The diffusion of learning is best accomplished by
applied team activities or learning projects (Atwood, Mora and Kaplan, 2010). This requires that
integration initiatives be permeated with communicating the knowledge, skills, and abilities (KSA)
gained and facilitating an environment where the generations can adapt the new KSAs into both their
social and work groups. This is often called organizational learning where training includes a process
of KSA transference or supporting learning in others. As part of the organization learns and shares
the need for additional training interventions is reduced. As the organizational learning spreads, indi-
viduals in each generation will begin developing their own supportive behaviors.

8.7 References
Adams, S. J., “Generation X: How understanding this population leads to better safety programs,” Profes-
sional Safety, 45, 2000, pp. 26-29.
Allen, N. J., and Meyer, J. P., “The measurement and antecedents of affective, continuance and normative
commitment,” Journal of Occupational Psychology, 63, 1990, pp. 1-18.
Allen, N. J., and John P. M., “The Measurement and Antecedents of Affective, Continuance and Normative
Commitment to the Organization,” Journal Of Occupational Psychology, vol. 63, no. 1, 1990, pp. 1-18.
Anderson, Jamie, “Customized executive learning: a business model for the twenty-first century”, Journal
of Management Development, vol. 29, no. 6, 2010, pp. 545-555.
100
 Managing the Multi-Generational Knowledge Based Workforce

Ansoorian, Andrew, Good, Pamela, and Samuelson, Dave,“Managing Generational Differences,” Leader-
ship, vol. 32, no. 5, 2003, p. 34.
Atwood, Meredith A., Mora, Jordan W. and Kaplan, Abram W., “Learning to Lead: Evaluating Leader-
ship and Organizational Learning,” Leadership & Organization Development Journal, vol. 31, no. 7,
2010, pp. 576-595.
Beutell, Nicholas J., and Wittig-Berman, Ursula, “Work-Family Conflict and Work-Family Synergy for
Generation X, Baby Boomers, and Matures: Generational Differences, Predictors, and Satisfaction
Outcomes,” Journal of Managerial Psychology, vol. 23, no.5, 2008, pp. 507-523.
Blau, Gary J., The measurement and prediction of career commitment, Journal of Occupational Psychology,
vol. 58, 1985, pp. 277-288.
Blythe, Jennifer, Baumann, Andrea, Zeytinoglu, Isik U., Denton, Margaret, Akhtar-Danesh, Noori,
Davies, Sharon, and Kolotylo, Camille. “Nursing Generations in the Contemporary Workplace,”
Public Personnel Management, vol. 37, no. 2, 2008, pp. 137-159.
Bova, Breda and Kroth, Michael. “Workplace Learning and Generation X,” Journal of Workplace Learn-
ing, vol. 13, no. 2, 2001, pp. 57-65.
Brown, Patrick, “Reaching out to Generation Y,” Nuclear Engineering International, vol. 56, no. 680,
2011, p. 42.
Carver, Lara and Candela, Lori. Attaining organizational commitment across different generations of
nurses, Journal of Nursing Management, vol. 16, 2008,pp. 984-991.
Chaleff, Ira, The Courageous Follower, Third Edition, Berrett-Koehler, 2009.
Chen, Po-Ju and Choi, Youngsoo. “Generational Differences in Work Values: A Study of Hospitality
Management,” International Journal of Contemporary Hospitality, vol. 20, no. 6, 2008, pp. 595-615.
Coley, D. C., “Leading Generation Y,” Education Digest, vol. 74, no. 9, 2009, pp. 20-23.
Dalakoura, Afroditi, “Differentiating Leader and Leadership Development,” Journal of Management De-
velopment, vol. 29, no. 5, 2010, pp. 432-441.
Dixon, Eugene N. An Exploration of the Relationship of Organizational Level and Measures of Follower Be-
haviors, A Dissertation. Huntsville AL: The University of Alabama in Huntsville, 2003.
Dixon, Gene and Westbrook, Jerry. “Followers Revealed,” Engineering Management Journal, vol. 15, no. 1,
2003, pp. 19-25.
Dixon, Gene. Emotions and Follower Behaviors in a Time of Crisis, Society of Automotive Engineers,
Proceedings of the 2009 World Congress, Detroit MI, 2009a.
Dixon, Gene. “Followers: The Rest of the Leadership Process,” SAE International Journal of Materials and
Manufacturing, vol. 1, no. 1, April, 2009b, pp. 255-263.
Dixon, Gene, and Mercado, Ashley. “Followers and Commitment in the Workplace,” Society of Auto-
motive Engineering Conference Proceedings, 2011.
Dixon, Gene, and Westbrook, Jerry D., “Followers Revealed,” Engineering Management Journal, vol. 15,
no. 1, 2003, pp. 19-25.
Dixon, Gene and Knowles, Brady. “A Study of the Correlation of Follower Behaviors and Levels of Com-
mitment Across Generations,” 2013 Proceedings of the ASEM International Annual Conference,
October 2013.
Downing, K., “Next Generation: What Leaders Need to Know About the Millennials,” Leadership in
Action, vol. 26, no. 3, 2006, pp. 3-6.
Ferguson, Karen L., and Reio Jr., Thomas G. “Human Resource Management Systems and Firm Perform-
ance,” Journal of Management Development, vol. 29, no. 5, 2010, pp. 471-494.
Gibson, Jane Whitney, Jones, J. Preston, Celia, Jennifer, Clark, Cory, Epstein, Alexandra, and Haselber-
ger, Jennifer,“Ageism and the Baby Boomers: Issues, Challenges and the TEAM Approach,” Contem-
porary Issues In Education Research, January vol. 3, no. 1, 2010, pp. 53-59.
Hira, N. ,“You Raised Them, Now Manage Them,” Fortune, vol. 155, no. 9, 2007, pp. 38-48.
Hoerr, T. R., “Supervising Generation X,” Educational Leadership, vol. 65, no, 2 , 2007, pp. 85-86.
Hotho, Sabine and Dowling, Martin, “Revisiting Leadership Development: the Participant Perspective,”
Leadership & Organization Development Journal, vol. 31, no 7, 2010, pp. 609-629.

101
Engineering Management Handbook

Johnson, James P., Korsgaard, M. Audrey, and Sapienza, Harry J. “Perceived Fairness, Decision Control,
and Commitment in International Joint Venture Management Teams,” Strategic Management Journal,
vol. 23, no. 12, 2002, pp. 1141-1160.
Joo, Baek-Kyoo and Park, Sunyoung, “Career Satisfaction, Organizational Commitment, and Turnover
Intention,” Leadership and Development Journal, vol. 31, no. 6, 2009, pp. 482-495.
Jorgensen, Bradley, “Baby Boomers, Generation X, and Generation Y?: Policy Implications for Defense
Forces in the Modern Era,” Foresight, vol. 5, no. 4, pp. 41-49, 2003.
Jurkiewicz, C. E., and Brown, R. G. “GenXers vs. Boomers vs Matures: Generational Comparisons of
Public Employee Motivation,” Review of Public Personnel Administration, vol. 18, 1998, pp. 18-37.
Karp, H., Sirias, D., Arnold, K. “Teams: Why Generation X Marks the Spot. The Journal for Quality and
Participation, vol. 22, 1999, pp. 30-33.
Karp, Tom, “Develop Oneself as a Leader,” Journal of Management Development, vol. 32, no. 1, 2012.
Keepnews, David M., Brewer, Carol S., Kovner, Christine T., and Shin, Juh Hyun, “Generational Differ-
ences Among Newly Licensed Registered Nurses,” Nursing Outlook, vol. 58, 2010, pp. 155-163.
Kelley, R. E., “Power of Followership: How to Create Leaders People Want to Follow and Followers Who Lead
Themselves, New York: Double Currency, 1991.
Kondratuk, Tammy B., Hausdorf, Peter A., Korabik, Karen, and Rosin, Hazel M., “Linking career Mobil-
ity with Corporate Loyalty: How Does Job Change Relate to Organizational Commitment?” Journal
of Vocational Behavior¸ vol. 65, 2004, pp. 332-349.
Kuperschmidt, B. R., “Multigeneration Employees: Strategies for Effective Management,” The Health
Care Manager, vol. 19, 2000, pp. 65-76.
Loomis, J., “Generation X,” Rough Notes, vol. 143, no. 9, 2000, pp. 52-54.
Martin, Harry J., “Improving Training Impact Through Effective Follow-Up: Techniques and Their Ap-
plication,” Journal of Management Development, vol. 29, no. 6, 2010, pp. 520-534.
May, D. R., Gilson, R. L. and Harter, L. M., “The Psychological Conditions of Meaningfulness, Safety
and Availability and the Engagement of the Human Spirit at Work,” Journal of Occupational and
Organizational Psychology, vol. 77, no. 1, 2004, pp. 11-37.
McGuire, David, By, Rune Todnem, and Hutchings, Kate, “Towards a Model of Human Solutions for
Achieving Intergenerational Interaction in Organisations,” Journal of European Industrial Training,
vol. 31, no. 8, 2007, pp. 592-608.
Merritt, Stephen R., and Neville, Shelley, “Generation Y,” The Serials Librarian, vol. 42, no. 1-2, 2003, pp.
41-50.
Meyer, J. P. and Allen, N. J., “A Three Component Conceptualization of Organization Commitment,”
Human Resource Management Review, vol. 1, no. 1, 1991, pp. 61-89.
Meyer, J. P., and Herscovitch, L., “Commitment in the Workplace: Toward a General Model.” Human
Resource Management Review, vol. 11, 2001, pp. 299-326.
Meyer, J. P., Stanley, D. J., Herscovitch, L., and Topolnytsky, L., “Affective, Continuance, and Normative
Commitment to the Organization: A Meta-analysis of Antecedents, Correlates, and Consequences,”
Journal of Vocational Behavior, vol. 61, 2002, pp. 20-52.
Silver, Mitchell, Changing Demographics of Eastern NC in 2050, November 3, 2011, ECU-TV.
Mraz, Stephen, J., “Changes in the Engineering Profession Over 80 Years,” Machine Design.com, 2009.
Peterson, Christopher and Seligman, Martin, Character, Strengths and Virtues. A Handbook and Classifica-
tion, Oxford University Press, 2004.
Ray, Linda Keith. Follow the Leader: An Investigation of the Relationship Between Hierarchical Levels and
Measures of Follower Behaviors of Selected NC Community College Employees, A Dissertation, Greenville,
NC, East Carolina University, 2006.
Rich, Theresa A., Becoming the boss whisperer: An Examination of the Relationship Between Employee Follow-
er Behaviors and Supervisor Satisfaction With Employee Performance, A Dissertation. Minneapolis MN:
Capella University, 2008.

102
 Managing the Multi-Generational Knowledge Based Workforce

Ricketson, Rushton S., An exploration of the relationship of leadership styles and dimensions of courageous
followership, A Dissertation, Virginia Beach, VA, Regents University, 2008.
Riggio, Ronald E., Chaleff, Ira, and Lipman-Blumen, Jean, The Art of Followership, Jossey-Bass, 2008.
Shaw, Sue and Fairhurst, David, “Engaging a New Generation of Graduates,” Education + Training, vol.
50, no. 5, 2008, pp. 366-378.
Sinclair, Robert R., Leo, Michael C., and Wright, Chris, “Benefit System Effects on Employees’ Benefit
Knowledge, Use, and Organizational Commitment,” Journal of Business and Psychology, vol. 20, no. 1,
2005, pp. 3-29.
Smola, Karen Wey and Sutton, Charlotte D., “Generational Differences: Revisiting Generational Work
Values for the New Millennium,” Journal of Organizational Behavior, vol. 23, no, 4, Special Issue:
Brave New Workplace: Organizational Behavior in the Electronic Age, 2002, pp. 363-382.
Tomkiewicz, Jospeh and Bass, Kenneth, “Attitudes of Business Students Toward Management Generation
Cohorts,” North American Journal of Psychology, vol. 10, no. 2, 2008, pp. 435-444.
Watsi, S. Arzu, “Commitment Profiles: Combinations of Organizational Commitment Forms and Job
Outcomes,” Journal of Vocational Behavior, vol. 67, 2005, pp. 290-308.
Wiener, Y. “Commitment in organizations: A normative view.” Academy of Management Review, vol. 7,
1982, pp. 418-428.
Xu, Jessica and Thomas, Helena Cooper, “How Can Leaders Achieve High Employee Engagement?,”
Leadership & Organization Development Journal, vol. 32, no. 4, 2011, pp. 399-416.
Zemke, Ron, Raines, Claire, and Filipczak, Bob, Generations at Work, AMACOM Books, 1999.

103
104
 Operations Research

9
Operations Research

Scott E. Grasman
Rochester Institute of Technology

Abhijit Gosavi
Missouri University of Science and Technology

Katie McConky
Rochester Institute of Technology

105
Engineering Management Handbook

9.1 Introduction to Operations Research Modeling

Operations Research (OR) applies a rigorous methodology to managerial problems, typically with quanti-
tative factors. With application to manufacturing, service, and military, OR is widely applied by engineer-
ing managers and consultants, and is seen as a valuable approach to aiding managerial decision-making.
The following sections provide a brief introduction to the importance and history of OR, as well as an
overview of the standard OR methodology.

9.1.1 Importance of Operations Research for Engineering Managers

Operations Research focuses on the application of resources to the production of goods and services. Op-
erations researchers optimize the use of capital, materials, technology, human skills, knowledge and infor-
mation. Solutions provided by operations researchers have helped engineering managers design effective
new systems, identify opportunities for improving systems, and make tradeoffs to coordinate policies from
different functional areas.
In order to successfully apply OR, engineering managers must have an understanding of the basic lan-
guage and concepts of operations, the mathematical skills, including modeling, probability and statistics, as
well as effective intuitive and critical thinking skills to synthesize all areas of operations. Since OR typically
aids in the decision making process, in contrast to smart systems, managers must combine the analysis and
recommendations, often generated through decision support systems, with other qualitative factors. In addi-
tion, engineering managers must use quantitative relations founded on theories from simple systems to build
theories and intuition for more complex systems.
Operations Research is generally used synonymously with Management Science, while less quantitative
researchers often use the term Operations Management as well. Loosely, the spectrum may be defined from
theoretical to applied, with OR on the theoretic end, Operations Management on the applied end, and
Management Science in the middle. Operations Management is described in Chapter 15.

9.1.2 History of Operations Research

Operations Research is a rich discipline with historical milestones involving world events, people, and
technology. Many date the discipline back to the industrial revolution or to the turn of the 20th centu-
ry, while other operations research historians look to military applications during the World War I and
World War II. Shortly after World War II, operations research was propelled by George B. Dantzig, who
derived the Simplex Method for solution of linear programs. Certainly, modern operations research has
been greatly enhanced by the use of modern computational technology that has allowed for the solution
to more and more complex problems. Annotated timeline of operations research is available (Gass and
Assad, 2004).
In the United States, the flagship professional society is the Institute for Operations Research and the
Management Sciences (INFORMS), though many other professional societies have operations research
divisions, councils or interest groups. Internationally, there are more than 50 societies organized under the
umbrella of the International Federation of Operational Research Societies (IFORS). These professional
organizations are purveyors of professional journals, international conferences, and professional stewardship.

9.1.3 Operations Research Methodology

Operations Research provides a modeling process from which a collection of (mathematical) models
that are appropriate for many real-world problems have evolved. These mathematical models are either
descriptive in that they predict or explain an outcome in order to determine if a given system would meet
specifications, or prescriptive and control or optimize an outcome in order to provide optimal design or
control of a system. Importantly, prescribing first requires the ability to describe!
The basic operations research process consists of eight phases, as shown in Figure 9.1, including:
1. Problem Definition which consists of stating the decision that needs to be made, including system
objectives and constraints.

106
 Operations Research

2. Data Collection specifies the data collection, processing, analysis, and management requirements.
3. Model Formulation translates the problem definition into mathematical form by stating decision
variables, objective and constraint functions.
4. Model Verification checks to make sure the model is working as intended. This is especially import-
ant with the implementation of technology based solutions.
5. Solution is generating an answer to your defined problem using the verified model. The solution
method is dependent on the model formulation.
6. Validation ensures that the model developed accurately represents the real system.
7. Presentation of Results combines the quantitative analysis and results with other factors such as com-
pany objectives.
8. Implementation applies the solution and recommendation to achieve the desired outcomes.

Operations Research has lead to a variety of deterministic and stochastic models that are appropriate
for use by engineering managers. Applications include traditional engineering disciplines such as man-
ufacturing and technology management, but have also lead to process improvement in sectors such as
health care, financial services, and entertainment. Specific models and applications are discussed in the
following sections. It is noted here, that these models often involve the designation, “program.” Although
computer programming has been instrumental in the implementation of solution algorithms for these
models, the term originate from the concept of “order of operations.” Mathematical programs were re-
searched and applied long before the invention of computers.

Figure 9.1. Operations Research Methodology

Define
Problem

Collect
Data

Formulate
Model

No
Verify?

Yes

Solve
Model

Present No
Valid?
Results

Yes

Implement
Solution

107
Engineering Management Handbook

9.2 Deterministic Models

This section covers topics in OR that deal primarily with known or deterministic parameters. Topics
include linear and integer programming, which provide a way to model and explore a system to find an
optimal solution to an objective. Linear programs lend themselves nicely to a process called sensitivity
analysis, which allows the researcher to understand the impacts of changes to model parameters. A dis-
cussion of non-linear programming follows and provides the ability to model more complex relationships
than strictly linear programs. Finally, the section is concluded with a discussion of dynamic program-
ming, a modelling framework often used for systems with recursive-based solutions.

9.2.1 Linear Programming

Linear programming is the optimization of a linear function subject to linear constraints, expressed as
equalities or inequalities. Generally, these problems either aim to maximize an objective, e.g., profit, sub-
ject to limited resources, or aim to minimize an objective, e.g., cost, subject to minimum requirements.
Other models have fixed-requirement constraints, e.g., matching supply with demand or combinations
of the above constraints. Linear programs (LP) are extremely useful to engineering managers because they
are efficient to solve, with solution procedures that guarantee optimal solutions (if one exists). In addition,
linear programs allow for the generation of useful sensitivity analysis information.
By definition, linear programs have the characteristics of proportionality and additivity. Further basic
linear programming has the additional characteristics of divisibility and certainty. All the characteristics
can be relaxed, leading to other mathematical models.
• Proportionality—If an activity level is multiplied by a constant, then the contribution of the activity
to the objective function and constraints is multiplied by the same constant.
• Additivity—The total contribution to the objective function and constraints is equal to the sum of the
contributions of the individual activities.
• Divisibility—Both integer and non-integer levels of activities are allowed.
• Certainty—No random outcomes.

Although many practical problems are essentially linear, linear programming can also be used to ad-
dress more complex problems. These techniques will be described in later sections.

9.2.2 Basic Problem Formulation

As described, linear programs consists of either a maximization problem or minimization problem subject
to a set of constraints. Two basic forms are shown in Figure 9.2, though fixed-requirement problems and
mixed-constraint problems are also common.

Figure 9.2. Basic Linear Programming Formulations

n n
maximize Z = ∑c jxj minimize Z = ∑c
j =1
j xj
j =1

subject to : subject to :
n n

∑ aij x j ≤ bi for i = 1,2,..., m

j =1
∑a
j =1
ij x j ≥ bi for i = 1,2,..., m

x j ≥ 0 for j = 1,2,..., n x j ≥ 0 for j = 1,2,..., n

108
 Operations Research

The following notation is used to formulate the models in Figure 9.2.

Z = objective value function

n = number of decision variables
m = number of constraints
xj = decision variable j
aij = resource/requirement for activity j and constraint i
bi = resource/requirement i
cj = objective value coefficient for activity j

The linear matrix nature of the formulation is evident from Figure 9.2. These characteristics are lever-
aged to obtain optimal solutions.

Solution Techniques
The main technique for solving linear programs is the Simplex Method (Dantzig), or a variation on the
Simplex Method. Other methods, e.g., Interior Point Methods (Karmarkar’s Algorithm), have also been
successfully applied to linear programs or special cases of linear programs. While the details of these
methods will not be provided here (see Hillier and Lieberman, 2010), small linear programs can be solved
graphically, along with linear algebra, to provide insight into the solution techniques.
Consider the following linear program.

maximize Z = 2 x1 + 3 x 2

subject to
2 x1 + x 2 ≤ 4
x1 + 2 x 2 ≤ 5
x1 , x 2 ≥ 0

The problem may be solved by graphing all constraints in order to establish the feasible region, i.e., the
points that satisfy all constraints, and by plotting iso-objective lines that are used to find an optimal solution.
The shaded region in Figure 9.3 is the feasible region, while the dotted lines represent the iso-objective lines.

Figure 9.3. Feasible Region and Iso-Objective Lines

x2

maximize Z = 2x1 + 3x2

x1
x1 , x2 ≥ 0
x1 + 2x2 ≤ 5000
2x1 + x2 ≤ 4000

109
Engineering Management Handbook

As the iso-lines in Figure 9.4 are moved “up and to the right”, the objective value increases, thus the
optimal solution is obtained by moving an iso-line to the extreme of the feasible region.

Figure 9.4. Corner Point Optimal Solution

x2

optimal solution (maximum

Intersection of:
2x1 + x2 = 4000
x1 + 2x2 = 5000

x1 = 1000, x2 = 2000
Z = $8000

x1
x1 , x2 ≥ 0
x1 + 2x2 ≤ 5000
2x1 + x2 ≤ 4000

Once the corner point is identified, as in Figure 9.4, linear algebra can be used to solve for the optimal
solution.
The main observation is that an optimal solution will be at one of the corners or extreme points of the
feasible region. More specifically, an optimal solution will exist at, at least one corner point solution; if
the optimal iso-line is parallel to a constraint, then there are multiple optimal solutions. In other cases, it
is possible that no feasible solutions exist, i.e., the combination of constraints is too restrictive, or that the
objective function is unbounded, i.e., the combination of constraints is too relaxed. In these situations
the model should be reformulated and validated.
The main observation, that optimal solutions occur at extreme points of the feasible region, is the
basis for most LP solution algorithms, including the Simplex Method. For more information on solution
theory, the reader is referred to Hillier and Lieberman (2010). Of course, linear programs may be solved
using algorithms implemented in computer software applications. These range from simple spreadsheet
applications to advance commercial software packages.

9.2.3 Sensitivity Analysis

Sensitivity Analysis asks questions related to the effect of changing model parameters. The most common
analysis targets changes to objective value coefficients, e.g., profit/revenue or costs, and constraints, e.g.,
resources or requirements. For objective coefficients, two important questions relate to range of optimality
and reduced costs. For constraints, two important questions relate to shadow prices and allowable ranges. It is
necessary to note that, for changes to objective coefficients, though the optimal solution may not change,
the value of the objective function certainly will change. For changes to binding constraints, both the solu-
tion and the objective value are likely to change. See Hillier and Hillier (2008) for further discussion.

Range of Optimality—How much coefficients can change without changing optimal solution.

Graphically, the range of optimality is found by changing the slope of the objective function line
within the limits of the slopes of the binding constraint lines. At this point, the iso-lines will last intersect
at two corners, causing multiple solutions; beyond this, the original optimal solution will no longer be
optimal.
110
 Operations Research

For a two variable example with objective function c1x1 + c2x2, and binding constraints, a11x1 + a21x2 =
b1 and a12x1 + a22x2 = b2, the range of optimality is given by:

a11 c1 a12
– ≤ – ≤ – .
a21 c2 a22

Changes to a single objective value coefficient are fairly straightforward to handle, while multiple
changes require further analysis. When changes are made to multiple objective coefficients, the percent-
age change relative to the range of optimality of each changing coefficient is calculated. If the sum of the
percentage changes does not exceed 100%, then the original optimal solution will remain optimal. If the
sum exceeds 100%, then the optimal solution may or may not change. The key is the relative change of
the coefficients and their effect on the slope of the objective function. For example, multiplying all coeffi-
cients by a constant will not change the slope of the objective function, regardless of the magnitude.
In most cases, computer software applications are used to solve and provide this information, though
the same logic applies to higher dimension problems.

Reduced Costs—How much a coefficient must change in order to enter the optimal solution.

If an activity is relatively too costly, or does not generate enough revenue, then this activity will not
be included in the optimal solution. The reduced cost indicates the change (reduction) in cost required
to make the activity desirable. Conversely, if an activity is not relatively profitable, then the reduced cost
indicates the required change (increase) in profit/revenue. The engineering manager can use this informa-
tion for pricing decisions, as well as identification of cost reduction strategies.
Reduced costs may be found in the same manner as the range of optimality. By leaving the other ob-
jective coefficients unchanged, the range of optimality of the coefficient of interest indicates the reduced
cost.

Shadow Prices—How much the optimal objective value changes with changes in a constraint (within
limits).

Shadow prices are perhaps the most useful sensitivity information because they indicate the linear
change in objective value due to increases or decreases in available resources or requirements. The engi-
neering manager can use this information to determine if additional resources should be obtained or if
requirements should be adjusted.
Shadow prices are determined by obtaining the slope/gradient of binding constraints. Again, this may
be done mathematically, but is normally done using commercial software applications.

Allowable Ranges—Valid Range of Shadow Prices.

Allowable ranges indicate how much the constraint, resource, or requirement, can change without
invalidating the shadow prices. Beyond the allowable range, the objective value may continue to improve;
however, the rate of change will be different. The allowable ranges are determined by obtaining the point
at which a binding constraint no longer becomes binding, or a nonbinding constraint becomes binding.
The 100% Rule also applies in that shadow prices will remain valid as long as the sum of the percentage
changes does not exceed 100%. Additional analysis is required if the change exceeds 100%.

9.2.4 Duality Theory

Duality Theory allows for both the solution of linear programs and sensitivity analysis. The original, or
primal, linear program may be converted to the dual linear program through a standard conversion pro-
cess involving linear matrix transformation.

111
Engineering Management Handbook

For the standard form linear programs shown in Figure 9.2, the dual linear programs are shown in
Figure 9.5.

Figure 9.5. Dual Linear Programs for Basic Linear Programs

Once the dual has been formulated, complementary slackness may be used to obtain the solution and
sensitivity analysis for both models. Generically, the solution to the dual problem provides the shadow
prices for the primal constraints and can be used in decision-making as previously described. The dual
solution can also be used to determine the range of optimality, but this process is a bit less transparent.
For more information on this duality, see Hillier and Lieberman (2010).

9.2.5 Applications
For application purposes, linear programs are often classified into one of four categories based on the
objective function and the set of constraints. These classifications include resource-allocation, cost-tradeoff,
fixed-requirement, and mixed problems (see Hillier and Hillier, 2008).

Resource-Allocation—Linear programming problems involving the allocation of resources to activities so

as to satisfy objective, e.g., maximizing profit, subject to limit resources. Thus, constraints are resource
constraints, in that the amount allocated has to be less than or equal to the amount available. Typical
examples include product-mix problems, activity-mix problems, and capital budgeting problems.

Cost-Tradeoff—Linear programming problems where the various activities are chosen to satisfy require-
ments, typically at minimum cost. Constraints are requirement constraints, in that the amount allocated
must be greater than or equal to the requirement. Typical examples include activity-mix problems, per-
sonnel scheduling problems, and others.

Fixed-Requirement—Linear programming problems involving allocation of activities such that the amount
provided is equal to the amount required. Functional constraints are fixed requirement constraints. Many
common applications relate to network optimization models, such as transportation/assignment prob-
lems, shortest/longest path problems, maximum flow problems, and spanning trees.

The engineering manager can address these applications through the implementation of standard
procedures presented earlier, of course, with the assistance of software applications. A common example is
the use of fixed-requirement models for critical paths in project networks.

9.2.6 Integer Programming

Integer programming models restrict the decision variable to integers, which violates the divisibility
assumption of linear programs. A variety of integer models exist including pure integer programs, mixed
integer programs, and binary integer programs. The formulation of basic integer programs is similar to
that of linear programs, but the solution creates many more challenges. Additionally, the integer nature,
duality theory does not hold and sensitivity analysis is much more challenging.
112
 Operations Research

9.2.7 Solution Techniques

Solution techniques are more complex than linear programming and include cutting plane methods
and branch and bound algorithms (see Hillier and Lieberman, 2010). Unlike linear programming,
not all integer programs can be solved in reasonable computational time, thus many heuristics
have been devised to achieve approximate solutions. One such technique is linear programming
relaxation, which ignores the integer constraints. The benefits of relaxation include more efficient
solution procedures, as well as simplified sensitivity analysis. Of course, the applicability of
relaxation depends on solution quality. Commercial software packages are available for practical
application.

9.2.8 Binary and Auxiliary Binary Variable

Use of binary and auxiliary binary variables is a powerful technique that aids in the formulation and ap-
plication of mathematical models. Binary decisions, e.g., yes or no decisions, are quite common in prac-
tice, and auxiliary binary variables can be used to efficiently incorporate problem characteristics such as
fixed (or setup) costs, mutually exclusivity or contingency, and either-or constraints. The ability to utilize
binary variables leads to models that are easy to interpret and analyze. For example, the use of auxiliary
binary variables may allow a non-linear model to be formulated as a linear integer program; thus aiding in
the solution and sensitivity analysis.

9.2.9 Applications
Though integer programming relates to any mathematical model with integer variables, there is much
overlap with network optimization problems (transportation/assignment problems, shortest/longest path
problems, maximum flow problems, and spanning trees). Facility location, inventory modeling, schedul-
ing, and investment are additional popular application areas.

9.3 Non-Linear Programming

Non-linear programming is similar to linear programming (and integer programming) except for the
inclusion of non-proportional relationships. Depending on the nature of the problem, formulation
of non-linear programs is generally more difficult, and solution is much more difficult, if possible.
Non-proportional relationships may exist in the objective value function, in the constraints, or in both.
For example, the objective function may include marginally increasing/decreasing revenues or costs, or
discontinuities.

9.3.1 Solution Techniques

Due to the complexity of non-linear models, numerous approaches have been used to attempt to reduce
the computational complexity and quality of solutions. Generally, the solution challenges relate to the
non-convexity of the feasible region or local optima. Solution approaches include gradient methods,
branch and bound, dynamic programming and meta-heuristic approaches, including genetic and other
evolutionary algorithms, tabu search, and simulated annealing (Hillier and Lieberman, 2010). Software
packages implement a variety of algorithms.

9.3.2 Separable Programming

Separable programming is a technique that may be used to convert a non-linear program to a linear pro-
gram in order to take advantage of the efficiency of solution and sensitivity analysis. The approximation
technique enhances the decision-making ability of the engineering manager, but quality of solution must
be considered.
A non-linear relationship, either an objective or constraint, may be approximated using piecewise
linear functions as shown in Figure 9.6.

113
Engineering Management Handbook

Figure 9.6. Piecewise Approximation to a Non-linear Function

The quality of approximation depends on the number of piecewise functions used in the approximation.
Hewitt et al. (2015) provide a methodology to overcome this challenge by adapting a reformulation
technique from non-convex optimization to model non-linear functions with a discrete domain using sets of
binary and continuous variables and linear constraints.

9.3.3 Applications
Some high profile applications of interest to the engineering manager include marketing and inventory
management. In these areas, non-proportional relationships commonly exist among various profit/revenue
or cost parameters. In some cases, these relationships may be made linear by using auxiliary binary vari-
ables (as described earlier). Other common non-linear relationships are prevalent in financial management
and risk management due to compound interest, variance and co-variance.

9.4 Dynamic Programming

Dynamic Programming involves the recursive solution to a set of sub-problems. These models apply to
problems requiring (or allowing) a sequence of interrelated decisions. Solutions usually rely on network
representations, where the nodes represent decision points and arcs represent the cost/reward of decisions,
thus many of previously mentioned models can also be formulated using dynamic programming.

9.4.1 Solution Techniques

A variety of solution methods are used to solve for optimal solutions to dynamic programming models.
Most of these rely on the Principle of Optimality, which states that the optimal solution from this point
(decision epoch) forward is independent of the past. This principle allows for significant computation
savings over enumeration.
As noted, a network representation is often used to represent the costs associated with decisions.
Nodes, representing State Space, provide enough information for decision-making (cost computation),
and the arcs, representing Action Space provide the set of feasible decisions. The Objective Value Function
provides a recursive optimal cost path from any decision node to final node. A Boundary Condition is
required as a starting condition for the recursion.
Mathematically, optimal solutions may obtained using recursion (forward or backward), Dijkstra’s Algo-
rithm, reaching, or other techniques (Denardo, 2003). Computationally, these algorithms are quite condu-
cive to computer coding. Dynamic programs can also be transformed to linear programs and solved using
standard linear programming methods. In addition, a number of commercial software packages are available.

9.4.2 Applications
Due to the network nature of dynamic programming models, the network models discussed earlier are
prime candidates for dynamic programming formulations. Additionally, inventory modeling and invest-
114
 Operations Research

ment decisions are popular applications. Dynamic programming may also be used to solve integer and
non-linear models; however, the curse of dimensionality often hinders practical application due to long
solution times.

9.5 Stochastic Models

The previous section discussed system models with known or deterministic parameters. All too frequent-
ly systems, encountered by the operations researcher include random or stochastic variables. A system
model that uses a collection of random or stochastic variables is termed a stochastic process. Stochastic
processes occur frequently, and examples include the service time for a customer at a fast food counter, the
loading and unloading times of parts on a machine, or the random decisions of amusement park patrons
as they decide which attraction to experience next. Stochastic processes are frequently modelled with
Markov Chains discussed next, which support queuing theory discussed later in this chapter.

9.5.1 Markov Chains

Markov Chains are powerful tools useful in modeling systems that generally exhibit randomness in their
behavior, i.e., random or stochastic systems. A so-called stochastic process is an abstract (mathematical) entity
associated with the stochastic system. The mathematics underlying the events that occur in a stochastic
system is often captured via the stochastic process. Here, we will focus on discrete-event stochastic systems,
wherein the time between successive events that occur in the system is usually a discrete random variable.
The “state” of the system is typically an n-tuple (with n = 1 for the simplest case), which defines the
condition of the system at any given time. Consider, for example, a single-server queue that forms in a su-
permarket. Other examples of queues that are observed in real-world systems are: queues of jobs in front
of machines in a production shop, virtual queues of customers on telephones that form in call-centers,
and queues of passengers that form in the security checkpoint in an airport. The state of this “queuing
system” could be defined by the number of customers in the system. An important fact about the state of
the system is that it changes with time, and usually, it changes randomly. Predicting what the next state
will be if the current state is known, usually, requires an analysis of the random variables that govern the
system’s behavior. Also, analysis of this nature can help the engineering manager estimate parameters such
as the average time spent by the system in a given state in the long run and the long-run cost of running
the system. In other words, this kind of analysis can help formulate a suitable objective function for a sto-
chastic system, which then can be used for optimizing the system. What is important to remember is that
the analysis requires an understanding of the mathematical properties associated to the stochastic system
and the stochastic process.
The Markov Chain is one of the simplest examples of a stochastic process. We will study two types of
Markov Chains (processes): (a) discrete-time Markov Chains and (b) semi-Markov processes.

9.5.2 Discrete-time Markov Chains

We begin by introducing some notation. Let X(t) denote the state of the system at time t when viewed by
the analyst. Also, P[event] will denote the probability of the occurrence of the “event” (within the square
brackets). We will assume for the discrete-time Markov Chain model that the system is observed peri-
odically after unit time. Hence time, t, will be increased in steps of 1 as follows: 1, 2, 3, …Note that the
duration of the “unit time,” which is technically the time interval between successive views of the system
by the analyst, is determined by the analyst, and it could be any finite quantity, e.g., 1 second, 4.5 hours,
or 17 days.
The fundamental property that defines the Markov Chain is:

𝑃𝑃[𝑋𝑋(𝑡𝑡 + 1) = 𝑗𝑗|𝑋𝑋(𝑡𝑡) = 𝑖𝑖] = 𝑓𝑓(𝑖𝑖, 𝑗𝑗),

where f(i,j) is a function of the states i and j. What the above implies is that for a stochastic process to be
called a Markov Chain, if the current state of the system is known (i.e., the state of the system at time t),
115
Engineering Management Handbook

the probability that the system will transition to a given value of the next state (i.e., the state of the system
at time t+1) should depend only on what the current state is and what the next state is. This means that
the probability that the system will transition to a new state depends entirely on what the current state
and the new state are; further, it is independent of where the system has been in the past. This is called the
Markovian property, or the memoryless property.
A number of system parameters can be easily measured for a system that can be modeled as a Markov
Chain. This is because the Markov Chain lends itself to some straightforward mathematical analysis. We
will discuss one simple aspect of the Markov Chain that is almost invariably of special interest to man-
agers: calculation of the limiting probabilities, also called the invariant or steady-state probabilities, of the
Markov Chain.

Limiting Probabilities
The proportion of time spent by the Markov Chain in any given state in the long run is called the limit-
ing probability of the state. This concept is best illustrated with an example.
Consider a two-state Markov Chain. The transitions of the Markov Chain are defined by the so-called
one-step transition probabilities. Here, P(i,j) will denote the one-step transition probability or simply the
transition probability of going from state i to state j in one step. The transition probabilities can be conve-
niently stored in a square matrix, such that P(i,j) is the element in the ith row and the jth column in the
matrix. This matrix is called the transition probability matrix (TPM).
In a so-called regular Markov Chain, for every value of i and j, P n (i,j) > 0 for some finite value of n,
where Pn(i,j) denotes the element in the ith row and jth column of the TPM of the Markov Chain raised
to the nth power. For a regular Markov Chain, limn→∞P n (i,j) can be shown to exist and is independent of
i, i.e., it only depends on j; we will use the notation to denote limn→∞P n (i,j). This limit is called the limit-
ing (or steady-state) probability of the state j. The limiting probability of a state represents the proportion
of transitions the chain makes to that state in the long run (in other words, if we observe the system for a
long time). For the Markov Chain, it is usual to assume that the system spends the same amount of time
in every state and that the transitions are instantaneous; hence the limiting probability of a state also rep-
resents the proportion of time the chain spends in that state. It is thus clear that the limiting probability
provides us with useful information about the system.
The limiting probability can be easily computed from the TPM via the solution of the following
system of linear equations:

for j = 1, 2, ... , k (where k denotes the number of states) and

We illustrate this idea with a simple example below.

Consider a 2-state Markov Chain, whose TPM is as follows:

Assume that the Markov Chain models a machine that can either be “up” (working) or “down”
(under repair because of failure); state 1 stands for the up state and state 2 for the down state. Solving the
linear system of equations provided above, we obtain that π (1) = 0.7273 and π (2) = 0.2727. This solu-
116
 Operations Research

tion provides the manager with a critical piece of information: the machine is down 27.27% of the time.
Analysis of this nature can lead to downtime reduction and process improvement.
Much of the work in building a Markov-chain model is in computing elements of the TPM. Once
the TPM is computed, it can be used elegantly to derive a number of system measures of interest to the
manager. Also, if the manager has access to the costs associated with spending time in a system, these
measures can also be useful for measuring the costs of operating a system under a given strategy. The
computations needed for these measures can be easily performed with the help of commonly available
software such as MS EXCEL or more sophisticated software programs such as MATLAB.
The above was a very simplified example (with a small 2-state Markov Chain) presented only for il-
lustrative purposes. However, we note that the principles of computing limiting probabilities can be easily
extended to scenarios with a larger number of states. In practice, it is common to see large Markov-chain
models with hundreds of states used by managers in production systems for inventory control, quality
control, and preventive maintenance. Markov Chains are also very useful in analyzing queues, which is a
topic that we will discuss in more detail next. Applications of Markov-chain-based models can be found
in a very large number of other domains, including wireless communication, analysis of banks, airports,
and amusement parks, robotics, speech recognition, forecasting, and biological modeling to name a few.

Absorbing Markov Chains

An absorbing state, i, in a Markov Chain is one for which P(i,i)=1, i.e., once an absorbing state is entered,
the chain does not leave the state. A Markov Chain in which at least one state is an absorbing state is
called an absorbing Markov Chain. The states of an absorbing Markov Chain that are not absorbing are
called transient states. A simple example of a Markov chain that is absorbing is:

In the above, the third state is the absorbing state. Examples of systems that can be modeled with absorb-
ing Markov chains are a production process that moves through gradually deteriorating acceptable states
but eventually enters an absorbing state from where it cannot return to an acceptable state and the process
must be halted.
Interesting questions that are relevant in absorbing Markov Chains are: (1) If there are multiple
absorbing states, what is the probability that the system is absorbed by a given absorbing state? (2) What
is the expected number of transitions that occur before a system is absorbed in a given absorbing state?
Answers to these questions depend on the initial state of the system and the TPM. Some straightforward
mathematical analysis can be used to answer the questions posed above. Absorbing Markov Chains are
useful in analyzing biological processes and quality control processes. We refer the interested reader to
Ross (2006).

9.5.3 Semi-Markov Processes

The Semi-Markov Process (SMP) is a more general model than the Markov Chain. In an SMP, we assume
that the time spent in any given state is a random variable with a given distribution. In other words,
underlying the SMP is a Markov Chain, which is usually referred to as the “embedded” Markov Chain.
The time spent in a state is usually called the sojourn time. If the sojourn time for every state is exponen-
tially distributed, the SMP is called a Continuous-Time Markov Chain (CTMC). We will first discuss the
CTMC, and general SMPs.

Continuous-Time Markov Chains (CTMCs)

In a CTMC, the time spent in every state has the exponentially distribution. The limiting probabilities of
the CTMC are usually found from the rate of transition from one state to another. While it is certainly
possible to determine the transition probabilities from the distributions involved, it is easier to use the
rates of transition from one state to another to determine the limiting probabilities, via the so-called bal-
117
Engineering Management Handbook

ance equations. It is easy to determine the rates from the underlying distributions. Note that use of these
balance equations works only for CTMCs and should not be used for other types of Markov Chains.
Let qij denote the rate of transition from state i to state j, and let vi denote the total rate of transition
from state i to all the other states. Thus, vi = Σqim, where the summation is over all values of m. Then,
the limiting probabilities can be determined by solving the following system of linear equations (balance
equations): For i=1,2, … , k,

and

Countless examples of CTMCs can be found in EM and social sciences, including the analysis of cer-
tain types of queues, inventory control, and studying biological processes (cancer cells, HIV, and flu virus
propagation). An attractive feature of the CTMC is that it can be analyzed very easily for its steady-state
properties via the balance equations provided above. However, a major criticism of the CMTC model is
that it works only if all the random variables for the sojourn times are exponentially distributed; this is
not usually the case in real-world applications.

General SMPs
The generalized model of the SMP in which the sojourn times do not have the exponential distribution
exploits properties of the embedded Markov Chain. In particular, to determine the proportion of time
spent by the SMP in any given state, one must first compute the limiting probabilities of the underlying
Markov Chain. Let L(i) denote the proportion of time spent in state i by the system. Then, if s(i) denotes
the mean sojourn time in state i, we have that:

for i=1,2, … , k and denotes the limiting probability of the ith state in the embedded Markov Chain.
More interestingly from the standpoint of the engineering manager, if there are costs involved in operating
the system, one can determine the average cost per unit time (ρ) of operating the SMP as follows:

where R(i) denotes the total cost of being in state i. The above is a very useful expression for quantifying
the performance of a semi-Markov process (and hence any CTMC and any Markov Chain) in terms of
dollars. Note that the expression developed above for the average cost of operating the system also works
for the Markov Chain by setting s(i) =1 for all values of i. The above formulation has been widely used
in the literature to develop objective functions of production systems (Tomasevicz and Asgarpoor, 2009;
Solo, Kharoufeh, and Ulukus, 2010; Nodem, Kenne, and Gharbi, 2011).

9.5.4 Queuing Theory

The theory of queuing has been developed in order to study queues or waiting lines that form in service
systems such as grocery stores, banks, airports, and amusement parks, production systems, e.g., machine
shops or assembly systems, and electrical systems, e.g., Internet and ATM networks. Queues are usually
118
 Operations Research

formed when there are one or more servers and a number of entities that need service from the server.
Examples of queues that are observed in real-world systems are: queues of jobs in front of machines in
a production shop, virtual queues of customers on telephones that form in call-centers, and queues of
passengers that form in the security checkpoint in an airport.
Long waiting lines generally imply long waits that typically result in frustration for those waiting.
On the other hand, ensuring short waits oftentimes requires a large number of servers or highly efficient
servers, who may charge higher salaries. Queuing systems are often studied for the mean (and higher
moments) of the waiting time and queue length, average utilization of the server, and the probability that
a customer reneges. Designing a queuing system appropriately is usually an important problem from the
standpoint of managing the system efficiently. Under-staffed servers can lead to longer than expected waits
driving customers away, while overstaffed servers can be expensive and can increase operating costs. We
will discuss some basic notions related to queues in what follows.

9.5.5 Stability of Queues

The arrival rate at any server station (which may have multiple servers) is the mean number of customers
that arrive to the server station in unit time. The arrival rate will be denoted by λ in our discussion. The ser-
vice rate is the mean number of customers served by the server station in unit time; it will be referred to as μ.
If γ < μ, we say that the system is stable, i.e., the system does not get overloaded. If this condition is not true
and if there is no restriction on how many customers can wait in line, gradually the system becomes unstable
and the number of customers waiting in the line starts approaching infinity. This happens unless there is a
restriction on how many customers can wait in the line. Usually, there is little point in analyzing unstable
queues. However, unstable queues do form in the real world. When an Internet website crashes, it is usually
because the server cannot handle the number of people trying to get on to that website.

9.5.6 Little’s Rule

Any queuing system can be subjected to a well-known principle of queuing called the Little’s rule (see
Gross and Harris, 1998 or any standard text on queuing for additional details). This principle says that:

𝐿𝐿 = 𝜆𝜆 𝑊𝑊
where L denotes the average length, W denotes the average wait, and λ denotes the rate of arrival of
customers into the system. In other words, if one knows the arrival rate, then knowledge of the mean wait
in the system can be computed from the mean length and vice-versa. This is a very useful principle widely
used in analysis of queuing systems. A simple application is as follows. Let the mean length in a queue,
usually denoted by Lq, be 25 and the mean rate of arrival be 5 persons per minute, the mean waiting time
in the queue will be: Wq = 25/5 = 5 minutes. This kind of analysis can be applied to any queue or even a
queue, which is a part of a queuing network (which has several interconnected queues).
If the server is a machine in a production shop, the mean length in the system usually denotes the
work-in-progress (WIP) inventory associated with the machine. It turns out that Little’s rule has been
extensively used in analyzing lean manufacturing systems (e.g., Askin and Goldberg, 2002).

9.5.7 Single-Server Single-Channel Queues

Single server single-channel queues are those in which all customers stand in one line and there is only
one server. These are usually the simplest types of queues to model. Generally, the ratio of the arrival rate
to the service rate in such queues is called ρ, i.e.,

where μ denotes the mean rate of service by the server. It can be shown that ρ also equals the proportion
of time the server is busy, i.e., the utilization of the server.

119
Engineering Management Handbook

We will discuss four types of single-server queuing models. We will assume that the server is available
at all times and that the queue is stable. To describe these models, we will first introduce some commonly
used queuing notation, the Kendall-Lee notation. A queue is often described with the symbolic: X/Y/n/s,
where X denotes the distribution of the inter-arrival time, Y denotes the same for the service time, n
denotes the number of servers, and s denotes the capacity of the waiting line in the queue. When s is
omitted, it implies that there is infinite waiting capacity in the queue. M is commonly used to represent
the exponential distribution and G is used to stand for general, i.e., any given arbitrary distribution. Thus,
an M/G/1 queue is a single-server queue whose inter-arrival time is exponentially distributed and service
time is generally distributed (has any arbitrary distribution).

M/M/1 Queues
The continuous-time Markov Chain model discussed above can be used to generate the following expres-
sion for the mean length of an M/M/1 queue:

where ρ denotes the utilization of the server (as defined previously). Via Little’s rule, one can compute the
mean wait in the queue. The mean wait in the system, W, for this queue is given by:

which follows from the fact that the mean wait in the system is a sum of the mean wait in the queue, Wq,
and the mean time in service at the server which is 1/μ. From W, via Little’s rule, it is easy to compute the
value of L, the mean number in the system.

M/G/1 Queues
This queue has been studied extensively over the years, but the most useful result related to this queue was
developed by Pollaczek and Khintchine in the 1930s. Their result, usually called the Pollaczek-Khintchine
formula, produced the following exact expression for the queue length:

where σS2 denotes the variance of the service time. Little’s rule (Equation 1) and Equation 2 can then be
used to determine the mean wait in the queue and the system. This formula is very useful in production
systems and in telecommunication systems.

G/G/1 Queues
This is the most general model that has the greatest applicability. Unfortunately, no closed-form formula
exists for its basic performance measures (queue length or wait). Marchal (1976) developed a very use-
ful approximation that works extremely well in practice. We present it next, along with some additional
quantities needed for this model. Let:
• C2: coefficient of variation of a random variable, i.e., C2 = variance /(mean)2
• : variance of the inter-arrival time
• C : coefficient of variation of the service time
s
2

• C : coefficient of variation of the inter-arrival time

a
2

120
 Operations Research

Clearly, then, Marchal’s formula is:

The previous equation is used in measuring waits in telecommunication systems, analysis of waiting
times in amusement parks, and in measurement of inventory in Kanban-controlled systems.
It is to be noted that Little’s rule and Equation 2 can be used in the context of this queue as well.
Under heavy traffic, i.e., roughly speaking when:

a much superior approximation, called the heavy traffic result, exists for the G/G/1 queue (see Medhi, 2002);
this result makes use of a stochastic process called Brownian motion (discussed later in the chapter).

9.5.8 Multiple-Server Queues

Not all queues have single servers. When a queue has multiple servers, it can be a multiple server sin-
gle-channel queue, in which all customers wait in one line, or a multiple-server, multiple channel queue
in which customers wait in different lines but are served by a pool of servers. Such queues are more diffi-
cult to analyze. Oftentimes, simulation is the only way to evaluate the performance of these queues. See
Gross and Harris (1998) or Medhi (2002) for an in-depth discussion of topics related to multiple-server
queues.

9.6 Advanced and Other Topics

Traditional OR topics will only take the operations researcher so far before problems become so complex
that they can no longer be solved in a reasonable amount of time. With the advent of Big Data systems,
the problem is only compounded. Meta-heuristics are often employed to efficiently search a large solu-
tion space for integer and mixed integer programs. Markov processes can be further exploited in Markov
Decision Processes and Brownian Motion. Finally, due to problem complexity, mathematical models are
sometimes avoided altogether in favor of creating a system model using discrete event simulation. This
section provides an introduction to and application areas for these advanced topics, and concludes with
an introduction to Big Data and its impact on OR.

9.6.1 Meta-heuristics
Meta-heuristics are relatively new heuristic techniques that attempt to solve those problems arising in
discrete and combinatorial optimization which cannot be solved via exact methods such as branch and
bound or dynamic programming. The field of discrete optimization is well-known for problems that
do not have any nice structure. Methods that produce global optimal solutions usually break down on
these problems due to their size or the structure. Another characteristic of these problems is that there are
usually multiple optima and derivative-based techniques can get trapped in local optima, which are not
necessarily the global optima. On such problems, a class of methods called meta-heuristics has emerged in
recent times. Because a very large number of real-world problems share these characteristics, this remains
an important challenge in the field of OR.
The meta-heuristic solutions in general tend to start at any arbitrary solution and “move” to bet-
ter solutions in their neighborhood. Hence, meta-heuristics are also sometimes called neighborhood
search methods or local search methods. Some meta-heuristics, however, tend to search over domains of
the objective function that are not in the neighborhood of the current solution. The three best-known
meta-heuristics are: genetic algorithms (Holland, 1975), simulated annealing (Kirkpatrick, Gelatt, and
121
Engineering Management Handbook

Vecchi, 1983), and Tabu Search (Glover, 1986; Hansen, 1986). This list is not exhaustive, however, and
other options include ant colony optimization, greedy randomized adaptive search procedure (GRASP),
variable neighborhood search, and iterated local search to name only a few (Blum and Roli, 2003).
Genetic algorithms tend to rely on a stochastic search in which the move from the current solution
to the next is guided by a random process that uses ideas from evolution. Simulated annealing is also a
stochastic search algorithm in which the move from the current solution to the next is inspired by a met-
allurgical process. Tabu search is a so-called “recency-based” search technique in which the move from the
current solution to the next is based on the moves that have actually occurred in the recent history of the
algorithm. All of these algorithms have their advantages and drawbacks. See Pham and Karaboga (2000)
for a discussion of their details and applications in engineering.
The genetic algorithm uses a strategy of cross-over that occurs in chromosomes during reproduction.
The strategy for selecting an improved solution mimics that of the evolutionary processes such as muta-
tion. Typically, in a genetic algorithm, one moves from a population of solutions to another. This is one of
the first biologically inspired meta-heuristics.
Simulated annealing as stated above relies on a technique used in metallurgy for strengthening metals to
obtain high quality solutions. In the annealing technique in metallurgy, the temperature of the liquid metal
is lowered at a sufficiently high rate so that it acquires some desirable properties, e.g., mechanical strength,
as it solidifies. In simulated annealing, the role of temperature is played by the probability of moving to a
solution that is not better than the current solution. As the algorithm progresses, this probability is reduced;
in other words, the temperature is reduced. It is hoped that during the initial stages of the search process,
the algorithm avoids all the local optima and escapes out of them, but after searching the solution space for a
sufficiently long time period, eventually gets trapped in a local optima that is also a global optimum.
Tabu search is different from the two techniques described above in that it is not usually a stochastic
search. However, in tabu search moving from one solution to a better solution is quite flexible. The strat-
egy to move from one solution to another can exploit the structure of the problem if it is known. What is
important in tabu search is that a list is maintained of recent moves. If a move has been made recently and
is in the list, also called tabu list, it is not permitted. This ensures that the algorithm does not repeatedly
traverse the same set of solutions.
We would like to note that meta-heuristics are very widely applied in industry for solving large-scale
and complex combinatorial optimization problems. Some of the noteworthy applications of meta-heu-
ristics have occurred in the area of machine scheduling, transportation routing of large supply chains,
logistics management, layout designing, VLSI circuit design, and airline scheduling.

9.6.2 Advanced Stochastic Models

Markov Decision Processes

Markov Decision Processes (MDPs) are decision-making problems associated with systems that can
be modeled via Markov Chains. Essentially, MDPs can be viewed as applications of control theory to
optimizing stochastic systems. The area of MDPs have seen a great deal of research activity in the last 50
years, and there are now numerous applications of MDPs in a variety of fields ranging from marketing to
medical disease treatment. Our goal here is to present the main ideas, and name a number of application
areas for the engineering manager.

Mathematical Model
We will explain the mathematical model underlying an MDP with a simple example. Consider a 2-state
Markov Chain in which two actions are permitted in each state. For instance, in the example considered
in the Limiting Probabilities section in this chapter, the two actions could be “Repair the Machine” and
“Do Nothing.” Usually, a unique TPM is associated with every action. Also, in the MDP model, one has
a so-called Transition Reward Matrix (TRM), which contains data for the immediate reward gained in
going from one state to another. Consider the following MDP:
122
 Operations Research

where TPMa and TRMa denote the TPM and TRM, respectively, associated with action a. The element in
the ith row and jth column of the matrix TRMa denotes the reward gained from selecting action a in state
i and transitioning to state j as a result. Like the TPM, a unique TRM is associated with each action.
A typical goal of the MDP is to consider the evolution of the system over the long-run, i.e., an
infinite time horizon. A policy is a map from the state space to the action space. A deterministic policy
specifies a unique action for each state in the system. Using optimization techniques, it is possible to
determine the “best” deterministic policy that optimizes some performance measure, provided an optimal
deterministic policy exists.
Using the TPMs and the TRMs, it is possible to develop expressions for the long-run average reward
per unit time or the total discounted reward earned over the long run. We will present an expression for
the first measure, average reward. Let p(i,a,j) denote the term in the ith row and jth column of TPMa and
r(i,a,j) denote the corresponding term in TRMa. Then, the average reward, ρ, of a policy in which action
a is chosen in every state is given by:

where denotes the limiting probability of state i when action a is chosen in every state. Clearly, ρ
depends on the policy, and the optimal policy is one for which ρ is maximized.
One way to determine the optimal policy is to evaluate the objective function of every policy, which
can make the problem very difficult to solve because typically there is a very large number of policies; for-
tunately methods based on linear programming and dynamic programming have been devised, which are
more efficient for solving these problems (Bertsekas, 1995). Dynamic programming methods originated
from the work of Bellman (1957) and Howard (1960). Recent developments in the field of reinforcement
learning (Bertsekas and Tsitsiklis (1996); Sutton and Barto (1998); Szepesvari (2010); Gosavi (2014) have
allowed managers to solve an MDP within a simulator of the system without access to the TPMs, which
may be notoriously hard to find for complex and large-scale systems.

Applications
MDPs have been used widely in a variety of domains. A critical difficulty in applying the MDP model
in the real world has always been the task of generating the transition probabilities. If this can be over-
come or circumvented (possibly via simulation-based methods such as reinforcement learning), the MDP
provides high-quality solutions that can outperform industrial heuristics. We will now discuss some key
applications of MDPs in the industry.

Inventory Control: Many of the fundamental inventory control models such as (S,s) strategies have been
analyzed via MDPs. In the area of supply chains MDPs continue to provide useful insights that often
lead to reduction of costs and increase of profits. The interested reader is referred to Fox, Barbueanu, and
Teigen (2000) for a tutorial on how the MDP framework forms the underlying basis for agent-based
architectures in modern supply chain management software.

Communication Networks: Management of cell-phone networks and asynchronous transfer mode (ATM)
networks requires the solution of routing problems and so-called admissions control problems. Many of
these problems are usually set up as MDPs and solved via the techniques enumerated above (Altman, 2002).

123
Engineering Management Handbook

Revenue Management: Revenue management is a broad field that encompasses study of pricing problems
in the context of resource allocation. The problem of allocating seats to “fare classes” is a central one for
the airline industries and hotels that use revenue management extensively in their operations. The revenue
management can be set up as a finite horizon MDP (Subramaniam, Stidham, and Lautenbacher, 1999).
A related infinite horizon MDP has also been solved by reinforcement learning (Gosavi, 2004; Gosavi,
Bandla, and Das, 2002).

Total Productive Maintenance: Total productive maintenance is a management philosophy popularized

by Toyota motors as a part of “lean enterprise management.” The problem of preventive maintenance of
production-inventory systems has been studied via an MDP model in Schouten and Vanneste (1995)
and a semi-Markov Chain model in Das and Sarkar (1999). MDPs provide the most accurate policies for
preventive maintenance in production systems.

9.6.3 Brownian Motion

Brownian motion was first discovered as a mechanism to describe the motion of particles in liquids
in 1827 by Robert Brown. A number of other mathematical models were subsequently developed for
the same, but the most successful models became available only as late as 1905 with the dissertation of
Einstein (see Einstein, 1956) and the work of Smoluchowski (1906). Norbert Wiener is credited with
having developed a rigorous definition of Brownian motion (also called a Wiener process in his honor).
An important fact about Wiener’s definition is that it is abstract and allowed the model to be used as an
operational model outside of physics.
Although we will not delve into the mathematical details of Brownian motion here, it is important
to point out that it can be explained as a type of limit of the random walk, which is a specific class of
Markov Chains. We will limit our discussion to some of the key applications of Brownian motion in
operations research.

Financial Engineering: Black and Scholes (1973) developed the famous Black-Scholes formula that uses
a Brownian motion model to describe the fluctuation of stock prices. (This work, in combination with
parallel work completed by Merton (1973) has been awarded a Nobel Prize in economics.) These ideas
have been subsequently extended to numerous other topics in the study of stock markets, options, and
other monetary instruments offered by banks and financial institutions. It is the case that almost all the
mathematical models in financial engineering rely on some sort of stochastic process. This is an area of
ongoing research.

Queuing Networks: A queuing network is a system in which customers from one queue join another
queue(s) in the system. Usually the queues are inter-connected. Queuing networks are notoriously hard
to analyze. Queuing networks are very common in manufacturing systems with serial or forked transfer
lines. Queuing networks are common in particular in semi-conductor manufacturing. Starting with the
work of Kingman (1962), Brownian motion has been used to study the single-server single channel queue
under the so-called heavy traffic conditions. This body of work has now been significantly expanded
and provides some very powerful results in the analysis of queuing systems including queuing networks
(Chen and Yao, 2001). This is also an area of active research that holds tremendous promise of generating
closed-form models for performance analysis of complex queuing systems and scheduling of workloads in
queuing networks.

Inventory Control: Brownian motion has been used to model inventory (Sethi and Thompson, 2000) in
production systems. Brownian motion has also been used to model the behavior of a deteriorating quality
control process. Although it is unclear how many of these models have been actually used by practicing
engineering managers, because many of these works are still in the early stages of research and develop-
ment, it is well-known that many operations research models in the stochastic area that started out as
theoretical concepts are now widely applied and used in the industry, examples being the news vendor in
124
 Operations Research

supply chain management (Wong, Qi, and Leung, 2009) and Littlewood’s equation (Littlewood, 1972) in
revenue management.

9.6.4 Discrete-Event Simulation

Discrete-event simulation is a numerical or computational approach for evaluating the performance of a
discrete-event system; a discrete-event system is one in which the time between two successive events is
usually a finite quantity. Some examples of events in a queuing system are: the arrival of a new customer,
service completion of a customer in the system, breakdown of the server, etc. Typically, the time between
such events is a random variable whose distribution is known, or it is a function of random variables
whose distributions are known. This time could also be a deterministic variable, and the simulation is
called deterministic simulation. Unless specified otherwise, discrete-event simulation is usually understood
to be for a stochastic system. While simulation is the topic of another chapter, we will highlight its rela-
tionship with OR.
In a discrete-event simulation, one samples values of the random variables (underlying the system)
from their distributions. These random variables are generally called the input variables for the simula-
tion. The samples generated are used to determine the time interval between successive events. Essentially,
the mechanism underlying discrete-event simulation is to generate the time intervals between successive
events and collect statistics about the system from every event generated in this process of “recreating”
events within the simulator. Because this is a time-consuming and tedious process, it is best left to the
computer. The time (in the simulation environment) of every event that can occur in the system is also
determined and stored in the computer. The sequence of events or “event list” along with the “simulation
clock,” which is simply a list of the actual times of each event stored in a chronological order, play a key
role in ensuring that the events are regenerated properly within the computer.
A simulation program is generally written with the intention of collecting statistics about one or more
parameters of interest (performance measures). Oftentimes, these parameters are random variables them-
selves and are commonly called the output variables or response variables from the simulation. Usually, the
value of the parameter is obtained by averaging over several values. Hence, in order to obtain the desired
average value of the parameter(s), one must update the value of the parameter after every relevant event. This
process of updating values of the output variables must occur simultaneously as the events occur. For more
details on the inner workings of a simulation program, the reader is referred to Law and Kelton (2000).
A large number of software programs are now available in the industry. These software programs are very
user-friendly and are very popular in the industry.
Simulation is a very powerful tool for evaluating the performance of a system. For analyzing stochas-
tic systems, it is one of the most widely used operations research tools in the industry (Carson et al., 2004).
Usually, if the distributions of random variables are available, it is possible to simulate the system. How-
ever, simulation is not used if a closed-form mathematical model is available. This is because the mathe-
matical formula can be used easily within spreadsheet or some other software for analysis of the system.
It is usually the case that writing the computer program in the simulation package requires a significant
amount of effort and expertise, and it also takes a significant amount of time to run the program and
obtain results. Hence, simulation is not the preferred model if a mathematical model can be developed.
However, with complex systems, it is oftentimes very difficult to develop exact or even near-exact math-
ematical models. It is in cases like these that simulation becomes extremely useful. Needless to add, most
real-world systems produce complex scenarios for which closed-form models are not available, and one
must take resort in simulation.

Simulation and Optimization

Simulation is very effective at answering what-if kind of questions about a given system, e.g., what will be
the throughput if an additional machine is purchased. Even today, a majority of applications of simula-
tion in the industry are geared toward this end. However, optimizing a system via simulation is a relatively
difficult idea because simulation is like a black box and provides the numerical value of the objective
function at any given point. Also, simulation takes a significant amount of time to generate the objective
125
Engineering Management Handbook

function value. Hence, combining simulation with optimization techniques can be challenging. However,
recent breakthroughs in continuous optimization, e.g., simultaneous perturbation (Spall, 1992) and in
control theory, e.g., reinforcement learning (Watkins, 1984) has made it possible to combine simulation
with optimization (see Gosavi, 2003 for an overview of this topic).

Applications
Simulation is very widely used in the military for planning their operations, by health-care service pro-
viders such as hospitals and ambulance services, for analyzing electrical communication networks, for
analyzing the operations of an amusement park, and of course in production systems. In production
systems, the uses of simulation are many: measuring the throughput of a system, measuring the inventory
in a system and the lead time of a new product, analyzing the throughput and inventory of a system with
automated guided vehicles (AGVs), and detecting the bottleneck in a system.
Oftentimes, the analysis in the systems described above revolves around measuring the time taken
to perform an activity, waiting times in queues involved in these systems, and the utilization of servers in
the queues. Very importantly, simulation can provide critical answers to what-if questions that can lead to
improvements in the design of the system.

9.7 Big Data and Operations Research

Since the first published academic article in 2008, the topic of Big Data has seen an exponential climb in
published literature (Wamba et al., 2015). This rise in popularity is due not only to the large number of
challenges associated with Big Data, but also is significantly due to the potential for Big Data to provide
new insights impacting all facets of business decisions. Big Data, and it’s closely related cousin the Inter-
net of Things, fall directly into the existing OR Methodology discussed in Section 9.1.3, with the data
collection phase impacted the most. This section covers a description of Big Data and how it relates to
OR, the Big Data value chain, and two case studies of Big Data applications in industry.

9.7.1 An Introduction to Big Data and the Internet of Things

Big Data is often differentiated from large or massive amounts of data by discussing the Vs. Depending
on the framework chosen there can be between three to five Vs, here we have chosen White’s (2012) 5 Vs
representation: volume, variety, velocity, veracity, and value. Volume, as the name suggests, refers to the
sheer quantity of data. The data volumes experienced in true Big Data situations should exceed the stan-
dard capacities and capabilities of traditional relational database data management systems (Chen et al.
2014). Minimally, there should be terabytes of data to process, though often the data quantity is orders
of magnitude larger. Variety refers to the types and structure of data collected. Big Data datasets should
have a mix of several data types including structured data such as database entries, unstructured data such
as free text, time series data such as weather data or click streams, video, geospatial, and image data. The
velocity characteristic of Big Data refers to the frequency of receiving new data points. Big Data datasets
are constantly growing at rapid rates, making the development of real-time data analytics a prevailing
challenge. The veracity of the data refers to the trustworthiness of the data. Big Data datasets may often
be noisy, contain duplicate data, or due to the data sources themselves have underlying trust issues. The
final attribute is value. Value describes the idea that there is economic value to be found in analyzing the
data as a Big Data dataset, but the individual data points on their own provide little value.
Coupled closely with Big Data is the idea of The Internet of Things, often abbreviated IoT. The Internet
of Things is a Big Data instantiation where a significant proportion of the data comes from sensors em-
bedded in devices and machines. By collecting and processing in real time, these sensor data and machines
can work together to optimize process and system efficiencies. The machines and devices producing data
could be cell phones, vehicles, a factory CNC machine, street lights, solar panels, wind mills, subway trains,
busses, household appliances, rfid scanners, or stock market tickers to name only a few options. An example
instantiation of the Internet of Things is the Smart Grid. In the Smart Grid, households have Smart Meters
that receive price signals from the utility. These price signals can be relayed to appliances and HVAC systems
126
 Operations Research

within the premise in order to change their settings to accommodate the new price of electricity. Mean-
while, the Smart Meters are reporting back to the utility usage data at frequencies of up to every 5 minutes.
Data is collected and analyzed by the utility on these usage patterns. Optimal pricing strategies are developed
in order to reduce peak demand on the electric grid. Smart Meters also relay outage information back to the
utility. The utility can then use that information to optimize restoration efforts. Notice, even in this Smart
Grid example, that despite the large amount of data, the data is still being used for traditional OR tasks:
optimizing a restoration plan, optimizing price signals to produce a desired demand pattern, and optimizing
appliance function to minimize electricity cost.
Despite the large volume of data generated by the Internet of Things and enterprise Big Data systems,
the same OR questions still apply to the system as a whole. The ORer still wants to maximize profits,
minimize waste, and generally use resources most efficiently as possible. The connection to Big Data is
that there is now more data to work with and with that comes more areas for optimization. Big Data
frameworks have significant impact on Step 2: Data Collection of the OR Methodology presented in
Section 1.3. Here the Operations Researcher can aid in identifying data collection requirements, and can
benefit significantly from the data collected. The additional data available to Operations Researchers in a
Big Data enterprise promises to improve the model validity and the value add for OR based analyses.

9.7.2 Big Data Value Chain

Executing Big Data projects can be divided into four main steps, each requiring increasing effort, while
simultaneously providing increased value. The steps involved in the Big Data value chain are data genera-
tion, data acquisition, data storage, and data analysis as outlined by Chen et al. (2014) and seen in Figure
9.7. Data generation requires the least effort and likewise provides the least value. Data is generated from
diverse sources including sensors, video feeds, Internet click streams, social media, transaction informa-
tion, logistics data, energy data, and vehicle data, to name only a few sources.
Creating or generating the data is followed by the task of actually recording the data, so that it can be
analyzed at a later point in time. Recording the data is part of the data acquisition stage. Data acqui-
sition consists of data collection, data transmission, and data pre-processing, all of which occur prior to
data storage. Of the three parts of data acquisition, data pre-processing plays the most significant role in
affecting the quality and speed of the data analysis phase. Data can be pre-processed to remove noisy or
anomalous data points, to remove data from faulty sensors, to fuse data with other sources, and to reduce
data redundancy thereby minimizing storage requirements.

Figure 9.7. Big Data Value Chain

127
Engineering Management Handbook

Once data is generated, acquired, and transmitted the next phase is data storage. Storing Big Data
requires the use of new information technology infrastructure that may or may not exist in your current
enterprise. Due to the size of Big Data, storage systems require data be distributed across multiple inter-
connected servers, and consideration needs to be given to consistency, availability and partition tolerance
(Brewer, 2000). Distributed file systems are fairly mature and include open source options such as HDFS
and Kosmosfs. Depending on the type of data being stored, you may want to have a key-value database
such as Dynamo, a Column-Oriented Database such as HBase or Google’s BigTable, a document database
such as MongoDB or CouchDB, or a combination of two or more of the above.
Finally, after the data have been generated, acquired and stored comes the analysis phase. It is in the
data analysis phase that OR resides. While common data analysis tools such as R or CPLEX can still be
used on subsets of big data datasets, significant progress has been made in exploiting Big Data distributed
frameworks, such as Map Reduce, to solve complex integer programs (Chandu, 2014).

9.7.3 Big Data Case Studies

Big Data in practice requires the integration of disparate data sources often found across different depart-
ments of an organization. Bringing these sources together not only requires technical skills, but more
importantly strong leadership and the ability to bring diverse groups together to see the good of a com-
mon vision. Here two case studies are presented that highlight the value that can be achieved by creating
a Big Data vision for your company.

Electricity Theft Detection: TROVE, a predictive data science company, in partnership with Teradata
(2015), a commercial big data information management and analytics platform, provide details on the use
of big data to identify incidences of electricity theft for a large west coast US utility. Like many progressive
utilities, when this utility transitioned to Smart Meters, they lost their eyes in the field as meter readers
no longer needed to visit meters. Prior to using a Big Data strategy, the utility’s primary theft detection
system was focused on leads generated by customers calling in to report suspicious activity. In a single
year, 15,000 such leads were investigated, generating a hit rate of only 30% true incidence of theft. By
instead focusing on their many internal data sources, the utility was able to improve their performance.
TROVE was able to increase the lead hit rate from 30% to 86% by fusing smart meter data with custom-
er demographic information, premise data, and other available sources, and then applying segmentation
and optimization algorithms.

Emergency Management: Wamba et al. (2015) provided details of a longitudinal case study on the use of
Big Data by New South Wales State Emergency Service (NSW SES), which integrated both structured
and unstructured data to form a comprehensive picture of the state of their 17 regions. The data integrat-
ed information sources including real-time volunteer staff availability, GIS, equipment availability and
location, weather services, police service data, fire and rescue readiness, rural fire readiness, public infor-
mation services, public welfare services, health services, energy and utility services, and environmental
services. By integrating all these systems, the NSW SES was able to enhance their situational awareness
enabling them to evaluate and assess mission readiness. The system allowed for the improved coordina-
tion of emergency response by coordinating 17 regional headquarters, including current staffing and GIS
systems, to track and monitor mission completion. Furthermore, the system allowed visibility into “who
and where,” which allowed for the reallocation of assets across the region in order to maximize emergency
readiness. Finally, with visibility into the entire system, NSW SES was able to optimize future invest-
ments by minimizing current vulnerabilities. Cited as crucial for the system to work was active engage-
ment from both the implementation team and top management.

9.8 References
Altman, E., “Applications of Markov Decision Processes in Communication Networks,” In Handbook of
Markov Decision Processes, edited by E. Feinberg and A. Schwartz, Chapter 15, 2002, pp. 489-536.
Askin, R., and Goldberg, J., Design and analysis of lean production systems. New York: Wiley, 2002.
128
 Operations Research

Banks, J, Carson, J, Nelson, D, and Nicol, D., Discrete-Event System Simulation, 4th edition, Prentice
Hall, 2006.
Bellman, R. E., Dynamic Programming. Princeton, NJ: Princeton University Press, 1957.
Bertsekas, D. P., Dynamic programming and optimal control. Belmont, MA: Athena Scientific, 1995.
Black, F. and Scholes, M., “The Pricing of Options and Corporate Liabilities.” The Journal of Political
Economy, vol. 81, no. 3, 1973, pp. 637-654.
Blum, C., and Roli, A., Metaheuristics in Combinatorial Optimization: Overview and Conceptual Com-
parison. ACM Computing Surveys, vol. 35, no. 3, 2003, pp. 268-308.
Brewer, E., Towards Robust Distributed Systems. In PODC, pg 7, 2000.
Chandu, D., “A Parallel Genetic Algorithm for Three Dimensional Bin Packing with Heterogeneous
Bins,” International Journal of Computer Trends and Technology, vol. 17, no. 1, 2014, pp. 33-38.
Chen, H. and Yao, D., Fundamentals of Queueing Networks: Performance, Asymptotics, and Optimization,
New York: Springer, 2001.
Chen, M., Mao, S., Zhang, Y., and Leung, V. Big Data: Related Technologies, Challenges and Future
Prospects. New York: Springer, 2014.
Das, T.K. and Sarkar, S., “Optimal Maintenance in a Single Machine Production Inventory Systems,” IIE
Transactions on Quality and Reliability Engineering, vol. 31, no. 6, 1999, pp. 537-551.
Denardo, E. V., Dynamic Programming: Models and Applications, New York: Dover Publishers, 2003.
Einstein, A., Investigations on the Theory of Brownian Movement. New York: Dover Publishers, 1956.
Fox, M., Barbueanu, M., and Teigen, R., Agent-Oriented Supply-Chain Management, International Jour-
nal of Flexible Manufacturing Systems, vol. 12, 2000, pp. 165–188.
Gass, S. I. and Arjang, A., An Annotated Timeline of Operations Research: An Informal History, Robert H.
Smith School of Business, University of Maryland, 2004.
Glover, F., “Future paths for integer programming and links to artificial intelligence.” Computers and
Operations Research, vol. 13, 1986, pp. 533-549.
Gosavi, A., “A reinforcement learning algorithm based on policy iteration for average reward: empirical re-
sults with yield management and convergence analysis.” Mach Learning, vol. 55, no. 1, 2004, pp. 5-29.
Gosavi, A., Simulation-Based Optimization: Parametric Optimization and Reinforcement Learning. Kluwer
Academic Publishers (now Springer), 2003.
Gosavi, A., Bandla, N., & Das, T., “Airline seat allocation among multiple fare classes with overbooking,”
IIE Transactions, vol. 34, no. 9, 2002, pp. 729-742.
Gross, D. and Harris, C. M., Fundamentals of Queueing Theory, Wiley Inter-science, 3rd edition, 1998.
Hansen, P. “The steepest ascent mildest descent heuristic for combinatorial programming,” In Conference
on Numerical Methods in Combinatorial Optimisation, Capri, Italy, 1986.
Hewiit, M.R., Chacosky, A., Grasman, S. E., and Thomas, B. W., “Integer Programming Techniques for
Solving Non-Linear Workforce Planning Models with Learning.” European Journal of Operational
Research, vol. 242, no. 3, 2015, pp. 942-950.
Hillier, F. S. and Hillier, M. S., Introduction to Management Science, 3rd edition, McGraw-Hill, 2008.
Hillier, F. H. and Lieberman, G. J., Introduction to Operations Research, 9th edition, McGraw-Hill, 2010.
Hillier, F. S. and Hillier, M. S., Introduction to Management Science, 4th edition, McGraw-Hill, 2010.
Holland, J. H., Adaptation in Natural and Artificial Systems. Ann Arbor, MI: University of Michigan Press,
1975.
Howard, R. A. Dynamic Programming and Markov Processes, The M.I.T. Press, 1960.
Kharoufeh, J., Solo, C., and Ulukus, M. Semi-Markov models for Degradation-Based Reliability. IIE
Transactions, vol. 42, 2010, pp. 599-612.
Kingman, J. F. C., “On Queues in Heavy Traffic.” Journal of the Royal Statistical Society. Series B (Methodo-
logical), vol. 24, no. 2, 1962, pp. 383-392.
Kirkpatrick, S., Gelatt, C. D. and Vecchi, M. P., “Optimization by simulated annealing.” Science, vol.
220, no. 4598, 1983, pp. 671-680.
Law, A. M. and Kelton, W. D., Simulation Modeling and Analysis, Third Edition, McGraw Hill, 2000.
Littlewood, K., “Forecasting and control of passenger bookings.” In Proceedings of the 12th AGIFORS (Air-
line Group of the International Federation of Operational Research Societies) Symposium, pp. 95-117, 1972.
129
Engineering Management Handbook

Marchal, W. G., “An approximate formula for waiting time in single server queues,” AIIE Trans, vol. 8,
1976, p. 473.
Medhi, J., Stochastic Models in Queueing Theory, 2nd edition, Academic Press, 2002.
Merton, R., “Theory of Rational Option Pricing,” Bell Journal of Economics and Management Science, vol.
4, 1973, pp. 141-183.
Nodem, F., Kenne, J., and Gharbi, A. “Simultaneous Control of Production, Repair/Replacement and
Preventive Maintenance of Deteriorating Manufacturing Systems.” Int. J. Production Economics, vol.
134, 2011, pp. 271-282.
Pham, D. T. and Karaboga, D., Intelligent optimisation techniques. Springer, 2000.
Ross, S. M., Introduction to Probability Models, Ninth Edition. Academic Press, 2006.
Sethi, S. P., and Thompson, G. L., Optimal Control Theory. Kluwer Academic Publishers (now Springer),
2000.
Smoluchowski, M. Zur kinetischen Theorie der Brownschen Molekularbewegung und der Suspensionen,
Annalen der Physik, 21, 1906, pp. 756-780.
Spall J. Multivariate stochastic approximation using a simultaneous perturbation gradient approximation.
IEEE Trans. Automat. Contr., vol. 37, no. 3, 1992, pp. 332-34.
Subramaniam, J. Stidham, S., and Lautenbacher, C., “Airline yield management with overbooking, can-
cellations and no-shows,” Transportation Science, vol. 33, no. 2, 1999, pp. 147–167.
Sutton, R. and Barto, A., Reinforcement Learning: An Introduction, Cambridge MA: MIT Press, 1998.
Szepesvari, C., Synthesis Lectures on Artificial Intelligence and Machine Learning: Algorithms for Reinforce-
ment Learning. Morgan & Claypool Publishers, 2010.
Teradata. TROVE Predictive Data Science - Revenue Protection Application. http://www.teradata.com/
brochures/TROVE-Predictive-Data-Science-Revenue-Protection-Application. Accessed August 19,
2015.
Tomasevicz, C. and Asgarpoor, S., “Optimum Maintenance Policy Using Semi-Markov Decision Process-
es,” Electric Power Systems Research, vol. 79, 2009, pp. 1286-1291.
The Institute for Operations Research and the Management Sciences (INFORMS) Website: http://www.
informs.org/
The International Federation of Operational Research Societies (IFORS) Website: http://www.ifors.org/
Van der Duyn Schouten, F. A., and Vanneste, S. G., “Maintenance optimization of a production system
with buffer capacity.” European Journal of Operational Research, vol. 82, 1995, pp. 323-338.
Watkins, C. J. C. H. Learning from Delayed Rewards. PhD Thesis, Cambridge University, Cambridge,
England, 1989.
Wamba, S., Akter, S., Edwards, A., and Chopin, G. “How ‘Big Data’ Can Make Big Impact: Findings
From a Systematic Review and a Longitudinal Case Study.” International Journal Production Econom-
ics, vol. 165, 2015, pp. 234-246.
White, M., Digital Workplaces: Vision and Reality. Bus. Inf. Rev. vol. 29, no. 4, pp. 205-214, 2012.
Wong, W. K., Qi, J. and Leung, S. Y. S., “Coordinating supply chains with sales rebate contracts and
vendor-managed inventory,” International Journal of Production Economics, 2009.

130
 Simulation

10
Simulation

Andreas Tolk
The MITRE Corporation

131
Engineering Management Handbook

10.1 Introduction
10.1.1 Importance of Simulation
Engineering Management bridges the gap between technical engineering processes and necessary
administration and management processes. As such, engineering managers should be aware of devel-
opments that are happening in the technical domain as well as of possible support on the management
side. Modeling and architecture methods have been in the scope of the body of knowledge for EM
from its beginning, as models and architectures belong to the main tools of communication adminis-
trative and management needs in order to support technical solutions. With simulation, another logical
element is added to the toolbox of engineering managers: models executed over time! Modeling, archi-
tecture, and simulation are connected in this chapter to support EM twofold. First, they are interpreted
as a new category of quantitative tools and methods supporting EM. Second, they are increasingly the
object of EM knowledge when applied as methods and tools in projects. Both aspects are important for
EM, as the engineering manager needs to understand the formalisms, methodologies, and technology
applied in order to utilize simulation in projects for which he or she is responsible. He or she needs to
understand the technical engineering process of simulation as well as the administrative and manage-
ment processes required for simulation.
The general importance of simulation for engineering was featured among other publications in the
2006 NSF Report on “Simulation-based Engineering Science.” This report showed the potential of using
simulation technology and methods to revolutionize the engineering science. Among the reasons for the
steadily increasing interest in simulation applications are the following:
• Using simulations is—as a rule—cheaper and safer than conducting experiments with a prototype of
the real thing. One of the biggest computers worldwide is currently designed in order to simulate the
detonation of nuclear devices and their effects in order to support better preparedness in the event of
a nuclear explosion. Similar efforts are conducted to simulate hurricanes and other natural catastro-
phes.
• Simulations can often be even more realistic than traditional experiments, as they allow the free con-
figuration of environment parameters found in the operational application field of the final product.
Examples are supporting deep water operation of the NAVY or the simulating the surface of neigh-
bored planets in preparation of NASA missions.
• Simulations can often be conducted faster than real time. This allows using them for efficient if-then-
else analyses of different alternatives, in particular when the necessary data to initialize the simulation
can easily be obtained from operational data. This use of simulation adds decision support simulation
systems to the tool box of traditional decision support systems.
• Simulations allow setting up a coherent synthetic environment that allows for integration of simulat-
ed systems in the early analysis phase via mixed virtual systems with first prototypical components to
a virtual test environment for the final system. If managed correctly, the environment can be migrated
from the development and test domain to the training and education domain in follow-on life-cycle
phases for the systems (including the option to train and optimize a virtual twin of the real system
under realistic constraints even before first components are being built).

Especially for the engineering manager it is of particular interest that simulation starts to replace
traditional experiments on a significant scale. The trend is most obvious in the military domain, but is also
deeply rooted in industry traditionally using computer aided design, such as the automobile industry.
Model-based design using virtual prototypes in realistic synthetic environments starts to emerge as a new
engineering method.
Another domain of interest is executable architectures. System architectures, as blueprint standards for
complex systems, are an excepted tool. However, most of the current system architecture frameworks do
not fully support the evaluation of the dynamic behavior of a system, as the artifacts used in these frame-
works deliver more or less snapshots of the systems. However, software tools increasingly offer the option
to “execute” a blueprint. This execution of a system’s architecture is a special case of applying the princi-
ples of simulation, as the execution of an architecture de facto simulates is functionality. This application
132
 Simulation

requires EM knowledge in the disciplines of system architecture and modeling as well as in simulation.
The tight connection between systems engineering processes, support system architecture artifacts, and
simulation methods has been dealt with in detail by Tolk and Hughes (2014).
As a result, simulation systems will be increasingly applied as tools in more and more engineering
domains and require to be managed. Although the general domain of information systems is supported
by good practices including those, documented in textbooks, such as Fuller, Valacich, and George (2008),
simulation systems are more than just huge information systems requiring special knowledge by those
who have to manage them over their complete life cycle. As models are purposeful abstractions of reality,
and simulation systems are executed models via information systems, an additional layer of complexity is
added to the information system challenge. In other words, Modeling & Simulation (M&S) opens a new
challenging field for EM.
In summary, M&S is a new way of understanding the interaction among parts of a system and the
systems as a whole. Simulations allow engineers to dynamically change design decisions and immediately
see the consequences. They can evaluate alternatives and options without creating risks or expensive pro-
totypes. The level of understanding of complex systems supported by M&S surpasses most other disci-
plines. The U.S. Congress recognized the contribution of M&S technology to the security and prosperity
of the United States and recognized M&S as a National Critical Technology in its House Resolution 487 in
July 2007. All these points motivate the inclusion of simulation as a chapter into this book.

10.1.2 Key Terms of Simulation

Every scientific discipline needs to establish a set of community-wide agreed key terms in order to for-
mulate its body of knowledge in a coherent and concise manner. This is also the case for M&S. The
application-oriented nature of this emerging discipline, however, sometimes results in the challenge, that
the supported application domains themselves already have vocabularies in place that are not necessarily
aligned between disjunctive application domains. This problem is comparable to the challenges of system
architectures, where engineers face the same challenge. The terms introduced here are based on curricula
definitions of these terms as captured in newer textbooks for M&S education, in particular Sokolowski
and Banks (2008, 2010) and Yilmaz and Oren (2008).
Modeling and Simulation can both be understood at least as sub-disciplines by themselves. Modeling is
the purposeful abstraction of reality. These abstractions take place on several steps, starting with the high-lev-
el conceptualization of the real-world referents (the system or part of the real world that should be modeled)
and resulting in coding decisions for the final implementation. The resulting artifacts must be captured in
formal specifications of the conceptualization. Robinson (2008) defined the conceptual model as “a non-soft-
ware specific description of the simulation model that is to be developed, describing the objectives, inputs,
outputs, content, assumptions, and simplifications of the model.” Simulation is the execution of such a
model. The simulation can be executed by hand, using physical models, and so on. In the context of this
chapter, the focus lies on computer-based simulation. They can be written in general-purpose languages or in
special simulation languages; or they can utilize configuration interfaces of high-level simulators.
If the execution is done in parallel on several computers that may be spatially distributed, this be-
comes a distributed simulation. If a distributed simulation is based on several different simulation sys-
tems (using different underlying models), each simulation is referred to as a federate within a simulation
federation. There are several simulation standards for distributed simulation. Simulation and simulation
federations can be executed stand-alone or integrated into operational systems. For integrated systems, the
application of system-of-systems engineering is good practice and topic of ongoing research.
The body of knowledge for M&S identifies three simulation paradigms: Monte-Carlo simulation,
discrete event simulation, and continuous simulation. All three will be dealt with in more detail in this
chapter. It will be shown that these paradigms are not mutually exclusive, but they are often used in mixed
forms to solve engineering problems in the real world.
Simulation already is a critical component of many application domains. Although traditionally the mili-
tary domain was the driving force behind standardization and applications for training, education, and even
operational support, other domains are becoming equally important: medical applications, transportation,
133
Engineering Management Handbook

business, manufacturing, social sciences, and more. Whenever the term complex system can be applied, it is
likely that simulation applications are used to understand the behavior of this complex system better.

10.1.3 Simulation Theory for Engineers

Engineers in general and engineering managers in particular need to understand the theory of simulation
in order to understand the valid range of applicability of simulation-based tools as well as to understand
the challenges of managing simulation applications. There is a significant overlap with other disciplines, in
particular operations research. On the one hand, simulation is often used as an additional powerful means
of operations research. Mathematical descriptions of systems that cannot be solved mathematically can
still be used to define the model for a simulation system enabling the engineer to gain insight into the sys-
tem dynamics and generally the system behavior. Heuristics can be applied and sensitivity analysis can be
conducted. On the other hand, simulations are also often used to produce quasi-heuristic data that needs
to be evaluated by traditional means of operations research. In any case, the tight connection between
both disciplines is obvious.
The theory of simulation described in this chapter is divided into five categories. These five categories
have been identified as the core aspects engineers and engineering managers must know when they want
to apply simulation within their projects and maybe subject to change and additions over time, but they
have been successfully used in engineering focused curricula development.
The first category builds the mathematical foundations with focus on probability and random
numbers that are essential for stochastic modeling approaches. The second category builds computer
science foundations. There are several simulation languages and frameworks allowing students without a
strong computer science background to utilize simulation methods as well, but some basic understand-
ing in algorithms and data structures generally used in programming are essential to fully understand
and utilize simulation. The third category deals with the theory of discrete event simulation, which is
the predominant simulation paradigm in the engineering domain. Category four deals with the prin-
ciples of data analyses needed for evaluation of results. Finally, the last category deals with Monte-Carlo
simulation and continuous simulation as the two additional simulation paradigms of special interest to
engineers.
The objective of these contributions is to enable EM students to understand the theoretic foun-
dations of simulation in order to enable them to manage their development and application within
engineering projects and to be aware of potential and constraints of using simulation applications
within his area of expertise. They should be able to write small simulation applications in a higher pro-
gramming language, and should be able to set up a statistically meaningful simulation experiments and
evaluate the results.

10.1.4 Simulation Applications for Engineers

Although understanding the theoretic foundations is necessary, the predominate interest of engineering
is to contribute to solutions by applying scientifically derived knowledge to solve real-world problems.
The simulation applications are therefore an important part that comprises three categories.
The first category describes simulation as an engineering method. This category relies on best practices
on how to successfully use simulation in engineering projects. The second category focuses on simulation
with ARENA. The main point is not to introduce a tool, but to focus on the engineering application using
the tool as an example. The statistical experimentation design is an important aspect of this section. Final-
ly, agent-based modeling is introduced in the third category. Individual agents and multi-agent systems are
discussed and their application is shown.
The objective of these contributions is to give examples for simulation applications for engineers.
Student will not be experts in simulation applications, but will understand the principles in all three
categories and will know how to apply the theory they learned in the first section in support of their
engineering tasks.

134
 Simulation

10.1.5 Simulation Engineering

Finally it must be pointed out that simulation in the context of this chapter is clearly perceived as an
engineering discipline. This does not exclude experience, heuristics, creativity, and the art of simulation,
but the emphasis of this chapter is on methods and engineering principles supporting the development
and application of simulations to solve engineering problems. As such, we focus on simulation as a tool in
support of the engineer.
In addition, simulation systems are perceived as “virtual” systems that require the same rigor in de-
sign, development, test, and application traditional systems need. Therefore, EM for virtual systems and
systems of systems is in the scope as well, although this topic is emergent and topic of current research.
In summary, simulation should be of high interest to every engineer due to its increasing practical
relevance in projects and growing management demands within this professional support. The use of sim-
ulation in a project can positively influence schedule, performance, costs, and risks of engineering proj-
ects, if applied and managed correctly. This chapter outlines the topics each engineering manager should
be aware of when utilizing simulation for engineering.

10.1.6 Modeling and Simulation as a Discipline

Several universities are increasingly offering not only courses, but also degrees in Modeling and Simula-
tion. Pioneers in these efforts were the Old Dominion University in Norfolk, VA, the Naval Postgraduate
School in Monterey, VA, and the University of Central Florida in Orlando, FL. Simulation societies are
supporting these efforts, in particular the Society for Modeling and Simulation (SCS) and the Special
Interest Group on Simulation of the Association for Computing Machinery (ACM SIGSIM).
The idea behind the curricula is to identify common principles and insights that allow to derive appli-
cable methods and solutions that lead to solutions in the various application domains. This should foster
reuse and dissemination of research results to the benefit of simulation users in all application domains.
Figure 10.1 shows the important components as discussed by Padilla, Diallo, and Tolk (2011).

Figure 10.1. Modeling and Simulation as a Discipline

EM is the art and science of planning, organizing, allocating resources, and directing and controlling
activities that have a technological component. As engineering managers are responsible for recommend-
ing the best available engineering solutions, they have to understand this new technology and the under-
lying epistemological foundations of simulation.

135
Engineering Management Handbook

To be able to do this, a sufficient knowledge in the domain of modeling and simulation is needed.
Kossiakoff and Sweet (2002) defined the role of a systems engineer in major system development projects
as bringing specialist together that are characterized by different fields and disciplines with his or her own
languages, experiences, and knowledge bases. The systems engineer needs to ensure that these diverse track
converge in support of developing and producing a new system. Similarly, the role of the engineering
manager dealing with simulation is to bridge the virtual worlds of simulation and the engineering world
to allow successful application of modeling approaches and simulation systems to minimize negative en-
vironmental effects, either by avoiding unnecessary experiments and prototypes that could be supported
by virtual systems, or by decision supports for the real system under development by clearly analyzing and
communicating environmental challenges.

10.2 Simulation Theory

10.2.1 Mathematical Foundations
One of the main applications for simulation in industry is to formulate a stochastic model to describe a
real phenomenon. In order to use mathematics to analyze a situation using simulation, probability models
are needed. One of the major elements in this probability models is the use of random number exhibiting
required characteristics. In order to use the model, such random numbers must be generated for applica-
tions within the simulation. This section will introduce the main ideas of probability, random numbers,
and how they can be generated. Among other valuable resources, these topics are well covered in Ross
(2006), chapters 2 to 5. They are also explained in Kelton, Sadowski, and Sturrock (2007), chapter 12.
A handbook chapter can never replace required in-depth studies of the referenced domain, and in the
case of probability, this is definitely the case. Each applicant of simulation must be aware of the principles
of probability in order to use simulation systems effectively. Even if the simulation system itself is deter-
ministic, the simulation results may reflect elements of probability if statistical experimentation planning
is used. This section can therefore be no more than a list of “things to know” and is a starting point or a
checklist for the engineering manager.
Several key terms need to be defined in order to deal with probability. Probability is always need-
ed when the outcome of an experiment is not known in advance or uncertain. The set of all possible
outcomes is the sample space. Each subset of this sample space is an event. For any event we define the
complement of this event as all events that are in the sample space but not in the event. Two events are
mutually exclusive if there are no outcomes that are a subset of both events. With these definitions, the
three axioms of probability can be formulated.
For each event A in a sample space S we denote the probability of A as P(A) in accordance with the
following three axioms of probability:

Axiom 1: 0 ≤ P( A) ≤ 1

Axiom 2: P( S ) = 1

Axiom 3: For any sequence of mutually exclusive events A1, A2, …

 n  n
P  Ai  = ∑ P( Ai ) , n = 1, 2, …, ∞
 i =1  i =1

These axioms can be used to proof a variety of results about probabilities and are the basis for stochas-
tic modeling.
Of particular interest for simulation applications are furthermore conditional probability and indepen-
dence. Conditional probability is defined as the probability that event A is observed under the condition that
event B occurs. As we know that B occurred, B becomes the new sample space for the conditional probabil-

136
 Simulation

ity. The events comprised in the conditional probability value must furthermore satisfy A and B, hence we
need the probability of AB relative to the probability of B, so that the conditional probability is denoted by

P( AB)
P( A | B) = .
P( B)
Following similar ideas, we define that two events A and B are independent if P ( AB ) = P ( A) P ( B ) .
It can be seen that formulas for independent events are much easier to compute and preferred for simula-
tion, but not for the sake of correctness and accuracy. The engineer must therefore know which events are
independent and which events were assumed to be independent when the model for the simulation was
developed.
Within simulation, the probability is often only a means used to specify the value of some numerical
quantity determined by the result of an experiment. Such numerical quantities are defined as random vari-
ables. Random variables can be discrete or continuous. If they are discrete, the overall probability can be
determined by adding the single probability values. If they are continuous, intervals are needed that define
the probability density function.
Three of the most useful concepts in probability often used for simulation are the expectation of a
random variable, the variance of a random variable, and the covariance of two random variables. The
expected value is the weighted average of the possible values a random variable can take on weighted by the
probability that the random variable assumes this value (or the integral over the random variable interval
weighted by the probability density function). The variance measures the variation around the expected
value by considering the average value of the square of the difference between the expected value and the
observed value. The covariance measures the degree of similarity between two random variables by con-
sidering the expected value of the difference between the observed value and the expected value of the
first random variable multiplied by the difference between the observed value and the expected value of
the first random variable. The correlation is a very similar measure to the covariance, but the correlation
has no dimension, as the covariance is divided by the square root of the product of the variances of both
random variables.
Ross (2006) introduced some selected discrete random variables that are useful for many simulation
applications, such as
• Binomial random variables: n independent events with two possible outcomes (yes/no, success/no
success, etc.) with equal probability. If we are interested in one successful outcome (n=1), we are
talking about Bernoulli random variables. This category of random variables is important for statisti-
cal significance testing.
• Poisson random variables: They are used to approximate the distribution of successes in a large num-
ber of trials. They are also used to count the number of events that occur in a certain time interval.
• Geometric random variables: If a series of n independent trials with the same probability p is con-
n −1
ducted, these variables can be used to compute the overall success probability by p (1 − p ) . Many
simulation applications make use of these variables.

Most software development environments provide the user with a function called random or similar
that returns a pseudorandom number. One of the most common approaches to generate pseudorandom
numbers is to start with an initial value, called the seed, and then computing successive values by letting

xnext = axcurrent mod m

where mod is the modulo function and a and m are positive integers. This procedure generates values
within the interval [0, 1, …, m-1] and is an approximation to the value of a uniform (0, 1) random
variable. It is obvious that this is not a real random number, as the next upcoming number is completely
determined by the formula and the series of numbers will repeat itself as soon as one number is repeated
(which must happen at least after m executions).
137
Engineering Management Handbook

Once the user is able to generate uniform random variables, he or she can apply well-established meth-
ods to transform them into other random variables with known distributions (defined by the probability
mass function for discrete random variables and the probability density function for continuous random
variables). For discrete random variables, the inverse transform method is often used. For continuous
random variables, the inverse transform algorithm is used. Both methods follow the same basic idea that
can be explained best using the following figure. The graph shows the probability mass/density function
of the targeted distribution. Both methods use a uniform (0, 1) random variable to generate a random
number (1), determine where this event “hits” the desired accumulated probability mass/density function
(2), and than determine which value corresponds this value on the desired random value scale (3) as shown
in Figure 10.2.

Figure 10.2. Visualization of the Principle of the Inverse Transform Method/Algorithm

Desired
Probability
Mass/density
function
Uniform (0,1) random variable

1 2

0
min 3 max

Random variable with desired distribution

Ross (2006) describes both, the inverse transform method and algorithm, in detail and gives more
established methods for special distributions. The interested engineering manager is referred to the refer-
ences for more detailed introductions.
For engineering managers, the current work on establishing a common general understanding of sim-
ulation theory based on common principles formulated in mathematical model theory can be of addition-
al interest (Diallo, Padilla, Gore, Herencia-Zapana and Tolk, 2014).

10.2.2 Computer Science Foundations

In order to understand simulations, it is highly recommended to be able to understand and write algo-
rithms in a higher programming language, such as Java or C++. In the application section, we will deal
with special simulation languages that are an alternative to general purpose programming languages;
however, as it is necessary to understand the foundations of probability before being able to apply a
statistics tool efficiently, it is necessary to understand the foundations of programming to understand
simulation programs.
Computers execute instructions. A computer program is a list of instructions including all necessary
input data. An algorithm is an instruction-by-instruction procedure to solve a problem, such as ordering a
set of numbers in ascending order, find the fastest way connecting two points, etc.

138
 Simulation

The list of instructions is normally executed in sequential order, if this order is not modified using
control flow statements that exist in all programming languages in one form or another. There are five
categories of control flow statements: halt, choice, loop, jump, and subroutines that are defined as follows:
• Halt statements stop the execution flow immediately and prevent any additional actions.
• Choice statements execute a set of statements only if certain criteria are met. The most common
choice statement is the conditional statement of the form
IF condition THEN instruction.
• Loop statements allow to repeat a set of statements for a given number or as long as a condition is
true. Some of the most common loop statements are
REPEAT instruction UNTIL condition;
WHILE condition DO instruction;
FOR enumerator DO instruction.
• Jump or go-to statements go directly to a specified instruction in the program. This instruction is
often labeled to make the reference easier. One of the most common jump statements is
GOTO label.
• Subroutines execute a set of instructions after which they potentially return to the calling instruction.
Subroutines are normally called with a set of input parameters, such as
SubroutineName (InputParameterList).

Beside these control structures, a certain commonality of data structures can be found in all program-
ming languages as well. The basic or primitive data item types are integer numbers, real or float numbers,
and characters or strings. Often, the numbers are distinguished in long and short primitives, where long
primitives require more storage space within the computer but also have a higher accuracy or bigger
range. When two or more primitive data item types are composed into a new data item, they build a com-
posite type. Primitive and composite types can be stored in ordered form, e.g., in lists and trees. Lists and
trees are ordered collections of data items. Lists can be indexed allowing to access a certain element (these
lists are often called array or vector), or they may only allow access to the first and/or last element of the
list. When data structures and procedures working on these data are combined into a common construct,
this is called an object (and the procedures are called methods). Many books have been published in the
domain of data structures and algorithms that are normally used in undergraduate programs of computer
sciences education. It is good practice to search for collaboration with a local college offering education in
this domain.
The EM body of knowledge enumerates the introduction to basic of Java or C++ as an important
component. This topic alone fills books and each attempt to introduce these languages in a handful
of sentences must be futile. Instead, the interested reader is referred to standard computer science
literature as well as web sites offering introduction tutorials and overviews. In particular Java is
supported by an active and competent online user community, such as http://java.sun.com and other
websites.

10.2.3 Discrete Event Simulation

While the mathematical and computer science foundation sections build the broad basis, discrete event
simulation basics are the first topic that aims at the need of engineering managers looking specifically for
simulation education.
Discrete event simulation is one of the simulation paradigms. It models a system as it evolves over time
as a series of system states. At discrete times, events occur that change the state of the system—or the state
of a system component—instantly. In other words, discrete event simulation simulates events and state
changes of the system connected with these events in chronological order. In order to be able to do so, the
events must be stored and delivered in the right order. For this purpose, the simulation system uses at least
one event list—or event queue— which stores events until they occur and distributes them when they are
needed. Furthermore, a representation of time—a simulation clock—is needed that determines together
with a time advance algorithm what timestamp is used to label the events and when and how to progress in
139
Engineering Management Handbook

time. In particular for distributed simulation system, where events can be produced in remote procedures,
the synchronization of several event lists is an issue requiring time management.
There are two principle approaches for time advance: fixed time steps and variable time steps. Figure
10.3 exemplifies both approaches. It shows discrete time steps tn, tn+1, and tn+2 that occur at predefined
fixed points on the time scale, and the time stamps of three events te1, te2, and te3.

Figure 10.3. Time Advance in Discrete Event Simulation

Event 1 Event 2 Event 3

te1 te2 te3 time

tn tn+1 tn+2

If a next-event time advance method is used, the time advance starts with the first event in the event
list (event 1) and uses the time stamp of this event to set the simulated time (te1). The system state con-
nected with event 1 occurs, and the next event is request from the event list.
If a fixed time advanced method is used, the time advance goes from time tn straight to tn+1. It the
requests all events with a time stamp smaller or equal to tn+1; in the example, this are the events 1 and 2.
When all events that fulfill this criterion are computed, the next time step is made to tn+2. In what order
the events are computed is due to the implementing details, as the events principally are aggregated into
one event composite that comprises all events that are happening in the interval within the current fixed
time step.
In both cases, an event may lead to the creation of a new event in the future. In this case, a new event
is created, the parameters of the event are calculated, the timestamp for this event is calculated, and the
event is handed over to the event list manager to be included at the right place. Challenges the simulation
developer faces are those cases where the timestamp of the new event potentially lies in the past of the
current simulated time. If in the example above a fixed time step approach is chosen, and event 1 creates
a new event with a timestamp smaller then that of event 2, this may cause problems if the resulting state
change caused by the new event is important for the computation of the correct effect of event 2.
If the simulation systems are distributed, the necessity for time management arises, as the different
simulation clocks must be synchronized. One possibility is to use real-time, but this creates two challeng-
es: (a) when a simulation is computation intensive, it may be too slow to be able to run in real time; (b)
when a simulation is very fast, the computation resources are idle most of the time. The same problem
occurs when two simulation systems have to be synchronized, as the faster simulation has to wait for the
slower simulation. Therefore, several different time management approaches have been designed, such
as conservative synchronization—only continue simulation when all simulation systems reached the same
time point—and optimistic synchronization—faster simulation may continue their work, but must be
prepared to roll back in case of need.
A good introduction to discrete event simulation in comparison to the alternative simulation para-
digm of continuous simulation is given in Sokolowski and Banks (2008), chapter 3. For advanced simula-
tion engineers it is recommended to evaluate the Discrete Event System Specification (DEVS) by Zeigler,
Praehofer, and Kim (2000). DEVS one of the most rigorous simulation formalism and well rooted in
engineering principles. It has been applied in many engineering contexts and is internationally applied on
a broad basis.
140
 Simulation

10.2.4 Data Analysis

It is very interesting that in practical application a lot of effort goes into the development of simulation
systems, but how to evaluate the simulation results is often neglected. The development of a hierarchy of
measures of merit should be included in every simulation project. The development of operational, user
driven definition of the measures, the development of instruments or definition of access points in the
simulation, the application of these instruments or use of these access points to collect the appropriate
data, and the establishment of relationships between the different forms of measure need to be agreed by
the user of the simulation system, the managers of the project, and the simulation engineers responsible
for the simulation. As these efforts are likely to vary in difficulty, costs, requirements for precision and
accuracy, and other characteristics, engineering management is challenged to established best practices for
their simulation applications.
It is common to distinguish measures of performance (MOP) and measures of effectiveness (MOE). MOP
focuses more on internal contributing components while MOE evaluates the system as a whole. Both measure
categories rely on the availability of the appropriate data. As it has been recognized that a single definition for
MOP and MOE does not exist, the term measures of merit (MOM) is often used to generalize the ideas. An
alternative term for MOM is figures of merit. Engineering managers are used to this form of analysis require-
ments, as it can be directly mapped to the objectives hierarchy used in systems architecture and modeling.
Once the access to the required data and their use for the agreed MOM is established, the resulting
data can be analyzed following the principles for output data analysis, such as described in Ross (2006),
chapters 7 and 8. The techniques that are essential for engineering applications of simulation recognized
as best practice are statistical analysis, variance reduction techniques, and sensitivity analyses.
The statistical analysis should at least result in means and variances and related interval estimates.
This is well known from operational research methods where these analysis methods are used typically to
evaluate the stability of optimization solutions. The difference to traditional operations research is simply
that the data is produced by a simulation system. For the engineer, the view of a simulation as a comput-
er-based statistical sampling experiment is beneficial: Whatever is applicable and necessary for other statisti-
cal sampling experiments is applicable and necessary for simulation result evaluation as well.
Furthermore, variance reduction techniques fall into this category. However, while statistical analysis
targets to increase the knowledge gained from a simulation experiment, variance reduction techniques are
normally applied for improving the speed and efficiency of a simulation by intelligently choosing simula-
tion runs that contribute to better estimates. The underlying view of a simulation system is that we utilize
the performance measures by which the system is to be judged (the MOM), and parameters that may be
adjusted to improve the system performance. The objective of variance reduction techniques is helping to
find best combinations used for these parameters to maximize the knowledge gained by simulation runs.
Finally, sensitivity analysis evaluates the stability of a recommended solution. Generally, sensitivity
analysis helps to track how variations in the input parameters of a simulation system trigger variations in
the output parameters. For many practical problems, a solution that is stable within the region of un-
certainty or accuracy of the input parameters is preferred to a better solution that is unstable. Sensitivity
analysis is therefore closely related to uncertainty analysis that answers the question: how certain is a given
solution, or in which confidence intervals is the proposed solution can be applied without becoming
invalid. In particular when simulation systems are used in support of decision-making, these questions are
essential and need to be addressed by the responsible engineering manager.
Simulation is also used to generate quasi-empirical data for data farming. In many domains in which
conducting real-world experiments is too expensive, too dangerous, ethically not justifiable, or simply not
possible, simulation experiments can be a surrogate that provides the data needed to support engineering
managers with the information needed to make the best possible informed recommendation.

10.2.5 Monte-Carlo Simulation and Continuous Simulation

Discrete event simulation as the predominant simulation paradigm has already been introduced earlier.
This section describes the other two simulation paradigms of interest to the engineering manager: Mon-
te-Carlo simulation and continuous simulation.
141
Engineering Management Handbook

• Monte-Carlo simulation uses a deterministic simulation model that maps input parameters to output
parameters. In the standard case, time is not modeled. The simulation model is then used to iterative-
ly evaluate the model by feeding random variables and evaluate the resulting outputs. The statistical
analysis means shall be applied here.
• Continuous simulation models system changes over time, but in contrast to discrete simulation the
system is described for continuous simulation by state variables that change continuously with respect
to time: state changes are not instant events.

Before going into further explanations and examples, some additional simulation foundations need
to be explained. The first is the difference between deterministic and stochastic models. In both cases, a
simulation model is interpreted to map input parameters to output parameters.
• In deterministic models, the same input will always produce the same output. Only if input parameters
are varied, the output parameter will vary.
• In stochastic models, the results when computing the output parameters are determined by using one or
more random variable to represent uncertainty about a process in which a given input will produce an out-
put according to some statistical distribution. Therefore, the same input may result in different outcomes.

Another fundamental concept resulting from stochastic processes is the Markov chain, which is
known to engineering managers from other applications. The characteristic of a Markov chain is that it
operates without memory: the conditional probability of any future event given any past events and the
present state is independent from any past events and only depends on the current state. This makes them
of interest to simulation developers, as it reduces the implementation efforts tremendously as past states
do not need to be tracked in order to compute the possible follow-on events.
Following similar ideas, the Poisson distribution is of particular interest for developers of stochastic
models as well. The basic idea and mathematical foundation was introduced earlier in this chapter: the
Poisson distribution expresses the probability of a number of events occurring in a fixed period of time if
these events occur with a known average rate and independently of the time since the last event. As before
with Markov chains, this insight can facilitate the implementation: if a stochastic process can be approx-
imated by this distribution, the likelihood for an event to happen in the next time step is independent
from its history, so no past states need to be tracked.
The use of Monte-Carlo simulation is quite obvious. It should be pointed out that a Monte-Carlo
model can be part of a discrete event simulation system: whenever a procedure operates on random vari-
ables without advancing the simulation time—such as producing new events, calculating the system state
change, etc.—all techniques supporting Monte-Carlo simulation can be applied. In particular when simu-
lation systems need to be evaluated, or even validated and verified, this can be beneficial. The engineering
manager responsible for such a project needs to be aware of these relations.
Continuous simulation is often used to simulate physical systems or systems that involve mechanical,
electrical, thermal, or hydraulic components. Such systems are most precisely described by differentials
equations. When computed using digital computers, these differential equations need to be transformed
into difference equations, or numerical approximation methods like the Euler method or Runge-Kutta
method need to be applied. This automatically introduces a numerical error, contributing to artificial
variances in the results of the system. It is of critical importance for the engineering manager to be aware
of these approximations and how they are dealt with in the data analysis.
In summary, this section on simulation theory shows that the engineering manager responsible for a
simulation project—be it development or application of a simulation in the engineering context—needs
a solid foundation to align the work of professional in the domains of statistic, computer science, numer-
ic, and M&S. In practice, the engineering manager is often the first of these experts that has access to all
these contributing elements, so he is the experts with the “big picture” of what is going on. The ability to
understand the nature of challenges that can occur in all these contributing domains is therefore essential
to successfully bridge the gap between these contributing experts as well as between technical experts,
management, and the user community.

142
 Simulation

10.3 Simulation Applications

10.3.1 Simulation as an Engineering Method
Simulations are becoming ubiquitous. Related research continuously introduces new and improved
formalisms, methodologies, and simulation tools that are intended to support the new, broader inter-
pretation of engineering. The 2006 NSF Report on “Simulation-based Engineering Science” states that
engineering and science communities have become increasingly aware that computer simulation is an
indispensable tool for resolving a multitude of scientific and technological problems facing our country.
The NSF view on simulation is summarized in the report as follows:
“Computer simulation represents an extension of theoretical science in that it is based on
mathematical models. Such models attempt to characterize the physical predictions or
consequences of scientific theories. Simulation can be much more, however. For example,
it can be used to explore new theories and to design new experiments to test these theories.
Simulation also provides a powerful alternative to the techniques of experimental science
and observation when phenomena are not observable or when measurements are impracti-
cal or too expensive.

“Simulation-Based Engineering Science (SBES) is defined as the discipline that provides the
scientific and mathematical basis for the simulation of engineered systems. Such systems
range from microelectronic devices to automobiles, aircraft, and even the infrastructures of
oil fields and cities. In a word, SBES fuses the knowledge and techniques of the traditional
engineering fields—electrical, mechanical, civil, chemical, aerospace, nuclear, biomedical,
and materials science—with the knowledge and techniques of fields like computer science,
mathematics, and the physical and social sciences.”

The American Society for Engineering Management definition of EM shows that this is a task in their
realm: “Engineering management is the art and science of planning, organizing, allocating resources, and
directing and controlling activities that have a technological component.” This can be mapped directly
to the tasks identified for SBES in the NSF report. To fill this generic task description with applicable
recommendations, best practices are needed.
Simulation systems have a long and successful history in the military domain. They are used in
analysis, procurement, acquisition, training, education, and in some instances even for support of oper-
ations. The North Atlantic Treaty Organizations (NATO) published the NATO Code of Best Practice
(COBP) for Command and Control Assessment in 2002. This code represents over a decade of work
by many of the best analysts from the NATO countries, conducted under the guidance of NATO’s
Research and Technology Organization (RTO). While the original application domain of the COBP
is military command and control, the code was written to give broad guidance on the assessment of
complex systems in complex environments for a wide variety of decision-makers. As such, it comprises
best practices and guidance on how to conduct a scientific study rooted in operations research ideas
on complex systems in complex environments. The COBP is mandated for operations research studies
conducted for the US Department of Defense (DoD) Assistant Secretary Defense (ASD) Networks and
Information Integration (NII).
Recent research work has shown that many traditional project management artifacts can be
mapped to the recommended processes and products documented in the COBP. It has also been
proven to be a valuable guide when conducting simulation-based studies, in particular for the US
Joint Forces Command, in particular when supporting new research requiring increasingly the incor-
poration of geopolitics, culture, religion, and political economy to better understand how Diplomatic,
Intelligence, Military, and Economic (DIME) factors affect military decision-making. A growing area of
research for the Department of Defense is centered on related Political, Military, Economic, Security,
Information, and Infrastructure (PMESII) aspects (for example, see Sokolowski and Banks (2008), chap-
ter 1). To ensure that all relevant information is captured, the NATO COBP recommends an iterative
approach captured in Figure 10.4.
143
Engineering Management Handbook

Figure 10.4. Phases for Conducting a Study as Recommended in the NATO COBP

Problem
Formulation

Solution
Strategy
Sponsor’s
Problem Human &
Organizational
Issues

Measures Methods
Scenarios
of Merit & Tools

Data

Assess
Products Risk

This COBP is organized into four phases. The first phase deals with study dynamics, problem for-
mulation, and the development of a solution strategy. This phase is the initialization phase, in which the
objectives and requirements are analyzed and it is ensured that the sponsor’s problem is understood and
a simulation-based solution is possible. The second phase identifies and discusses in depth the essential
elements of assessment: measures of merit, scenarios, and human and organizational issues. In this prepa-
ration phase, applicable solutions are identified and the selection of best tools is prepared by in-depth
analysis of systems and their environment. This leads to the definition of necessary data and selection of
the best tools. The third phase addresses issues related to risk and uncertainty while the final phase de-
scribes the range of assessment products.
As it is the case in all engineering task, the success starts with understanding the real needs of the
sponsor and the environment in which the support has to be delivered. There may be political, economic,
or even cultural constraints. Once this is understood, the problem formulation activities lead to specifica-
tions on what needs to be solved, and the solution strategy captures how these problems will be solved. The
results are captured in a study plan as well as in a study management plan. These documents can be aug-
mented by additional documents and artifacts supporting better project management, cost management,
and risk management.
Capturing the relevant system information regarding human and organizational issues becomes
increasingly relevant. A system is commonly defined to be a collection of hardware and software,
people, facilities, resources, and procedures organized to accomplish some common objectives. These
aspects must be managed for real systems and modeled in virtual systems. An exhaustive variation of
all parameters defining a solution space is normally not feasible for large and complex challenges. This
can normally only be done for small problems that can be solved by closed mathematical solutions and
not for the type of problems that are addressed by simulation-based solutions. It is therefore essential
to capture operationally relevant scenarios to ensure that relevant parameter combinations are evaluat-
ed. A scenario can be defined as a description of the geospatial constraints, the environment, available
resources, given objectives, past and current relevant events, and all other factors being related to the
system to be evaluated during a specified time frame suited for satisfactory study objectives and the
problem analysis directives. Quite often, the use of smaller vignettes is good practice, in particular for
smaller scenarios and as excursions from the main scenario. Measures of merit have already been dealt
144
 Simulation

with in the theory section. They should be directly linked to the elements of the scenarios and reflect
the solution strategy. It should be pointed out that up to this point all decisions and evaluations have
been made tool independent.
Selection the methods and tools to be applied in the project, including selecting the best simulation
tool, should always be based on these tool independent analysis. It is bad practice to build a study or a
project around a preselected simulation tool, as this automatically limits the focus to “what can the tool
do” instead of answering “what is the sponsor’s problem.” As a rule, the engineering manager should be
able to select an orchestrated set of tools that are able to generate the required MOM and for which the
necessary data can be obtained. It is good practice to include the management of tools selection—in-
cluding simulation systems—and data engineering for obtaining the necessary input data and produce
the required MOM in the management artifacts mandatory for simulation-based projects. Finally, risk
assessment is recommended. Sensitivity analysis, as described earlier in this chapter, is recommended but
not sufficient.
In summary, simulation-based studies and projects require rigorous EM to be successful. Best practic-
es exist that can be of help. However, it is still true that success comes from wisdom, wisdom comes from
experience, and experience comes from making mistakes. Simulation as an engineering method
can give guidelines and avoid obvious traps; but as so often in engineering, there is no golden rule
that ensures success.

10.3.2 Simulation with ARENA

As mentioned before, computer simulations can be written in general-purpose languages or simulation
languages. ARENA is a widely distributed example for using a simulation framework. In general, simulation
languages have become very popular and are often part of operations research curricula. Frameworks support
the user by providing not only a simulation language, but also by providing composable simulation con-
structs that are often supported by intuitive graphical user interfaces. ARENA supports the user with a great
variety of predefined constructs plus the ability to program user-created constructs. In summary, as stated
in various overview papers, the philosophy of this approach is to treat simulation modeling as an in-vitro lab-
oratory that facilitates the understanding of complex systems and experimentation with what-if scenarios in
order to estimate their performance metrics. Figure 10.5 shows a screenshot of executing an ARENA model.

Figure 10.5. Executing an ARENA Model

As shown in the screenshot, building a simulation in ARENA is pretty straightforward: users select
constructs representing the necessary processes or process steps (and users can define such constructs,
145
Engineering Management Handbook

including their graphical representation) and connects the input of following activities with the output of
producing activities. In addition, users can define data collection and visualization capabilities that can be
used to produce statistical data and their display. In addition, ARENA supports several probability distri-
butions. ARENA supports all three simulation paradigms, but the emphasis clearly lies on discrete event
simulation. Trying to give a more detailed introduction in form of a short section would be futile, so the
interested reader is referred the Kelton et al. (2007) for further reading.
Another aspect in the focus of simulation applications for engineers is the statistical experimentation
design. Some simulation frameworks are supporting their users with integrated tools for the definition
of MOM or with predefined procedures supporting data analysis as defined in the theory part of this
chapter. Nonetheless, the overview compiled by Kleijnen (2004) should be known by every engineer that
applies simulations in his or her project. This journal article comprises best practices and theoretic foun-
dations critical for simulation experiment design and completes the recommendations given in Kelton et
al. (2007), chapter 12.

10.3.3 Agent-based Modeling

Agent-based modeling is on the brink to becoming the fourth broadly applied simulation paradigm. As
a metaphor, the use of agents is not new. The availability of necessary computing power and memory for
execution and storage helped this powerful concept to become an emerging branch in simulation. Yilmaz
and Oren (2008) compiled several chapters into a book focusing on agent-directed simulation for systems
engineering. Yilmaz and Oren (2008, chapter 3) gives an overview comprising the important points of
interest to engineers wanting to understand agent-based modeling for engineering applications.
The working definition for an agent as proposed in Yilmaz and Oren (2008, chapter 3) defines agents
by their characteristics as follows:
• The agent is situated, it perceives its environment, and it acts in its environment. The environment
includes typically other agents, other partly dynamic objects, and passive ones, that are, e.g., subject
of manipulation by the agent. The communication with other agents is of particular interest systems
comprising multiple agents, as agents can collaborate and compete for tasks. This later characteristic
has also been referred to as social ability.
• The agent should be autonomous, in the sense that it can operate without the direct intervention of
humans or others and autonomy requires control about its own state and behavior. They must be
guided by some kind of value system.
• To be flexible for an agent means to mediate between reactive behavior, being able to react to changes
in its environment, and deliberativeness to pursue its goals. A suitable mediation is one of the critical
aspects for an agent to achieve its tasks in a dynamic environment. An agent can act upon its knowledge,
its rules, beliefs, operators, goals, and experiences, etc. and adapt to new constraints and requirements—
or even new environments—as required. New situations might ask for new goals, and new experiences
might lead to new behavior rules. Furthermore, being mobile adds to the flexibility of an agent.

The architectural frame shown in Figure 6.5 was proposed in support of discussing how the agent
characteristics enumerated above can be realized. It is kept simple on purpose, as it is not intended to
prescribe a solution but to make developers aware of domains that need to be taken into account.

146
 Simulation

Figure 10.6. Architectural Frame Addressing Main Agent Characteristics

Information
Exchange
with other Agents

Communications

Situated Environment
at objects in the
Input from the

Action directed
Environment

Perception

Sense Decision
Situated

Action
Making Making

Memory

Adaptation

There are three external and four internal architectural domains identified. The external domains
comprise those functions needed by the agent to interact with and to act within his environment. The
internal domains categorize the functions needed for the agent to act and adapt as an autonomous object.
• Perception: The agent has to receive input from the situated environment and map it to his or her
internal structures.
• Communications: The agent needs to exchange information with other agents based on an agreed
protocol.
• Action: The agent need to move and act in the situated environment.
• Sense making: The agent needs to base his or her decision on a fused awareness of what he or she
perceives, what he or she communicates, and what he or she knows. To enable autonomy, the agent
needs a sense-making domain.
• Memory: The knowledge of the agent must be accessible to the agent. It may have several compart-
ments, such as short- and long-term memory, earlier decisions, pattern, etc.
• Adaption: Flexibility requires that rules and memories can be changed to reflect new recognized cir-
cumstances.
• Decision-making: Situational awareness leads to a desired outcome and related steps. These steps can
be decided on one at a time or in form of a complex plan. The decision-making domain enables this.

When such agents are used to populate a simulation, in particular when these agents do not all sup-
port the same view but are heterogeneous regarding the way they perceive, make sense, communicate, and
decide, the result is a multi-agent system. These systems have been successfully applied in many domains.
In particular the characteristics of autonomy and flexibility make them of interest to engineers, as they
enable to add human-like behavior to simulations (life sciences and political sciences have been among
the pioneers of agent-based simulation applications) as well as system’s learning and adaption of systems
to new environments (e.g., it has been discussed if systems’ functionality cannot be provided by system
agents that observe and adapt continuously to new situations). Again, this is a topic of current research.
Figure 10.7 summarizes the characteristics.

147
Engineering Management Handbook

Figure 10.7. Agents, Environment, and Societies

Agent System

Agent Situated Agent

Characteristics Environment Society

Accessible vs. Large scale vs.

Perception
Non-Accessible few Agents

Deterministic vs. Cooperative vs.

Decision Making
Stochastic Non-cooperative

Episodic vs. Homogeneous vs.

Communication
Sequential Heterogeneous

Static vs. Open society vs.

Action
Dynamic non-open society

Discrete vs.
Continuous

Similar to compiling the characteristics of agents into architectural domains, the characteristics of
contributing agents, the situated environment, and the agent society can be compiled into taxonomical
domains. The overview is neither complete nor exclusive, but it summarizes the core domains the engi-
neering manager must be aware of when applying multi-agent systems.

10.3.4 Simulation and Systems Engineering Methods

An emergent application domain for simulation is the support of system engineers in better understand-
ing complex systems and system of systems. The role of simulation systems can be manifold:
• Simulations are used as serious games educating managers and technicians in a secure but immersive
environment.
• Simulations provide the foundation for what-if-analyses of alternatives: each option can be simulated
and the results can be compared using the established operations research methods. This may even
lead to simulation based optimization.
• Simulations allow executable architectures: system architecture artifacts are used to define simulation
components that act like the specified systems. This allows to bring one or many simulated systems of
a portfolio together in a common synthetic environment to test the possible solution before a system
has to be build.
• Simulations are used as fully controlled and adaptable test beds for systems. In particular when
requirements are used to derive measures and metrics for the acceptance of a system, test cases can be
directly used to specify simulations providing the necessary parameters to stimulate the system under
test accordingly.
• Simulations are used to be executed in parallel to the controlled system: at specified times or events,
the observations are compared with the predications of the simulation. If the variance between ex-
pected and observed status becomes too big, additional control or a new decision is needed.

Of particular interest is furthermore the support of systems engineering and system of systems engi-
neering by simulation applications. The observation of emergence in such systems has been the topic of

148
 Simulation

concern, as engineered systems should not expose unspecified behavior that may defeat the system’s pur-
pose, as discussed by Osmundson et al. (2008). Emergence can be reproduced in particular in agent-based
simulations. Looking into agent-based methods to better understand emergence and potentially becoming
able to engineer positive emergence into systems is a topic high on current research agendas. The increas-
ing number of autonomous systems in various application domains of interest to the engineering manager
also requires a better understanding of potential and limits of simulation, as the intelligent behavior of
autonomous systems is constrained by the same epistemological and computational frontiers as simulation
systems. The engineering manager must know these limitations. A good overview of such limits has been
compiled by Oberkampf et al. (2002). A view on simulation from the perspective of philosophy of science
has been provided by Tolk (2015).
To summarize this chapter on simulation it should be obvious that applying simulation in and for
engineering projects is challenging and requires a solid education. It showed M&S within the supporting
disciplines including probability and statistics, computer science, systems modeling and architecture, and
operations research. It introduced discrete event simulation, Monte-Carlo simulation, and continuous
simulation as the simulation paradigms, and it mentioned M&S methodologies and application domains.
The sections of this chapter cannot replace the referenced literature—which needs to be completed with
experience to lead at the end to good decisions. However, the core knowledge references in this chapter
will enable engineering managers to have a good start and will prepare them with tools and methods for
solving real-world problems and challenges when using simulation for and in engineering.

10.4 References
Diallo, Saikou Y., Padilla, Jose J., Gore, Ross, Herencia-Zapana, Heber, and Tolk, Andreas, “Toward a for-
malism of modeling and simulation using model theory,” Complexity, vol. 19, no. 4, 2014, pp. 56-63.
Fuller, Mark, Valacich, Joe, and George, Joey, Information Systems Project Management – A Process and
Team Approach. Pearson Prentice Hall, 2008.
Kelton, David, Sadowski, Randall, and Sturrock, David, Simulation with Arena, McGraw-Hill Science/
Engineering/Math, 2007.
Kleijnen, Jack, An overview of the design and analysis of simulation experiments for sensitivity analysis.
European Journal of Operational Research, vol. 164, no. 2, July 2004, pp. 287-300.
Kossiakoff, Alexander, and Sweet, William N., Systems Engineering Principles and Practice. John Wiley &
Sons, 2002.
National Science Foundation (NSF) Blue Ribbon Panel, Report on Simulation-Based Engineering Science:
Revolutionizing Engineering Science through Simulation, NSF Press, May 2006.
NATO Research and Technology Organization (RTO), NATO Code of Best practice for C2 Assessment,
Command and Control Research Program (CCRP) Press, 2002.
Oberkampf, William. L., DeLand, Sharon M., Rutherford, Brian M., Diegert, Kathleen V., and Alvin,
Kenneth F., “Error and uncertainty in modeling and simulation.” Reliability Engineering & System
Safety, vol. 75, no. 3, 2002, pp. 333-357.
Osmundson, John S., Huynh, Thomas V., and Langford, Gary O., “Emergent Behavior in Systems of
Systems,” INCOSE International Symposium, vol. 18, no. 1, 2008, pp. 1557-1568.
Padilla, Jose J., Diallo, Saikou Y., and Tolk, Andreas, “Do We Need M&S Science?” SCS M&S Magazine,
vol. 2, no. 4, 2011, pp. 161-166.
Robinson, Steward, Conceptual modelling for simulation Part I: definition and requirements. Journal of
the Operational Research Society, vol. 59, 2008, pp. 278-290.
Ross, Sheldon, Simulation (4th edition). Academic Press, 2006.
Sokolowski, John and Banks, Catherine (Editors), Principles of Modeling and Simulation: A Multidisciplin-
ary Approach. John Wiley & Sons, 2008.
Sokolowski, John and Banks, Catherine (Editors), Modeling and Simulation Fundamentals: Theoretical
Underpinnings and Practical Domains. John Wiley & Sons, 2010.
Tolk, Andreas, Simulation. Engineering Management Body of Knowledge. American Society of Engineering
Management, vol. 1.1, Nov. 2007.
149
Engineering Management Handbook

Tolk, Andreas, Learning Something Right from Models That Are Wrong: Epistemology of Simulation. In
Concepts and Methodologies for Modeling and Simulation, Springer International Publishing, 2015,
pp. 87-106.
Tolk, Andreas, and Hughes, Taylor K., Systems engineering, architecture, and simulation. Modeling and
Simulation-Based Systems Engineering Handbook, CRC Press, 2014, pp. 11-41.
Yilmaz, Levent, and Oren, Tuncer (Editors), Agent-Directed Simulation and Systems Engineering, John
Wiley & Sons, 2008.
Zeigler, Bernard, Praehofer, Herbert, and Kim, Tag Gon, Theory of modeling and simulation: Integrating
discrete event and continuous complex dynamic systems - second edition, Academic Press, 2000.

150
 Decision Analysis

11
Decision Analysis

Gregory S. Parnell
University of Arkansas
and Innovative Decisions Inc.

151
Engineering Management Handbook

11.1 Introduction
11.1.1 What is Decision Analysis?
Decision analysis is an operations research technique for analyzing complex decisions with multiple
(and usually conflicting) objectives and uncertainty. One of the founders of the field, Ronald Howard,
first coined the name in 1964. Decision analysis uses the axioms of probability and utility theory and
the philosophy of systems analysis (Howard, 1966). The first decision analysis book (Raiffa, 1968),
used probability and a single objective, net present value. The first multiple objective decision analy-
sis book was published in 1976 (Keeney & Raiffa). Decision analysts use probability to model their
belief in the likelihood of each outcome of an event based on our state of information. They use Bayes
law to update beliefs as they learn new information. In addition to the mathematical foundations of
decision theory, decision analysts have adopted lessons from behavioral decision theory research about
the heuristics and biases people use to reason with uncertain information and make decisions (Clemen
and Reilly, 2013; Kirkwood, 1997). Decision analysts have used behavioral decision research to develop
effective problem structure, uncertainty, and preference elicitation protocols.

11.1.2 Why Use Decision Analysis?

Engineering managers need to make defensible decisions in a complex technology management en-
vironment when faced with complex alternatives, conflicting objectives of diverse stakeholders, and ma-
jor uncertainties. Engineering managers can use decision analysis for major decisions including R&D
decisions (Matheson and Matheson, 1998), and systems decisions (Parnell, Driscoll, and Henderson,
2008) throughout the system life cycle. The stakeholders include consumers, owners, users, deci-
sion-makers, developers, and maintainers. Typically, engineering managers must consider technology,
safety, economic, organizational, environmental, and emotional factors. In addition, major decisions
sometimes involve important political, historical, cultural, social, and other considerations. Because
most EM decisions impact future products and services, uncertainty can be a major concern. These
uncertainties can create technical, cost, and schedule risks for the organization.

11.1.3 When Do You Use Decision Analysis?

While decision analysis principles can be used for simple decisions, decision analysis is most appro-
priate for the engineering managers’ most complex decisions. Engineering managers typically use
decision analysis to provide fact-based decision information for two types of decisions that have ma-
jor consequences to the organization. The first approach is to use decision analysis to provide infor-
mation at a major program decision milestone. An example would be the decision to select a system
concept for design and development. The second approach is to use decision analysis to provide
information for the major annual investment (e.g., R&D portfolio and capital budgeting) decisions.
An example would be the major development projects to provide the technologies for future prod-
ucts and services.

11.1.4 Who Uses Decision Analysis?

In the past 40 years, there are been a wide variety of decision analysis applications. Few application
articles are published due to proprietary information, classified information, and lack of incentives of
practioners to publish. Good surveys can be found in Corner and Kirkwood (1991); Keefer, Kirkwood,
and Corner (2004); Philips (2007); and Parnell (2007). Decision analysis applications, including the
use of decision analysis with other operations research techniques, are published in a wide variety of
professional journals.
The decision analysis is usually performed by employees of the company, consultants, or a combi-
nation of employees and consultants. Decision analysis education and training are obtained by academ-
ic courses, certification courses, and professional continuing education courses. Large companies that
institutionalize decision analysis, sometimes develop their own internal decision analysis training pro-

152
 Decision Analysis

grams. Many decision analysts belong to the Society for Decision Professionals1 and the Decision Analysis
Society2 of the Institute for Operations Research and Management Science.

11.2 Decision Processes

11.2.1 Challenges
The organizations decisions and the implementation of the decisions ultimately determine the success
of the organization. Decision analysis is a technical field that uses mathematical modeling to help make
sound decisions. However, leaders and key stakeholders need to effectively and efficiently interact to de-
termine and implement the best decisions for the organization.
We can think of decision analysis as a conversation with the decision-maker and key stakeholders.
The conversation is only as good as the people participating. The model structure is the topic of the
conversation. The numbers are used to define the topics and reason about the relevance of the topics. A
well-executed decision analysis emphasizes insight about opportunities and risks.
We have to design the organizational process as well as the decision model. The process should in-
clude the:
• Right people that have broad and deep knowledge
• Right data and information
• Right forum that is conducive to discussion and interaction
• Right balance of modeling and challenging the model with intuition
• Right duration to meet decision deadlines but enable information gathering and socializing the
results.

The Handbook of Decision Analysis provides more details of the decision analysis process. Three de-
cision analysis processes have been successfully used in organizations: the analytical process, the decision
conference process, and the dialogue decision process.

11.2.2 Analytical Process

When the technical (i.e., the complexity of the alternatives and the mathematics of the model) part of the
decision analysis is complex and more critical that the social (i.e., the stakeholder interaction), an ana-
lytical process may be appropriate. Some decisions involve complex, technical issues that can be assessed
with models. The decision-maker provides the initial guidance, the stakeholders provide input, and the
decision analysts build models, collect data, analyze alternatives, and present insights at a decision briefing
attended by the decision maker and the key stakeholders.

11.2.3 Decision Conference Process

When the social part of the decision is more critical than the technical, the decision conference may be
appropriate. Figure 11.1 describes the activities of a decision conference3. The key idea of a decision con-
ference is the shared awareness of the key players to discuss issues, build models to evaluate alternatives,
and explore the results.

1. http://www.decisionprofessionals.com/ accessed August 22, 2015

2. http://decision-analysis.society.informs.org/ accessed August 22, 2015
3. Modified from Phillips, L. D., “Chapter 19: Decision Conferencing,” Advances in Decision Analysis – From Foundations to
Applications, Edwards, W., Miles, R., and von Winterfeldt, D., Cambridge Press, 2007.
153
Engineering Management Handbook

Figure 11.1. Decision Conference

Compare: Gut ⇔ Model

Awareness Key Discuss
of Issues Players Issues

Prepare
- objectives Build
- participants Model
- announcement
Explore
results

Shared Understanding Commitment Action

11.2.4 Dialog Decision Process

When the decision models are complex and stakeholder participation is critical the dialog decision process
may be appropriate. The dialog decision process uses regular interaction opportunities for the decision
team to “dialog” with the decision makers and key stakeholders. Figure 11.2 shows the concept of the dia-
log decision process4. The frame is the fundamental structure that we use to view the problem. The values
are the customers’ objectives and preferences. The alternatives are options to be evaluated. The evaluation
is the decision analysis and the insights.

Figure 11.2. Dialog Decision Process

Decision Makers

Decision
Frame Values Alternatives
Evaluation

Decision Team

4. Modified from Spetzler, C., “Building decision competency,” Advances in Decision Analysis – From Foundations to Applica-
tions, Edwards, W., Miles, R., and von Winterfeldt, D., Cambridge Press, 2007.

154
 Decision Analysis

11.2.5 Advantages and Disadvantages of Decision Processes

Table 11.1 summarizes the advantages and disadvantages of each of the three processes. The table also
identifies the individuals performing the analytical role. The analytical process is most useful for when
detailed models are required and decision-makers are confident that the analysts will not lose focus on the
problems. Decision conferences are most useful when the model can be done in real time and the partici-
pation of key stakeholders in essential. The dialog decision process is most useful when the models require
significant development time but key stakeholder participation is essential to commitment to implement
the solutions.

Table 11.1. Advantages and Disadvantages of Decision Processes

Analytical Approach Decision Conference Dialog Decision Process

Analytical role Analyst team Facilitators Decision team/Design team

High confidence you are solving the High confidence you are solving
right problem the right problem
May be appropriate for
well-framed problems All participants develop common un- Planned involvement of key de-
derstanding and shared commitment cision-makers and stakeholders
Detailed analytical models
Advantages developed Develop and use requisite decision at major decision points
models that use the essential infor- More analytical models of val-
Least time demand on mation to distinguish between the
decision-makers and alternatives ues and uncertainty
stakeholders Less time demand (several
Multiple conferences can support short meetings)
hierarchical decision-making
Analysts can lose focus
on the evolving views Must schedule all key players for same
of decision-makers and time Requires scheduling periodic
stakeholders meetings with key players
Disadvantages Time commitment of managers and
Models may become stakeholders (days) Key stakeholder availability
overly complex and data collection challenges
If needed, complex models must be between dialog points
Lack of stakeholder par- developed before the conference
ticipation and data

11.3 Decision Elements

11.3.1 Values and Outcomes
Values are what we care about in the decision-making process. Decision analysts try to identify the al-
ternatives that have the best probability of providing outcomes that will meet our values and objectives.
Keeney (1992) suggests we should start a decision-making process by identifying the values and objectives
that we are trying to achieve with the decision(s). This is more difficult than it seems. Keeney’s recent
research has shown that people can only identify about half of their final objectives in the initial meeting
and that they may not initially identify the objectives that they will assign the most importance.

11.3.2 Uncertainty
Engineering managers make decisions about products and services for future consumers and customers.
There are many uncertainties involved in EM. Four of the most common are technical (how well with the
technologies work), cost (how much will it cost), schedule (when will it be delivered), and market (what
will be the future demand). However, sources of uncertainty can include all elements of the decision en-
vironment including safety, economic, organizational, environmental, and emotional factors. In addition,
major decisions sometimes involve important political, historical, cultural, and social uncertainties.

155
Engineering Management Handbook

11.3.3 Decisions
Engineering managers make decisions about the best products and services to develop and market to cus-
tomers and consumers. The most difficult decisions involve decision strategies that combine many decision
elements including partnerships, technologies, production plans, supply chain, marketing, and logistics.

11.4 Decision Modeling—Illustrative Product Development Example

11.4.1 Basic Influence Diagram
The influence diagram (Howard and Matheson, 2005) is a useful decision modeling technique that helps
us identify the decision elements and their interrelationships. We will use DPL software to illustrate our
influence diagrams and decision trees5. While an influence diagram solution algorithm exists (Clemen
and Reilly, 2013), we will use influence diagrams to model the decision problem and decision trees solve
for the best decision and obtain insights. Other decision analysis software is also available to perform a
decision analysis (Patchak, 2014).
We will use an influence diagram to consider an illustrative product development example. The influ-
ence diagram in Figure 11.3 identifies the decisions (squares), uncertainties (circles) and values (rounded
squares). The two sequential decisions are to develop a new product and produce a new product. The
arrow denotes that we have to develop the new product before we can produce the new product. If we
produce the new product, the market success is uncertain. The arrow denotes that the uncertain variable
market success depends on whether we produced the product. Finally, our net present value depends on
development cost, production cost, and sales (market success). We can see that the major benefit of the
influence diagram is that it helps identify the key variables and their interrelationships in a picture and
encourages us to develop the details needed for the analysis later.

Figure 11.3. Basic Influence Diagram

Market
Success

Develop Produce Net

New New Present
Product Product Value

11.4.2 Basic Decision Tree

In order to decide if we should develop and produce the new product, we need to know the relevant cost
and market data. Suppose our current product is expected to provide a net present value of sales of $35M.
However, the product development group wants to develop a new product (development cost is $10M)
that has the following potential sales: -$20M in a low market, $50M in a nominal market, a $100M in a
high market. The marketing department assesses the following probabilities: 0.3 for low market, 0.4 for
nominal market, and 0.3 for high market. Figure 11.4 shows a decision tree using this information.

5. DPL is decision and risk analysis software developed by Syncopation Software. http://www.syncopation.com/ accessed August
22, 2015.
156
 Decision Analysis

Figure 11.4. Basic Decision Tree

Low [-30]
Market Success 30% -20
Produce New Product Yes [34] Nominal [40]
Develop New Product Yes [34] 40% 50
[35] -10 High [90]
30% [100]
No [25]
35
No [35]
35

The decision tree uses the following steps. First, all the values are calculated for the end nodes of the tree
(triangles) for each path through the decision tree. There are five paths in Figure 11.4. Starting at the bottom
and working up, the first path is not to develop and the NPV is $35M. The second path is to develop but
not produce for NPV of $25M (35 minus the development cost of 10). The third path has NPV of 90
(100-10). Likewise, the fourth and fifth paths are $40M and -$30M, respectively. The second step is to start
at the end nodes and solve the decision tree using the “Average Out-Roll Back” Algorithm, which calculates
expected values at uncertain nodes and selects the highest NPV at decision nodes. For example, the expected
value at market success of 34 (0.3*(-30) + 0.4*(40)+0.3*(90)) and at the produce new product node, the best
decision is Yes since 34 > 25. Finally, the develop new product decision is No since 35>34.

11.4.3 Basic Risk Profile

Risk is the probability of a bad outcome. One of the important decision analysis displays is the NPV
cumulative probability distribution, sometimes called the cumulative risk profile. Figure 11.5 shows the
cumulative risk profile for our basic decision. The higher expected value alternative (No development) has
significantly less risk. We can see that the no development decision has a value of $35M with probability
1.0, which means we assume no uncertainty. The Yes decision (Develop and Produce) has a probability of
0.3 of -$30M, a probability of 0.4 of $40M and a probability of 0.3 of $90M (expected value of $34M).
The major risk is the 0.3 probability of losing $30M.

Figure 11.5. Basic Cumulative Risk Profile

So far, this seems like an easy decision, select the highest expected value and the lowest risk.

157
Engineering Management Handbook

11.4.4 Value of a Test

One of the obvious weaknesses of our analysis is that we have not considered using a development test to
see if the new product design will meet the market needs. The influence diagram with the addition of the
development test is shown in Figure 11.6. The new node and the three new arrows each have meaning.
The arrows mean that if we develop the new product, we can do the development test; the results of the
test are known before the production decision; and the development test results are used in the calculation
of NPV.

Figure 11.6. Influence Diagram with Test

Market
Success

Develop Produce Net

New New Present
Product Product Value

Development
Test

We assume the test can be a success (0.9) or fail (0.1). If the test succeeds the market success will be as
modeled in section 11.4.2. However, if the test fails the NPV will be 0.
Figure 11.7 shows our new decision tree with the test. Information has value only if the decision chang-
es. The test changed the decision and increased the expected value from $35M to $36M in spite of the
$1M cost of the test. The highest expected value is to develop the new product and produce the product
if the test is a success and not produce if the test fails. The cost of the test is an important factor, if the test
cost $3M, the expected value of the develop option would have been $34M and it would have been better
to not develop the new product. If the test has been free, our expected value would have been $37M.
Because our expected value without the test was $35M, we would pay up to $2M for the test.

Figure 11.7. Decision Tree with Test

Low [-31]
Market Success 10% -20
Produce New Product Yes [37] Nominal [39]
Success [37] 80% 50
90% -1 High [89]
Development Test
10% [100]
Develop New Product Yes [36]
No [24]
[36] -10
35
Market Success
Produce New Product Yes [-11]
Failure [24]
10% -1 No [24]
35
No [35]
35

In addition to the $1M increase in expected value, the test has reduced the risk from a 0.3 probability
of losing $30M to a 0.09 probability (0.9*0.1) of losing $31M. This can be seen by calculating the prob-
ability of the top path through the decision tree in Figure 11.7. Of course, it would also be easy to see in
the cumulative risk profile.

158
 Decision Analysis

11.4.5 Value of Imperfect Information about Market Success

In the previous section, we examined the value of a test. We can also consider the value of imperfect infor-
mation about the market test. In Figure 11.8, we add a market survey uncertainty node to our influence
diagram and three arrows. The arrow from develop new product to market survey means the market sur-
vey is done only if we develop the new product. The arrow from market success to market survey means
that the probabilities assigned the market survey outcomes depend on the outcome of market success. The
arrow from market survey to produce new product means that the market survey results will be known
before the produce new product decision.

Figure 11.8. Influence Diagram with Test and Market Survey

Market
Market Success
Survey

Develop Produce Net

New New Present
Product Product Value

Development
Test

Suppose we have a market survey with the following data on the left side of Figure 11.9. We are given
the prior probability distribution on the market success and the likelihood distributions on the on the
probability of the survey prediction given the market success outcome. The likelihood distribution is a
quantitative statement about the ability of the market survey to predict the true market outcome. In the
decision tree, we need the preposterior distribution (the probability of the prediction) and the posterior
distribution (the probability of market success given the market survey prediction). Figure 11.9 shows
the standard probability calculations on the middle and right side. We enter the prior and likelihood into
DPL and the software calculates the preposterior and posterior distributions.

Figure 11.9. Probability Calculations

Prior Likelihood Joint probability Preposterior Posterior

Predict Low l Low Low l Predict Low

0.7 0.21 0.66

Low Predict Nominal l Low Predict Low Nominal l Predict Low

0.3 0.2 0.06 0.32 0.25

Predict High l Low High l Predict Low

0.1 0.03 0.09

Predict Low l Nominal Low l Predict Nominal

0.2 0.08 0.17

Nominal Predict Nominal l Nominal Predict Normal Nominal l Predict Nominal

0.4 0.6 0.24 0.36 0.67

Predict High l Nominal High l Predict Nominal

0.2 0.08 0.17

Predict Low l High Low l Predict High

0.1 0.03 0.09

High Predict Nominal l High Predict High Nominal l Predict High

0.3 0.2 0.06 0.32 0.25

Predict High l High High l Predict High

0.7 0.21 0.66

1.0 3.0 1.0 1.0 3.0

159
Engineering Management Handbook

Figure 11.10 shows the decision tree with the test and the market survey. We have assumed that the
development test and the market survey are done concurrently. The expected value has increased signifi-
cantly from 36 to 49M. The market survey changes the best decision strategy. If the test is a success, we
only produce the new product if the market survey predicts nominal or high.

Figure 11.10. Decision Tree with Test and Market Survey

Low [-22]
Market Success
66% -20
Produce New Product Yes [7] Nominal [48]
Predict Low [33] 25% 50
32% -1 High [98]
9% [100]
No [33]
35
Low [-22]
Market Success
17% -20
Market Survey Produce New Product Yes [45] [48]
Nominal
Success [50] Predict Nominal [45] 67% 50
90% -1 36% -1 High [98]
17% [100]
No [33]
35
Low [-22]
Development Test Market Success
Produce New Product 9% -20
Yes [49] Yes [74] Nominal [48]
Develop New Product Predict High [74] 25% 50
[49] High [98]
32% -1
66% [100]
No [33]

Market Success
Produce New Product Yes [-2]
Predict Low [33]
No [33]
32% -1
35
Market Success
Market Survey Produce New Product Yes [-2]
Failure [33] Predict Nominal [33]
36% -1 No [33]
10% -1
35
Market Success
Produce New Product Yes [-2]
Predict High [33]
32% No [33]
-1
35
No [35]
35

Another interesting benefit of the market survey is the reduction in risk. With the market survey, the
worst case risk is now -22M (versus -30M), which occurs with a probability of 0.08 (versus 0.09).
We know from this analysis that the market survey costing $1M resulted in an expected value of
$49M. Had the test been free, our expected value with the market survey would have been $50M. There-
fore, we know that the maximum we should pay for this market survey would be $13M (50 – 37).

11.4.6 Value of Perfect Information About Market Success

Market managers may want to know how much they should pay for a better market survey. Decision ana-
lysts use the expected value of perfect information to assess the maximum we would pay for any information.
The value of perfect information can be calculated three ways. The first way is to change the probabil-
ities in Figure 11.9 (and Figure 11.10) to have the survey perfectly predict the outcomes. The second way
is to delete the market survey node and put the market success as the first node in the tree. The third way
is to have DPL calculate the expected value of perfect information using the tree in Figure 11.10. All three
ways result in an expected value of perfect information of 56. This means that given we have the test and
market survey would be 7M (56 - 49).

160
 Decision Analysis

In addition to an increased expected value, perfect information would significantly reduce the risk to
a worst case outcome of 33M (35 – 2 for the test and survey). However, this outcome would occur with
probability 0.37.

11.4.7 Value of Control

Although the value of perfect information assesses the expected value of knowing the outcome of a vari-
able, it does not change the probabilities assigned to the outcomes. As we have seen, a market survey is an
example of obtaining information on a probability distribution.
The value of control is another important decision analysis concept. Advertising is a common
marketing tool to control the market outcome. The value of perfect control assumes we can
change the variable to its best outcome. Therefore, the expected value of perfect control would tell
us the maximum we would pay for marketing to make the demand be the highest outcome in our
distribution.
In our basic decision tree, the expected value with perfect control was $90M. Therefore, the expected
value of perfect control was $55M (90 – 35). One of the principles is that the expected value of perfect
control is always greater than or equal to the expected value of perfect information. Intuitively, this means
that we would rather control the outcome of a variable to it best outcome than know which outcome has
occurred.

11.4.8 Sensitivity Analysis

Because our data is seldom perfect, it is useful to consider how sensitive we are to our assumptions. We
say a variable is sensitive if a value in the range of interest would cause us to change our decision. Decision
analysis software allows us to perform sensitivity analysis to one or more parameters.

11.4.9 Comparison of Influence Diagrams and Decision Trees

The two major modeling tools we have used in this section are influence diagrams and decision trees.
As we have noted, the same model can be solved for the same answer using both tools but the algo-
rithms are different. The two tools are complementary. The influence diagram is very useful for mod-
eling the problem structure and capturing the relationships between variables. A complex problem
can effectively be understood with an influence diagram. The decision tree is useful for displaying
the mathematics of the modeling assumptions and showing the best solution strategy on the decision
tree algorithm has been completed. Large decision trees are difficult to understand without careful
study.

11.5 Single Attribute Utility

11.5.1 Utility
In the previous section, we used net present value as our single objective. In addition, we used the ex-
pected value to compare alternatives and the cumulative risk profile to assess the risk. If we were going to
make a thousand similar decisions the expected value would be wonderful criteria since we would expect
to get 1,000 times the expected value! However, some decisions are only one time decisions. An alter-
native approach is to use a utility function (Clemen and Reilly, 2013; Kirkwood, 1997) to capture our
returns to scale and our risk preference. Two exponential utility functions (top and bottom) and a linear
utility function (middle) are shown in Figure 11.11.

161
Engineering Management Handbook

Figure 11.11. Three Utility Functions

1
0.9 Risk Adverse
Risk Neutral
0.8
Risk Seeking
0.7
0.6
Utility u(x)

0.5
0.4
0.3
0.2
0.1
0
0 1 2 3 4 5 6 7 8 9 10
X

11.5.2 Risk Preference

Utility functions are assessed by asking questions about lotteries, e.g., would you rather has $5M with
probability 1.0 or a 50/50 chance of $10M or $0. If we would take less than $5M, say $4M, we are risk
adverse (see curve in Figure 11.11) and we say that we would we pay a risk premium of $1M (expected
value of $5M – the $4M) to avoid the risk. Buying life insurance is an example of typical risk adverse
behavior. We pay a premium to hedge against the risk to our families. If we are indifferent, we are ex-
pected value decision makers. If we would pay more than $5M, say $6M, we are risk seeking and the risk
premium is -$1M ($5M – 6M). An example of risk seeking behavior is gambling in Las Vegas. Clearly,
the house adjusts all games so our risk premium is negative (the house is favored to win). Otherwise, they
could not make a profit.

11.5.3 Utility with Decision Trees

One of the nice features of utility is that decision trees work equally well with utility as the end nodes of
tree. We can use our “average out – roll back” algorithm to calculate expected utility. Also, we can perform
value of information, value of control, and sensitivity analysis exactly like we did with net present value.

11.6 Multiple Objective Decision Analysis (MODA)

11.6.1 Additive Value Model
In many decision problems we have other objectives besides net present value and we choose not to
convert all objectives to dollars. Multiple objective decision analysis uses many mathematical equations
to evaluate alternatives. The simplest and most commonly used model is the additive value model (Kirk-
wood, 1997). This model uses the following equation to calculate each alternative’s value:

n
where v ( x ) = ∑ wi v i ( xi )
i =1

v(x) is the alternative’s value

i = 1 to n is the number of the value measure

xi is the alternative’s score on the ith value measure
162
 Decision Analysis

vi(xi) = is the single dimensional value of a score of xi

wi is the weight of the ith value measure

n

and ∑w
i =1
i = 1 (all weights sum to one)

The additive value model has no index for the alternatives we’re evaluating because our values do not
depend on the alternative. We use the same equations to evaluate every alternative.

11.6.2 Value Functions

Value functions measure returns to scale on the value measures. They have four basic shapes: linear, con-
cave, convex, and an S-curve (Figure 11.12). The linear value function has constant returns to scale: each
increment of the measure is equally valuable. The concave value function has decreasing returns to scale:
each increment is worth less than the preceding increment. The convex value function has increasing
returns to scale: each increment of the measure is worth more than the preceding increment. The S-curve
has increasing, then decreasing, returns to scale on the measure.
We have several techniques to develop value curves from subject-matter experts. Our first step is to
have the experts determine the shape of the value curve: linear, concave, convex, or S-curve. Next, we use
value increments to identify several points on the curve—asking experts the relative value of increments in
the value measure scale.

Figure 11.12. Four Types of Value Functions

0.9 Linear
Concave
0.8
Convex
0.7 S-Curve

0.6
V(x) [Value]

0.5

0.4

0.3

0.2

0.1

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
x [ Value Measure]

11.6.3 Swing Weights

Weights play a key role in the additive value model. MODA quantitatively assesses the trade-offs between
conflicting objectives by evaluating the alternative’s contribution to the value measures (a score converted
to value by single-dimensional value functions) and the importance of each value measure (weight). The
163
Engineering Management Handbook

most common mistake in MODA is assessing weights based on importance only (Parnell et al., 2013).
The weights depend on the value measure scales’ importance and range. If we hold constant all other value
measure ranges and reduce the range of one of the measure scales, the measure’s relative weight decreases,
and the weight assigned to the others increases since the weights add to 1.0.

11.6.4 Swing Weight Matrix

The swing weight matrix (Parnell et al., 2013) defines what we mean in the decision context by the im-
portance and range of variation for the value measures. The idea of the swing weight matrix is straightfor-
ward. A measure that is very important to the decision should be weighted higher than a measure that is
less important. A measure that differentiates between alternatives, that is, a measure in which value mea-
sure ranges vary widely, is weighted more than a measure that does not differentiate between alternatives.
The first step is to create a matrix (Table 11.2) in which the top defines the value measure importance and
the left side represents the range of value measure variation. The levels of importance and variation should
be thought of as constructed scales that have sufficient clarity to allow the analyst to uniquely place every
value measure in one of the cells. A measure that is very important to the decision and has a large vari-
ation in its scale would go in the upper left of the matrix (cell labeled A).6 A value measure that has low
importance and has small variation in its scale goes in the lower right of the matrix (cell labeled E).

Table 11.2. Elements of the Swing Weight Matrix

Importance of the value measure to the decision

Factor to
Critical Important
Consider
Range of Large A B2 C3
variation of the
value measures Medium B1 C2 D2

Small C1 D1 E

Consistency Rules
Because many individuals may participate in the assessment of weights, it is important to ensure consis-
tency of the weights assigned. It is easy to understand that a very important measure with a high variation
in its range (A) should be weighted more than a very important measure with a medium variation in its
range (B1). It is harder to trade off the weights between a very important measure with a low variation in
its range (C1) and an important measure with a high variation in its range (B2). Weights should descend
in magnitude as we move on the diagonal from the top left to the bottom right of the swing weight
matrix. Multiple measures can be placed in the same cell with the same or different weights. If we let the
letters represent the diagonals in the matrix A, B, C, D, and E, A is the highest weighted cell, B is the next
highest weighted diagonal, then C, then D, and then E. For the swing weights in the cells in Figure 7.1 to
be consistent, they need to meet the following relationships:
• Any measure in cell A must be weighted greater than measures in all other cells.
• Any measure in cell B1 must be weighted greater than measures in cells C1, C2, D1, D2, and E.
• Any measure in cell B2 must be weighted greater than measures in cells C2, C3, D1, D2, and E.
• Any measure in cell C1 must be weighted greater than measures in cells D1 and E.
• Any measure in cell C2 must be weighted greater than measures in cells D1, D2, and E.
• Any measure in cell C3 must be weighted greater than measures in cells D2 and E.
• Any measure in cell D1 must be weighted greater than measures in cell E.
• Any measure in cell D2 must be weighted greater than measures in cell E.
• No other strict relationships hold.

164
 Decision Analysis

If we denote i to be the label of the cell in the swing weight matrix and fi to be the unnormalized
swing weight of the value measures in each cell, then the following strict inequalities relationships of
non-normalized swing weights must hold:
fA > fi for all i in all other cells
fB1 > fC1, fC2, fD1, fD2, fE
fB2 > fC2, fC3, fD1, fD2, fE
fC1 > fD1, fE
fC2 > fD1, fD2, fE
fC3 > fD2, fE
fD1 > fE
fD2 > fE

No other specific relationships hold.

Assessing Un-normalized Swing Weights

Once all the value measures are placed in the cells of the matrix, we can use any swing weight technique
to obtain the un-normalized weights as long as we follow the consistency rules previously cited. In assign-
ing weights, the stakeholders need to assess their tradeoffs between level of importance and level of varia-
tion in measure scale. One approach would be to assign the measure in cell A (the upper left corner cell)
an arbitrary large unnormalized swing weight, for example, 100 (fA = 100). Using the value increment
approach (Kirkwood, 1997), we could assess the weight of the lowest weighted measure in cell E (the low-
er right corner) the appropriate swing weight, for example, 1. This means the swing weight of measure A
is 100 times more than that of measure E. It is important to consider what the maximum in cell A should
be. Common choices are 1000 and 100. Of course fE can be other numbers besides 1. If we use 100 and
1, we have three orders of magnitude. If we use 1000 and 1 we have four orders of magnitude. Using a
value increment approach, un-normalized swing weights can be assigned to all the other value measures
relative to fA by descending through the very important measures, then through the important measures,
then through the less important measures.

Calculating Normalized Swing Weights

We can normalize the weights for the measures to sum up to 1 using the following equation:
fi
wi = n
,
∑f
i =1
i

where fi is the un-normalized swing weight assessed for the ith value measure, i = 1 to n for the number of
value measures, and wi are the normalized swing weights from Equation 1.
MODA examples can be found in Kirkwood, 1997, Parnell, Driscoll, & Henderson, 2011, Parnell et
al., 2013, and Clemen and Reilly, 2013.

11.6.5 Multiple Objective Decision Analysis with Decision Trees

One of the nice features of MODA is that decision trees work equally well with multiple objective value
at the end nodes of tree. We can use our “average out – roll back” algorithm to calculate expected multi-
ple objective value. Also, we can perform value of information, value of control, and sensitivity analysis
exactly like we did with net present value and utility.

11.7 Role of Engineering Manager

The engineering manager plays a key role in the decision analysis process. First, the engineering manager
must determine the most appropriate decision process (Section 11.2) for the type of decision, the organi-
165
Engineering Management Handbook

zation, and the leadership styles of organizational decision-makers. Second, the engineering manager must
ensure that all key stakeholders participate in the process. Third, innovative alternatives are considered
that have the potential to create high value for the organization. Fourth, the engineering manager must
ensure that all relevant uncertainties and risks have been considered. Finally, the engineering manager and
the leadership team must ensure that the solutions are implementable. Having early stakeholder participa-
tion in the decision analysis helps to ensure the solutions are implementable.

11.8 Advanced and Other Topics

This chapter covered the fundamentals of decision analysis for engineering managers. Section 11.9 and
specifically Table 11.3 provides references and a mapping of all of the topics to two standard references in
the field. The third column in the table lists advance material that is not covered in this chapter.

11.9 References
Clemen, R., Making Hard Decisions, 2nd Edition, Duxbury Press, 1996.1
Corner J. L. and Kirkwood, C. W., “Decision Analysis Applications in the Operations Research Literature,
1970-1989,” Operations Research, vol. 39, no. 2, pp. 206-219, March-April 1991.
Howard, R. A., & Abbas, A. E., Foundations of Decision Analysis. Prentice Hall, 2015.
Howard, R. A. and Matheson, J. E., Editors, The Principles & Applications of Decision Analysis, 1983, Vol-
umes I & II, Strategic Decisions Group.
Keefer, D. L., Kirkwood, C. W., and Corner, J. L. Perspective on Decision Analysis Applications, 1990–
2001, Decision Analysis, vol. 1, no. 1, pp. 5-24, March 2004.
Keeney, R. L. Value-Focused Thinking: A Path to Creative Decision Making. Cambridge, Massachusetts:
Harvard University Press, 1992.
Keeney, R. L. and Raiffa H. Decision Making with Multiple Objectives Preferences and Value Tradeoffs. New
York: Wiley, 1976.
Kirkwood, C. W., Strategic Decision Making: Multiobjective Decision Analysis with Spreadsheets, Belmont,
California: Duxbury Press, 1997.2
Matheson, D. & Matheson, J., The Smart Organization: Creating Value Through Strategic R&D, Harvard
Business School Press, 1998.
Patchak, William, M., “Decision Analysis Software Survey,” OR/MS Today, October 2014 [Biannu-
al survey of DA software] https://www.informs.org/ORMS-Today/Public-Articles/October-Vol-
ume-41-Number-5/Decision-Analysis-Software-Survey, Accessed August 22, 2015.
Parnell, G. S., Driscoll, P. J., and Henderson D. L., Editors, Decision Making for Systems Engineering and
Management, Wiley Series in Systems Engineering, Andrew P. Sage, Editor, Wiley & Sons Inc., 2008.
Parnell, G. S., Value-Focused Thinking Using Multiple Objective Decision Analysis, Methods for Conducting
Military Operational Analysis: Best Practices in Use Throughout the Department of Defense, Military
Operations Research Society, Editors, A. Loerch & L. Rainey, pp. 619-656, 2007.
Parnell, G. S., Bresnick, T. A., Tani, S. N., and Johnson, E. R. Handbook of Decision Analysis, John Wiley
& Sons, 2013.
Phillips, L. D., “Chapter 19: Decision Conferencing,” Advances in Decision Analysis – From Foundations to
Applications, Edwards, W., Miles, R., and von Winterfeldt, D., Cambridge Press, 2007.
Raiffa, H. Decision Analysis: Introductory Lectures on Choices Under Uncertainty, Addison-Wesley Publish-
ing Co., 1968.
Spetzler, C., “Building decision competency,” Advances in Decision Analysis – From Foundations to Applica-
tions, Edwards, W., Miles, R., and von Winterfeldt, D., Cambridge Press, 2007.

166
 Decision Analysis

The following are two standard references in this field. The following table maps the topics in this chapter
to these references.
1. Clemen, Robert T. and Reilly, T., Making Hard Decisions: An Introduction to Decision Analysis, 2nd
Edition, Duxbury Press, 2013.
2. Kirkwood, Craig W., Strategic Decision Making: Multi-objective Decision Analysis with Spreadsheets,
Duxbury Press: Belmont, CA, 1997.

Table 11.3. Topics Referenced to Standard Texts in the Field

Advanced
References 1 2
Material
Authors C&R K
I Introduction X X
II Elements of Decision Analysis X X
A Decision Context X X
B Values and Consequences X X
C Decisions X X
D Uncertain Events X X
E Alternative-Focused Thinking and Value-Focused Thinking X
III Structuring Decisions X X
A Value Hierarchies X X
B Means Objectives X X
C Influence Diagram X
C Decision Trees X X
E Comparison of Influence Diagrams and Decision Trees X
F Sequential Decisions X
G Time Value of Money X
H Cash Flows and Probabilities X
IV Decisions with Single Objectives - Value X X
A Decision Tree Example with Expected Monetary Value X X
B Influence Diagram Example with Expected Monetary Value X
C Risk Profiles X
D Dominance X
V Decisions with Multiple Objectives - Value X X
A Objectives, Attributes,Value Measures, and Scores X X
B Types of Value Measures X
C Value Functions X X
D Importance Weights and Swing Weights X X
E Additive Value Model X X
F Decisions with Uncertain Scores X
G Decision with Uncertain Events and Uncertain Scores X X
H Mathematical Foundations of Multiattribute Value X A
VI Sensitivity Analysis X X
A One Way Sensitivity X X
B Two Way Sensitivity X X
C Tornado Diagram X
D Probability Sensitivity X
E Weight Sensitivity X X
167
Engineering Management Handbook

VII Modeling Uncertainty X X

A Probability Basics X X
B Subjective Probability X X
C Heuristics and Biases X X
D Decomposition and Probability Assessment X X
E Art of Probability Elicitation X X
VIII Value of Information X
A Expected Value without Information X
B Value of Perfect Information X
C Value of Imperfect Information X
IX Single Attribute Risk Preferences X X
A Risk Attitude X X
B Expected Utility, Certainty Equivalent, and Risk Premiums X X
C Utility Function Assessment X X
D Constant Risk Aversion - Exponential Utility Function X X
E Axioms of Utility Theory X X A
F Paradoxes and Implications X X
G Mathematical Foundations of Single Attribute Utility X X A
X Multiattribute Risk References X X A
A Additive Utility Model X X A
B Weight Assessment with Lotteries X X A
C Utility Independence X X A
D Mathematical Foundations of Multiattribute Utility X A
XI Resource Allocation X
A Benefit Cost Analysis with Multiattribute Value X
B Project Selection with Constraints using Optimization X

168
 Multi-Criteria Analysis

12
Multi-Criteria Analysis

Anirban Ganguly
Stevens Institute of Technology

Donald N. Merino
Stevens Institute of Technology

169
Engineering Management Handbook

12.1 Introduction to Multi-Criteria Analysis

12.1.1 Background
Rapid globalization and continual change in the business environment has led various engineering and
business organizations to search for improved techniques to achieve higher profitability in the market.
In this context, a proper “decision-making strategy” is the foundation for success or failure of an orga-
nization. A key aspect of an organization’s strategic decision-making process is how to select the “best”
alternative from among a set of alternatives with often-conflicting attributes. The competing projects that
are to be selected are often dependent on a variety of factors, ranging from the availability of resources to
the organizational infrastructure. Approaches that consider a plethora of attributes, both economic and
non-economic in nature, often prove to be the best selection. Multi-Criteria Analysis (MCA), can trans-
form dissimilar (and often incongruent) information into a common index or value. This then provides
the decision-makers a rational basis for selecting the best alternative.
The purpose of this chapter is to provide engineering managers with an overview of MCA along
with a detailed discussion of some of its commonly used tools and techniques. According to Canada and
Sullivan (1988), increased competitiveness cannot be achieved without an optimal mix of investment in
people, technology and “bricks and mortar.” In this context, having a knowledge about MCA could great-
ly aid decision-makers to arrive at the optimal mix of trade-offs between attributes.

12.1.2 Overview of Multi-Criteria Analysis

Multi-Criteria Analysis (MCA) can be defined as “the study of methods and procedures by which concerns
about multiple conflicting criteria can be formally incorporated into the management planning process” (Inter-
national Society on Multiple Criteria Decision Making). MCA first appeared as a decision making tool in
the sixties (Evalsed, 2003) and is a structured approach used to facilitate the selection of a preferred alter-
native by evaluating each of the alternatives from a set of well-defined criteria. The set of criteria on which
the selection of the alternatives is based should be measurable, even if the measurement is performed on a
simple nominal scale. The measured outcome of the set of criteria (and its subsequent conversion to a sin-
gle composite value) provides the basis for comparison of choice and subsequently facilitates the selection
of the “best alternative.”
The business operations of most organizations consist of decision-making that is made up of a series
of choices, with the final decision being dictated by the result of analyzing each of the choices. Hence,
one of the main purposes of MCA is to structure a set of important criteria that form the backbone of the
decision for choosing a preferred alternative. Furthermore, in a democratic business environment, which
consists of a group of decision-makers (or stakeholders), there often exist a variety of opinions with regard
to the choice of the best alternative. In this context, MCA serves as a widely accepted tool because it con-
siders the subjective opinions of all the decision-makers on each particular criterion and in turn uses the
result to arrive at the “best alternative.”
MCA is used in a wide variety of decision-making processes, from assessing investment decisions in
alternative manufacturing processes to evaluating and selecting any hi-tech engineering project (Ganguly
& Merino, 2006, 2007). Other applications of MCA include decision-making in a variety of fields like
evaluating a new manufacturing system, software allocations, technology management, telecommunica-
tion management and operations research to name a few.

12.1.3 Relevance of MCA to Engineering Management

With the blurring of boundaries between technology and management, engineering must redefine its role
to survive in the modern day business environment (Kotnour and Farr, 2005). As a result, an in-depth
knowledge of decision-making techniques using Multi-Criteria approaches could serve as a very useful
tool for an engineering manager. The techniques highlighted in this chapter are simple and yet highly
purposeful for facilitating any successful decision-making process. As more EM students (and consequent-
ly engineering managers) are employed by industries spanning all areas of manufacturing and services,
the need for awareness of Multi-Criteria decision-making techniques like Multi-Attribute Analysis and
170
 Multi-Criteria Analysis

Analytic Hierarchy Process (AHP) increases. The insight of the techniques gained from this chapter can
aid the engineering managers’ knowledge about techniques and practical applications of decision-making.
This, in turn, could lead to a more effective decision-making process and hence a better selection of EM
projects. Additionally, using non-economic decision-making tools like MCA in tandem with economic
tools like sensitivity analysis and after-tax analysis could provide any engineering manager with the knowl-
edge of how to combine economic as well as non-economic tools to arrive at a more accurate decision
regarding the choice of an engineering project.
The proper selection of any engineering/manufacturing project is a complicated process that requires
detailed analysis before committing huge capital investments. Hence, a proper selection among competing
alternatives is a key to effectively managing engineering/technology projects. This is a typical problem for
engineering managers. This chapter illustrates how to use various techniques to choose among alternative
engineering projects, and, in turn, increase the profitability of the organization.

12.2 Analytic Hierarchy Process

12.2.1 Overview of Analytic Hierarchy Process
Policy makers at all levels of decision-making often use multiple criteria, which, through various tradeoffs,
illustrate the advantages as well as the disadvantages of various policy options under the condition of risk
and uncertainty (Saaty, 1994). One of the most common approaches to the practice of “multiple criteria
decision making” has been Analytical Hierarchy Process (AHP) developed by Thomas L. Saaty (1980).
AHP is a decision-making process that is defined as “an approach to decision making that involves struc-
turing multiple choice criteria into a hierarchy, assessing the relative importance of these criteria, com-
paring alternatives for each criterion, and determining an overall ranking of the alternatives” (Decision
Support Systems Resources Glossary). AHP considers multiple criteria simultaneously, dissects a decision
choice problem in various levels of hierarchy, in turn aggregate the individual solution at various levels of
the hierarchy into a consolidated structure, which the determine the best alternative in the process (Rop-
er-Lowe and Sharp, 1990).

12.2.2 The AHP Process

The process of AHP starts with the construction of a hierarchy that describes the problem that is about
to be tackled. While constructing the hierarchy, the overall objective (which Saaty calls “the focus”) of
the project is always placed right at the top of the hierarchical tree and the main attributes a level below
it. The sub-attributes are placed on the subsequent levels of hierarchy and the final level consists of the
alternatives among which the selection is to be made.
A simple three-level AHP hierarchy is presented in Figure 12.1. Although the level of hierarchies can
be extended further, depending on the degree of details that the decision-maker wants to choose.

Selecting the Attributes

The “old” right-hand rule of industrial engineering says that fewer attributes are preferred because they
represent the vital few—as opposed to the trivial many. The “right hand” suggests that five attributes is an
appropriate number. Selecting attributes should follow the KISS (Keep It Simple Stupid) principle.

Choosing Among the Alternatives

After constructing the hierarchy, the next step is to choose between the attributes through a series of
pair-wise comparisons where each attribute of that particular hierarchical level is compared with its sibling
with respect to their relative importance to each other. The pair-wise comparisons are made relative to
the importance, likelihood, desirability and so on and are mostly based on a numeric scale. The pair-wise
comparisons are denoted in terms of the relative importance of an attribute with respect to the final alter-
native decisions being compared. Table 12.1 shows the 9-point AHP scale with an explanation of each of
the scale levels.
171
Engineering Management Handbook

Figure 12.1. A Simple Three-Level AHP Model

Objective /
Goal / Focus

Attribute 1 Attribute 2 Attribute 3

Alternative A Alternative B

Table 12.1. Scale for Pair-wise Comparison Using AHP1

Relative Definition Explanation

Intensity
1 Equally Preferred The two attributes in question (i and j) are of equal importance
3 A Little More Preferred One variable is a little more important than the other
5 Moderately Preferred One variable is much more important than the other
7 Highly Preferred One variable is very much more important than the other
9 Extremely Preferred One variable is extremely more important than the other
Reciprocal If attribute i has one of the above numbers assigned to it when compared with attribute j, then
(1/3, 1/5, j has the value 1/number assigned to it when compared with i. More formally if nij = x then nji
1/7, 1/9) = 1/x.

Determining the Weights

Next, we need to derive the weights of the lowest level of attributes through a series of pair-wise compari-
sons where each attribute of that particular hierarchical level is compared with its sibling. In this context,
it should be noted that any pair-wise judgment could be represented in the form of a matrix where the
cells denote the relationship between a particular pair-wise judgments. Each judgment represents the domi-
nance of an element in the column over an element in the row (Saaty, 1994), based on the scale provided in
Table 12.1. This is shown in Table 12.2.

Table 12.2. Pair-Wise Comparison Between Attributes

Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5

Attribute 1 1 3 5 5 9
Attribute 2 1/3 1 3 9 7
Attribute 3 1/5 1/3 1 5 9
Attribute 4 1/5 1/9 1/5 1 7
Attribute 5 1/9 1/7 1/9 1/7 1
Table 12.2 exhibits a hypothetical pair-wise comparison table among five attributes. In this example,
172
 Multi-Criteria Analysis

because Attribute 1 is “a little more” preferred to Attribute 2, cell i12 is “3” and consequently, its reciprocal,
that is, cell i21, is “1/3.” Furthermore, for a set of “n” elements (or attributes) the number of pair-wise compari-
sons should be “n (n-1)/2”. Saaty (1994) provides a rationale for this. According to him, because there are n
1’s on the diagonal for comparing the attributes with themselves and of the remaining judgments, half are
reciprocals. Therefore, there are “(n2- n)/ 2”, i.e., n (n-1)/2 judgments for a set of “n” attributes. Thus, for
a set of five attributes, the number of pair-wise judgments should be 10 (i.e., “(5*4)/2 = 10”).

Weighting the Attributes

After the comparisons are made, they are converted into a numeric scale and are entered into a matrix.
The resulting data is normalized in order to make the matrix column stochastic in nature and the Eigen-
vectors are subsequently derived from the matrix. Tables 12.3 and 12.4 illustrate this point.

Table 12.3. Pair-Wise Comparison Between Attributes with Totals

Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5

Attribute 1 1 3 5 5 9
Attribute 2 1/3 1 3 9 7
Attribute 3 1/5 1/3 1 5 9
Attribute 4 1/5 1/9 1/5 1 7
Attribute 5 1/9 1/7 1/9 1/7 1
TOTAL 1.84 4.59 9.31 20.14 33

Table 12.4. Normalized Values of Pair-Wise Comparison Between Attributes

Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5

Attribute 1 0.542 0.654 0.537 0.248 0.273
Attribute 2 0.181 0.218 0.322 0.447 0.212
Attribute 3 0.108 0.073 0.107 0.248 0.273
Attribute 4 0.108 0.024 0.021 0.050 0.212
Attribute 5 0.060 0.031 0.012 0.007 0.030
TOTAL 1.000 1.000 1.000 1.000 1.000

Composite Score
After the pair-wise comparison has been completed, the results are combined into a composite score,
which shows how well each of the alternatives to be chosen fits the overall objective (focus) of the deci-
sion-making process. Finally, the last step of the AHP is that of making the actual decision based on the
overall values of the alternatives in question.

Summary of AHP
1. Choose the goal or objective to be evaluated
2. Choose the attributes (KISS)
3. Establish a rating system for pair-wise comparisons
4. Use the rating system to choose among the attributes
5. Normalize the attributes to determine their weights
6. Chose the alternatives
7. Use the same process as in Steps 3 and 4 for each attribute/alternate combo
173
Engineering Management Handbook

8. Summarize and evaluate the ratings

9. Choose the alternate with the highest score

Are the Choices Consistent?

The process discussion of AHP will conclude with an overview of the “Consistency Ratio (CR).” Consis-
tency Ratio in AHP can be defined as an indicator of the level of consistency in the judgments of the
respondents. For example, it is often seen that the respondent to any pair-wise judgment survey might
prefer A to B, B to C, but C to A. The consistency ratio essentially denotes the level of inconsistency of
the respondents. Any consistency ratio of 0.10 and under is acceptable (Lang and Merino, 1993; Saaty
1994) to the decision-makers and if the judgments are perfectly consistent, the consistency ratio is zero.
However, an inconsistency ratio of greater than 0.10 does not necessarily denote an error in the multiple
criteria analysis using AHP. It is often seen (Ganguly and Merino, 2007) that the pair-wise comparison
among the attributes selected was not transitive in nature. For example, the relative importance of attri-
bute “A” being greater than attribute “B” and the relative importance of attribute “B” being greater than
attribute “C” does not necessarily signify that attribute “A” will be preferred to attribute “C.” Saaty (2001)
provides a rationale behind this in the sense that evaluators often make tradeoffs that violate transitivity
but, overall, are accurate in their judgments because they take into account the relative importance of the
criteria themselves. There are times when an evaluator cannot make a clear decision because the tradeoffs
among several activities come out to be the same (Saaty, 2001) and are not related to some other pair-wise
judgment. This is the primary reason why the final AHP judgment values are not revised in many situa-
tions in spite of a high CR and the overall AHP value based on the pair-wise judgment value is used as the
final decision-making criteria. For further insights into Consistency Ratio (CR) and Consistency Index
(CI), readers are advised to refer to sections 7.4 and 7.5 in Saaty (2001) and Appendix 28A in Lang and
Merino (1993).

Distributive vs. Ideal Mode

AHP has two options of performing an operation—the distributive mode and the ideal mode (Dolan,
2000; Liberatore and Nydick, 2003). The distributive mode is followed when the objective of the analysis
is to prioritize a set of options in order to determine how to distribute something among them while the
ideal mode is used when the basic objective of the analyses is to identify the best set of options. Generally,
the ideal mode of synthesis is used more frequently than the distributive mode of synthesis.

12.2.3 Advantages and Limitations of AHP as a Multi-Criteria Tool

The popularity of AHP stems from its ability to translate subjective judgments by the decision-makers
into numerical values. AHP is an intuitive technique that not only integrates subjective judgment with
mathematical data, but also facilitates the participation of the entire pool of decision-makers in the deci-
sion-making process. Additionally, AHP’s simple, intuitive nature allows the participants to complete the
process with relative ease, thereby arriving quickly at a conclusion regarding the selection of an alternative
from a multiple set. However, in spite of its wide popularity, AHP is not devoid of limitations. The two
major limitations of AHP that have been cited are its implicit assumption of transitivity among the pair-
wise judgments and the problem of Rank Reversal. AHP implicitly assumes a logical transitivity among
pair-wise judgments, which is not always the case in a real-life decision-making process. Thus, the value
of the Consistency Ratio (CR) in AHP often ends up being higher than the desired value (i.e., ≤ 0.10),
reducing the authenticity of the analysis in the process. However, this is not true because the pair-wise
judgments of the decision-maker are not always transitive in nature. An example of the loss of transitivity
on judgment and the subsequent explanation is provided in the previous section. Another major limita-
tion of AHP is the issue of Rank Reversal. Rank Reversal can be explained as the situation where an alter-
native chosen as the best out of a set fails to be chosen when another, perhaps unimportant and irrelevant,
alternative is excluded from (Perez et al., 2002) or included in the set. The issue of rank reversal has been
raised by the practitioners of Utility Theory as one of the major drawbacks of AHP (Saaty, 1994). How-

174
 Multi-Criteria Analysis

ever, Saaty (1994) argues that using the “ideal mode” of AHP synthesis, rather than the distributive mode,
would aid any decision-maker to preserve the original rank.

12.2.4 Conclusion
We can conclude from the above that an AHP analysis aids the decision-maker in gaining valuable insight
into his or her values and the relative merits of the available decision options. AHP is a structured method
that can elicit more information from target respondents (usually experts or decision-makers) (Cheng and
Li, 2001). According to Dolan (2000), AHP reduces a complex problem into smaller, simple parts and
thus makes solving not only easier, but also much less error prone. Additionally, AHP provides a method
of applying multiple viewpoints into a decision-making process in an explicit and unbiased manner—
thereby making the decision-making process not only very practical, but also very complete. Several
available techniques of sensitivity analysis allow how changes in the pair-wise comparisons of the criteria
weights might affect the result. Finally, AHP, which is a multiple criteria decision-making process, has all
the potential for overcoming many of the cognitive and practical problems associated with most other
decision-making models. AHP also ensures that all-important considerations, even the ones that are very
unique, are addressed while selecting the best alternative (Saaty, 1990).

12.3 Analytic Network Process

12.3.1 Overview of Analytic Network Process
In spite of its wide popularity, one of the drawbacks of AHP is that it is primarily based on a one-way
hierarchical structure. In the case of Analytic Network Process (ANP), all the attributes in the deci-
sion-making process can be related in any possible way—thereby incorporating a subjective judgment not
only within a particular level of hierarchy, but also among various levels (referred to as clusters in ANP) of
the hierarchy. This type of networked approach is suitable for complex decision-making scenarios, where
interrelations among all the elements at every level of hierarchy is considered as a part of the final analy-
sis—a situation that every engineering manager is faced with at some point in their careers.

ANP Structure
ANP takes into consideration the inner as well as outer dependence among the elements (Saaty, 2001).
Although inner dependence signifies the relationship between the attributes of any particular level of
hierarchy (or cluster, in the case of ANP), the outer dependence indicates the relationship among various
levels. This relationship is illustrated by a Supermatrix, which is a two-dimensional matrix that represents
the relationship among all the clusters available in the ANP analysis and is column stochastic in nature,
which is a matrix whose columns sums up to unity (Saaty, 2001). The overall decision regarding the
choice of the final alternative in ANP is based on the Supermatrix.

12.3.2 The ANP Process

A typical ANP decision-making process comprises of the following steps.

Step 1: Structuring the Problem

ANP starts by laying down the problem in the form of an interdependent network of elements. A typical
ANP network comprises all the clusters and the sub-clusters, arranged in a networked fashion, that might
be beneficial in achieving the overall object of the decision-making process. For example, let us suppose
that a car buyer has to decide among selling three brands of car, Brand A, B and C. In order to arrive at
a purchasing decision, the buyer has to consider a set of monetary as well as non-monetary attributes. A
basic ANP network for this problem is shown in Figure 12.2.

Figure 12.2. Simple ANP Network for a Decision-Making Process

175
Engineering Management Handbook

• Brand A
• Brand B
• Brand C

Alternatives
(Car Brand)

• Initial Cost Monetary Non-Monetary • MPG

• Maintenance Cost Attributes Attributes • Look of the Car

As seen in Figure 12.2, the basic ANP structure, unlike AHP, consists of a network where every node
is connected with each other.

Step 2: Determining the Prioritized Weights of the Elements (or attributes)

The next stage of an ANP process consists of performing a pair-wise comparison among the various ele-
ments of a cluster, the influence of the clusters on each other as well as the overall objective of the process.
This analysis follows the same process and the 9-point scale used in AHP. However, in the case of ANP, the
pair-wise comparisons are made between the sub-elements with respect to their parent elements. The resulting
values are then normalized to add up to one. For example, in the context of the car purchase example, a
possible pair-wise comparison would be to assess the relative priorities of the different brands of the car,
with respect to the maintenance cost. This is shown in Table 12.5.

Table 12.5. Pair-Wise Comparison Between Brands with respect to Maintenance Cost

Brand A Brand B Brand C Mean Normalized Weights

Brand A 1 5 3 0.6234
Brand B 1/5 1 3 0.2390
Brand C 1/3 1/3 1 0.1376
TOTAL 1.533 6 7 1.0000

Step 3: Creating a Supermatrix

Once the pair-wise comparisons have been done and their values normalized, the next stage is to arrange
the values in the form of a Supermatrix—a matrix that contains the normalized values of the pair wise
comparisons among the different levels of hierarchy—or as they are called in ANP, clusters. The Superma-
trix, in other words, is a matrix that includes the pair-wise comparison value of a sub-element with respect
to its parent element. Additionally, a zero entry in a particular cell in the Supermatrix represents the
absence of any relationship between the corresponding row and the column elements. Table 12.6 provides
a sample Supermatrix.

176
 Multi-Criteria Analysis

Table 12.6. ANP Supermatrix—Un-weighted

– Brand A Brand B Brand C I – Cost M – Cost MPG Look

Brand A 0 0 0 0.6843 0.6234 0.6063 0.3326
Brand B 0 0 0 0.2276 0.2390 0.3328 0.2993
Brand C 0 0 0 0.0881 0.1376 0.0609 0.3682
I – Cost 0.6000 0.5000 0.3200 0 0 0.4443 0.4200
M – Cost 0.4000 0.5000 0.5800 0 0 0.5557 0.4800
MPG 0.3524 0.4500 0.3333 0 0 0 0
Look 0.6476 0.5500 0.6667 0 0 0 0

Table 12.6 depicts a simple ANP Supermatrix. As seen from the matrix, each cell in the Supermatrix
denotes the relationship of a sub-element with respect to a parent element, with the sub-elements present-
ed in rows and the parent elements in columns. Thus, the intersection cell of the fifth column and the first
row shows the normalized value of Brand A with respect to the Maintenance Cost (Table 12.5) and so on.
The “zero” values denotes the absence of relationship between the row and the column element.
The next stage consists of normalizing the Supermatrix in order to make it column stochastic in na-
ture. The new Super matrix is called Weighted Supermatrix and is provided in Table 12.7.

Table 12.7. ANP Supermatrix—Weighted

– Brand A Brand B Brand C I – Cost M – Cost MPG Look

Brand A 0 0 0 0.6843 0.6234 0.3032 0.1750
Brand B 0 0 0 0.2276 0.2390 0.1664 0.1575
Brand C 0 0 0 0.0881 0.1376 0.0305 0.1938
I – Cost 0.3297 0.2500 0.1684 0 0 0.2222 0.2210
M – Cost 0.2198 0.2500 0.3053 0 0 0.2779 0.2526
MPG 0.1936 0.2250 0.1754 0 0 0 0
Look 0.2569 0.2750 0.3509 0 0 0 0

Step 4: Creating the Limit Supermatrix

Once the Supermatrix has been determined, the next step is to raise it to a large power at which point
the weight stabilizes. In other words, the matrix has to be raised to a sufficiently high power where all the
values of a single row have to be the same. This has to be done through a number of iterations. The new
matrix is called Limit Supermatrix and has the same form as the weighted Supermatrix, but all the col-
umns of the Limit Supermatrix are the same (Saaty, 2001). Normalizing the Limit Supermatrix will result
in the final prioritized weights of all the attributes and the sub-attributes from which the overall value of
the set of alternatives can be determined. This is shown in Table 12.8.

Table 12.8. ANP Limit Supermatrix

– Brand A Brand B Brand C I – Cost M – Cost MPG Look

Brand A 0.270 0.270 0.270 0.270 0.270 0.270 0.270
Brand B 0.113 0.113 0.113 0.113 0.113 0.113 0.113
Brand C 0.064 0.064 0.064 0.064 0.064 0.064 0.064
I – Cost 0.175 0.175 0.175 0.175 0.175 0.175 0.175
M – Cost 0.163 0.163 0.163 0.163 0.163 0.163 0.163
MPG 0.089 0.089 0.089 0.089 0.089 0.089 0.089
Look 0.123 0.123 0.123 0.123 0.123 0.123 0.123

177
Engineering Management Handbook

The weighted Supermatrix converges until the third decimal place when raised to the 18th power. Al-
though this might sound very difficult, there are mathematical software programs (Scientific Notebook®,
Mathematica®, Matlab®, etc.) that solve these problems with considerable ease.

Step 5: Determining the Final Alternative

The final selection of the preferred alternative is determined by synthesizing the Limit Supermatrix. The
values in the Limit Supermatrix are then normalized according to the clusters and the alternative with the
highest value is considered as the preferred one. This is shown in Table 12.9.

Table 12.9. Final Alternative Values based on ANP

Alternative Value Rank

Brand A 0.270 1
Brand B 0.113 2
Brand C 0.064 3

12.3.4 Benefits and Limitations of ANP as a Multi-Criteria Tool

Like AHP, the popularity of ANP stems from its ability to translate subjective judgments by the deci-
sion-makers into numerical values. ANP, like AHP, is also an intuitive technique that not only integrates
subjective judgment with mathematical data, but also facilitates the participation of the entire pool of
decision-makers in the decision-making process. However, in addition to having the same benefits as
AHP, ANP makes a decision-making process more rational by incorporating non-linear interdependence
between the different hierarchical levels of the analysis. Including interdependent relationships in any
ANP model has allowed ANP to gain rapid popularity over its unidirectional hierarchical counterpart,
i.e., AHP. The procedure of ANP is especially beneficial in complex engineering projects, where an engi-
neering manager has to consider a number of interrelated factors in order to determine the viability of a
particular project. Due to its complexities and the tedious nature of the survey, ANP is yet to gain popu-
larity among the industry practitioners. For any project that is simplistic in nature, AHP is often preferred
over ANP due to its simplicity. Furthermore, the process of ANP does require some complex calculation
(for example, the determination of Limit Supermatrix), that often deter any practitioner to indulge in the
process. However, software like Superdecisions® (www.superdecisions.com) developed by Thomas L. Saaty
can prove to be useful in solving any decision-making problem using ANP.

12.3.3 Conclusion
One of the fundamental advantages of ANP lies in the fact that it stretches well beyond the tradition-
al boundaries of linear decision-making tactics. In a world that is guided by complex decision-making
processes, the business and engineering managers often have to indulge in decision-making processes that
can be far more well represented through a non-linear multidirectional networked approach. This type of
an approach enables the decision-makers to consider consequences that not only affects the alternatives,
but also derive its importance from the alternatives themselves—thereby resulting in a networked frame-
work for decision-making. The networked structure used in ANP allows the users to identify, classify, and
arrange all the factors that influence the outcome of a decision (Saaty and Vargas, 2006), enabling, in the
process, the decision-maker to arrive at more robust and practical solutions regarding the project selection
and evaluation.

178
 Multi-Criteria Analysis

12.4 Multi-Attribute Analysis (MAA)

12.4.1 Overview
As most engineering managers would agree, the selection of any manufacturing / capital project stretches
beyond the economic considerations. The economic justification of projects still plays the single most
important role in its choice, as more and more organizations are trying to arrive at an efficient mix of
economic as well as non-economic justifications in the final selection of an engineering project. Multi-at-
tribute analysis (also addressed as multi-objective analysis, multi-factor analysis, etc.), though different
techniques, addresses this concern and enlists possible ways to include monetary considerations in the
decision-making process that are often intangible in nature and are very difficult to quantify directly. It is
very common to find that a project, which was considered economically viable, lose its importance once
the non-economic criteria are added to the decision-making process. This is especially true in govern-
ment and public-sector projects, where the benefits derived from the projects (along with other periph-
eral non-economic consideration) are of primary importance when it comes to the final selection of the
preferred alternative among a set of many. The remainder of the chapter will provide the reader with a
discussion of some of the most commonly used techniques of MAA.

12.4.2 The Multi-Attribute Analysis (MAA) Process

The typical MAA process consists of the following stages.

Step 1: Selecting the Attributes

The starting point of any MAA consists of selecting the set of attributes, which will be evaluated as part of
the final decision-making process. As stated earlier, most of the attributes selected are generally non-mon-
etary in nature. The selection of the attributes can be made based on group discussions, interviews,
surveys, experts’ solicitations, among others. Although the list of attributes influencing a particular project
can be endless, it is always advisable to select a set on critical ones that have the greatest influence on the
selection process (i.e., select vital few from trivial many) and only if the results warrant, add more to the
list (Lang and Merino, 1993).

Step 2: Selecting the Measurement Scale

The list if attributes identified in the previous stage have to be evaluated on a scale. Therefore, selecting
the measurement scale represents the second stage of the process. The selection scale, like the attributes,
can be decided based on discussion or subjective judgment. In many cases, the scale is simply the metric
on which the measurement is made. Nevertheless, the general practice is to use the same measurement
scale for all the attributes (for example, using a scale of 1 – 5 to rank attributes) in order to avoid any am-
biguity in the ranking process. Once the measurement scale is selected, the attributes are ranked following
the selected scale.

Step 3: Weighting the Attributes

Once the attributes are ranked, the next step is to assign weights to the attributes. Normally, the range of
the weights varies from 0 to 1, with 0 being the least preferred attribute and 1 being the most preferred.
The weighting of the attributes can be accomplished using two different techniques. First, the relative
importance of the attributes can be assigned from discussions with the stakeholders and decision-makers
so that the most important attribute is assigned the highest weight and so on. The other method would be
to assign the weights based on specific tradeoffs. However, unless important otherwise, it is advisable to
assign equal weights to the attributes under the assumption that the entire set of identified attributes has
approximately the same importance in affecting a decision-making scenario.
Once the weights have been assigned, the next stage is to normalize the weights. Normalization is
done to reduce data redundancy—although this is unnecessary if the attributes are assigned equal weights.
Normalizations enable the scores to be converted into a standard scale that adds up to 1.00 and therefore
179
Engineering Management Handbook

provides the decision-maker with a true reflection of the attributes’ relative weights. The normalized val-
ues of the weights serve as a cornerstone for determining the overall rank of alternatives.

Step 4: Determining the Final Rank of the Alternatives

The final values of the attributes are determined by multiplying the normalized weights to the rank
assigned to each of the attributes (Step 2). This is called the Weighted Additive Model and is by far the
technique most widely used for final ranking of a set of attributes. The attribute with the highest overall
value is considered the most important followed by the one with the second highest value and so on. The
additive function is:

Ai = ∑ ni = 1 Xi * Yij (12.1)

where,
Ai = The final value of alternative i
Xi = The normalized weights of the attributes and
Yij = Rating of attribute i for alternative j.

In context of Equation 12.1, the alternative with the highest value of “A” should be the preferred one. If
the decision is based on the viewpoint of several decision-makers, the standard procedure it to determine
the mean of the final overall value for any particular alternative.

12.4.3 Utility Theory (Utility Analysis)

Utility, as defined by the American Heritage Dictionary of the English Language, is “the quality or condition
of being useful.” Therefore, Utility Theory can be stated as an attempt to infer subjective value, or utility,
from choices. The concept of utility analysis has emerged as a useful tool for the selection of different
projects. As a result, the perceived utility for a selected project serve as a very important consideration for
selection among a set of competing projects. One of the main reasons for the huge success of utility anal-
ysis is that it affords a rational method of project selection, thus avoiding many of the fundamental logical
difficulties of many widely used alternative approaches (Roth, Field, and Clarke, 1994).
As an illustration of the concept of utility, let us cite a simple hypothetical scenario. Suppose an
engineering manager has been given the responsibility to select a data network that would streamline
the flow of information in the organization. One of the primary attribute to be considered in this case
should be the reliability of data network. The utility derived from getting 99% reliability will result in a
higher perceived utility than 97% reliability, all other things remaining constant. So, in this case, it will
be U 99% > U 97% for the engineering manager (Lang and Merino, 1993). However, the decision-maker
might become indifferent among the projects if the utility falls below a certain level. For example, for
any reliability level of less that 85%, the decision-maker becomes indifferent to the projects and might
start looking for other options (or base the selection of other attributes). At the point of indifference
onward, the utility curve becomes asymptotic to the horizontal axis. This will be discussed further in
the following section.

Stages in Utility Analysis

Utility Theory (Analysis) is a multi-attribute decision-making tool that determines the expected utility for
a project, based on the possible values of its attributes.
Utility Analysis is comprised of the following stages.

Step 1: Selecting the Attributes

Utility Analysis, like any other multi-attribute decision-making technique, starts with the selection of a set
of critical attributes whose expected utility is to be determined. The expected utility of the attributes will
180
 Multi-Criteria Analysis

subsequently be combined to develop the overall value of the utility function. The selection of the attri-
butes can be based on group discussions, interviews, surveys, and experts’ opinions, among others.

Step 2: Determining the Utility Function and its Shape

Utility Function can be defined as a mathematical function that expresses the preferences of decision-mak-
ing attributes with respect to expected returns and risks associated with the decision. The shape of the
utility function is called Utility Curve. For any decision-making attributes (say, reliability as cited in the
previous section), there is a most favorable (best) outcome and a least favorable (worst) outcome. The
best outcome is generally assigned a value of 1 and the worst a value of 0. The shape of the utility curve
depends on the attribute and the decision-maker (Lang and Merino, 1993). For example, let us consider
the attribute “reliability.” A reliability of 95% and more has a reading of 9, 90%-95%, a reading of 0.8,
88% - 90%, a reading of 0.5 and 85% - 88%, a reading of 0.2 and anything below a 85%, a reading of
0.1. Then the shape of the utility function (Utility Curve) will assume the one shown in Figure 12.3.

Figure 12.3. The Shape of a Hypothetical Utility Function

Utility

0.8

Reliability
0 85% 95% 100%

As seen in Figure 12.3, the perceived utility of the attribute starts rising only after it passes the 85%
mark. A 100% reliability assumes a utility value of 1 (the best outcome) while any value below the 85%
level assumes a value of 0 (worst outcome). However, it should be mentioned here that the Utility func-
tion shown in Figure 11.4 is just one of many shapes it can assume. It can be either linear or non-linear
in nature depending on the attribute and the scale assigned by the decision-makers. For example, the
shape of the utility function for “cost” is generally linear and negatively sloped in nature, i.e., the higher
the cost, the lower the utility while that of the profit function is positively sloped. In addition, the same
decision-making project can comprise of multiple utility function depending on how many attributes the
decision is evaluated upon.

Step 3: Determining the Overall Utility of the Alternatives

Once the utility functions are derived, the set of values is then replaced in the function in order to deter-
mine the utility value of the attribute. A composite utility function consisting of all the attribute utility
value forms the overall utility value of the alternative, on which the final decision is based.

12.4.4 Conclusion
The utility and value analysis allows a decision-maker to take into account a set of subjective judgments and
convert them into a numerical scale. This technique is highly useful when it comes to solving decision-mak-
181
Engineering Management Handbook

ing problems with multiple objectives, as it effectively incorporates the perceived utilities derived from a
variety of attributes, and combines them to form a composite overall utility value. The approach is also use-
ful when money is not the sole criterion but other non-economic criteria are used in tandem with monitory
aspects in the overall decision-making process. Utility theory brings structure and method to what is often an
ad-hoc decision-making process, providing the decision-maker with a more rational and concrete decision.

12.5 References
Blank, Leland and Tarquin, Anthony, Engineering Economy, McGraw-Hill, 2005.
Canada, John R., and Sullivan, William G., Economic and Multiattribute Evaluation of Advanced Manufac-
turing Systems, Prentice Hall, 1988.
Cheng, Eddie W. L., and Heng Li, “Information priority-setting for better resource allocation using ana-
lytic hierarchy process (AHP),” Information Management & Computer Security, vol. 9, no. 2-3,
2001, pp. 61-70.
Dolan, James G., “Involving patients in decisions regarding preventive health interventions using the
analytic hierarchy process,” Health Expectations, vol. 3, no. 1, March 2000, pp. 37-45.
Environmental Resources Management (ERM), “Multi Criteria Analysis,” Anex 4D,.4 for Strategic Plan-
ning Guide for Municipal Solid Waste Management by Wilson, Whiteman & Tormin, Accessed online
on 7th July 2008 from http://www.worldbank.org/urban/solid_wm/erm/Annexes/US%20Sizes/
New%20Annex%204D.4.pdf
Evaluating Socio Economic development (Evalsed), “Multicriteria Analysis,” Sourcebook 2: Methods and
Techniques (2003), Available online at http://ec.europa.eu/regional_policy/sources/docgener/evalua-
tion/evalsed/downloads/sb2_multicriteria_analysis.doc
Ganguly, Anirban and Merino,Donald N., “Economic and Non-Economic Analysis of Emerging Micro-
wave Technology,” 27th American Society of Engineering Management (ASEM) National Conference
Proceedings, Huntsville, Alabama, October 2006.
Ganguly, Anirban and Merino, Donald N., “Applying Analytical Hierarchy Processing in Selection
among Alternative Chemical Process,” 28th American Society of Engineering Management (ASEM) Na-
tional Conference Proceedings, Chattanooga, Tennessee, November 2007.
Keeney, Ralph L., “An Illustrated Procedure for Assessing Multiattributed Utility Functions,” Sloan
Management Review, vol. 14, no. 1, Fall 1972, pp. 37-50.
Kotnour, Timothy and Farr, John V., “Engineering Management: Past Present and Future,” Engineering
Management Journal, vol. 17, no. 1, March 2005, pp. 15-26.
Lang, Hans J. and Merino, Donald N., The Selection Process for Capital Projects, John Wiley & Sons Inc., 1993.
Liberatore, Matthew J. and Robert L. Nydick, Decision Technology: Modeling, Software, and Applications,
John Wiley & Sons, Inc., 2003.
Roper-Lowe, G. C. and Sharp, J. A., “The Analytical Hierarchy Process and its Application to an Infor-
mation Technology Decision,” Journal of Operational Research Society, vol. 41, no. 1, 1990, pp. 49-59.
Roth, Richard, Field, Frank, and Clarke, Joel P., “Material Selection and Multi-Attribute Utility Analysis,”
Journal of Computer Aided Material Design, vol. 1, no. 3, October 1994, pp. 325-342.
Saaty, Thomas L., Analytic Hierarchy Process, New York: The McGraw-Hill Companies, 1980.
Saaty, Thomas L., “How to Make Decisions: The Analytic Hierarchy Process,” European Journal of Oper-
ation Research, vol. 48, no. 1, Sept. 1990, pp. 9-26.
Saaty, Thomas L., “How to Make a Decision: The Analytic Hierarchy Process,” Interfaces, vol. 24, no. 6,
November / December 1994, pp. 19-43.
Saaty, Thomas L., Multicriteria Decision Making—The Analytical Hierarchy Process: Planning, Priority Set-
ting, Resource Allocation, RWS Publications, 2001.
Saaty, Thomas L., Decision Making with Independence and Feedback: The Analytic Network Process, Pitts-
burgh: RWS Publications, 2001.

182
 Engineering Informatics – State of the Art and Future Trends

13
Engineering Informatics – State of the Art
and Future Trends

Li Da Xu
Old Dominion University

183
Engineering Management Handbook

13.1 Introduction
Engineering informatics is an emerging engineering discipline combining information technology or
informatics with a variety of engineering disciplines. It is an interdisciplinary scientific subject focusing
on the application of advanced computing, information, and communication technologies to a variety of
engineering disciplines.
Computer-aided design (CAD), computer-aided engineering (CAE), computer-aided manufacturing
(CAM) are the terms that have appeared over the last four decades in the area of computing technology
in engineering. Computing technology has had significant impacts on a variety of engineering disci-
plines. Meanwhile, computing technology in engineering has also continuously promoted the advances in
computing technology. In this evolution process, computing technology, computational methods, and a
variety of engineering disciplines have increasingly intertwined as the development of the theory and prac-
tice in both disciplines (computing technology and engineering) influences each other.
Since 1990, the need for a scientific subject called engineering informatics has been recognized,
although the subject has not yet been formally recognized as a scientific and engineering discipline. The
following are excerpted from reports from either the National Science Foundation or the National
Academies:
“The structuring of design information and data integration are critical requirements for data shar-
ing between designers separated physically and in time, as well as between companies, vendors and
customers. Standards do not yet exist for modeling many engineering and organizational param-
eters that are essential for design specification and analysis, nor are there standards for structuring
rational for decisions and design procedures used” (National Research Council, 1991). “Data
communication in a heterogeneous system, validation, and consistency of data, representation of
textual and geometrical data, …, analytical models of manufacturing processes are all risky areas
of research, requiring multiyear, cooperative efforts. Solutions to these problems are needed…”
(National Research Council, 1995). “Interdisciplinary collaborations will be especially important
for implementing comprehensive processes that can integrate the design of mechanical systems
with the design of electrical systems and software. Successful collaborations, however, will first
require overcoming incompatibilities between emerging technologies and the existing technological
infrastructure and organizational cultures” (National Science Foundation, 2004). “For many orga-
nizations, a fundamental change in the engineering culture will be necessary to take advantage of
breakthroughs in advanced computing, human-machine interactions, virtual reality, computational
intelligence, and knowledge-based engineering…” (National Academy of Engineering, 2005).

In 2008, Subrahmanian and Rachuri first proposed to use the term “engineering informatics” to cover
the theory and practice in which computing technology and engineering are interfacing (Subrahmanian
and Rachuri, 2008). “Informatics, with origins in the German word Informatik referring to automated
information processing, has evolved to its current broad definition. The rise of the term informatics can
be attributed to the breadth of disciplines that are now accepted and envisioned as contributing to the
field of computing and information sciences. A common definition of informatics adopted by many
departments/schools of informatics comes from the University of Edinburgh: “the study of the structure,
behavior, and interactions of natural and artificial computational systems that store, process and commu-
nicate information.” Informatics includes the science of information, the practice of information process-
ing, and the engineering of information systems” (Subrahmanian and Rachuri, 2008). Informatics has an
engineering aspect, which addresses the engineering and operation of information processing systems that
compute, store, communicate, and visualize information (Broy, 2006).
Subrahmanian and Rachuri (2008) further indicated that the history of computing technology and
engineering shows a trend of increasing sophistication in the type of engineering problems being solved.
Early CAD was primarily based on computational algorithms and models. Then came the engineering use
of artificial intelligence (AI), driven by theories of cognitive science and computational models of cogni-
tion. More recently, models of collaboration, and the acquisition and representation of collective knowl-
edge have been introduced. Following this trend, engineering informatics can be defined as “the study
184
 Engineering Informatics – State of the Art and Future Trends

of use of information and the design of information structures that facilitate the practice of engineering
and of designed artifacts that embody and embed information technology and science to achieve social,
economic and environmental goals” (Subrahmanian and Rachuri, 2008). Subrahmanian and Rachuri
identified several strands of concepts that support the proposing of engineering informatics as a distinct
discipline that interfacing engineering and informatics (Subrahmanian and Rachuri, 2008). As comput-
er scientists or engineers cannot solve engineering informatics problems in the context of engineering
systems alone, engineering informatics is an interdisciplinary and collaborative effort. In other words,
the lack of required backgrounds among computer scientists in engineering and engineers in computing
technology has led to develop a new interdisciplinary subject—engineering informatics.
Engineering informatics is an interdisciplinary subject. For example, constructing an embedded soft-
ware system for engineering purpose requires interdisciplinary efforts in mechanics, the domain, software,
hardware, human-machine interfaces, and other disciplines. Engineering informatics is to use the knowl-
edge from both informatics and engineering for forming engineering informatics knowledge framework
and base.
Similar movements have been seen in individual engineering disciplines. In the construction engi-
neering discipline, initially, several names have been used for the interdisciplinary field related to both
construction engineering and computing technology such as “computer integrated construction,” “com-
puting in civil engineering,” and “information technology in construction.” The most commonly used
terms are “information technology in construction” or “construction IT.” They were coined in the middle
1990s (Turk, 2006). According to Turk (2006), “years later more sober voices claim that many of the
problems in the construction industry, that could have been solved by information technology, are not
solved, however not only due to technical issues. It seems appropriate, therefore, to remove the word
technology and leave just ‘construction informatics’ (CI), construction taken in the broadest sense of the
word to include building, civil engineering, and structural engineering, AEC (architecture, engineering,
construction) and other disciplines…” (Turk, 2006).
As informatics is applicable in multiple engineering disciplines or span multiple engineering disci-
plines, as such, the term “engineering informatics” was proposed, coined, and started to be used. It is
natural that the informatics for a specific engineering subject start expanding to cover a variety of engi-
neering disciplines, and eventually, a more general term called engineering informatics was proposed and
coined. Engineering informatics is considered as a distinct discipline, at the interface between engineering
and informatics, in the same vein as bioinformatics and medical informatics (Subrahmanian and Rachuri,
2008).
Subrahmanian and Rachuri proposed their view of the field of engineering informatics (for fully rep-
resent the original contents, Figure 1 was reproduced from (Subrahmanian and Rachuri, 2008). In Figure
13.1, the inner set of circles marked as informatics covers the fundamental activities associated with infor-
matics in general. The next circle, denoted by Product and Process, identifies the multilevel, multi-scale
modeling activities of products and processes. The role that informatics plays in engineering products and
processes has been becoming significant in past decades. The outer circles show the inputs to engineering
informatics from a number of disciplines that provide the domain knowledge and methods and tools.

185
Engineering Management Handbook

Figure 13.1. The Scope of Engineering Informatics Proposed

Although Subrahmanian and Rachuri proposed their view of the field of engineering informatics, the
scope of engineering informatics, can be further refined. As indicated by Broy (2006), software and systems
engineering is the key for constructing information processing systems. In particular, software and systems
engineering addresses issues such as requirements engineering and reliability engineering (Broy, 2006).
Regli (2007) indicated that, in the information technology in engineering, although there have been
great strides made by academic and commercial entities in the past decades, the fundamental problems
of information integration remain the same. In 2008, Subrahmanian and Rachuri indicate the numerous
incompatibilities in information exchange and coordination. The delays that occurred in Airbus 380 and
Boeing 787 are examples of the problems of this nature (Subrahmanian and Rachuri, 2008). The infor-
mation integration within or across industrial sectors is still a dream. Regli and other researchers have
indicated the key technological issue of engineering informatics is “the apparent lack of fundamental
progress in areas of information integration” (Regli, 2007).
Before the need for engineering informatics was formally presented in 2007 and term “engineering
informatics” was coined in 2007 and 2008 (Subrahmanian and Rachuri, 2008; Regli, 2007), a scientific
and engineering discipline called Industrial Information Integration Engineering was formerly proposed
and recognized by international organizations International Federation for Information Processing (IFIP)
and the Industrial Information Integration Engineering (IEEE) in 2005.
In June 2005, at a meeting of the IFIP Technical Committee for Information Systems (TC8) held at
Guimarães, Portugal, the committee members intensively discussed and formally recognized the import-
ant role played by industrial information integration and the innovative and unique characteristics of IIIE
as a scientific sub-discipline (Roode, 2005; Raffai, 2007). IIIE is a set of foundational concepts and tech-
niques that facilitate the industrial information integration process; specifically speaking, IIIE comprises
methods for solving complex problems when developing IT infrastructure for industrial sectors, especially
in the aspect of information integration. It was decided at this meeting that the IFIP First International
Conference on Research and Practical Issues of Enterprise Information Systems (CONFENIS, 2006)
would be held in Vienna, Austria. In August 2006, at the IFIP 2006 World Computer Congress held
in Santiago, Chile, the IFIP TC8 WG8.9 Enterprise Information Systems was established. In 2007, the
Enterprise Information Systems Technical Committee was established within the IEEE SMC Society. To
further respond to the needs of both academicians and practitioners for communicating and publishing
their research outcomes, the science and engineering journal entitled Enterprise Information Systems, was
launched in 2007 (Figure 13.2). In 2016, the science and engineering journal entitled Journal of Industrial
Information Integration, exclusively devoting itself to the topics of IIIE, will be launched (Elsevier, 2016).
186
 Engineering Informatics – State of the Art and Future Trends

Figure 13.2. IIIE Discipline History

The concept of IIIE emphasizes multiple aspects, including one of the major aspects that completely
overlaps with the scope of engineering informatics: engineering information integration.
This chapter is focused on one of the major aspects of IIIE that completely overlaps with the scope
of engineering informatics: engineering information integration. The objective of this article is to intro-
duce to the communities of engineering and engineering informatics the current development and future
opportunities that exist in engineering information integration, but it is by no means meant to be exhaus-
tive. In Section II, we briefly discuss the relationship between engineering integration and engineering
information integration. Section III describes major techniques or technologies in engineering informa-
tion integration applicable to engineering informatics, while Section IV concludes this paper.

13.2 Overview of Engineering Information Integration

13.2.1 IIIE-A New Discipline of Industrial Information Integration
Broadly speaking, IIIE is a set of foundation concepts and techniques that facilitate the industrial infor-
mation integration process; specifically speaking, IIIE comprises methods for solving complex problems
in developing information technology infrastructure for industrial sectors, especially in the aspect of
information integration (Xu, 2015). IIIE has been proposed and studied through identifying its the-
oretical foundation, body of knowledge, frameworks, theories, and models at multiple levels. The key
research questions addressed include: (1) what is the scientific foundation that will provide IIIE with the
disciplinary support at the levels of frameworks, theories, and models? (2) And, at each level of IIIE (i.e.,
frameworks, theories, and models/techniques), how can real-world problem solving support be provided?
IIIE is an interdisciplinary discipline with the typical characteristics of giant and complex system. Accord-
ing to the subsystems that make up a system, the number of subsystems involved, and the degree of com-
plexity involved with the subsystems, the overall system can be categorized either as a simple system or as
a giant system. If a system is made up of a huge number of subsystems, the system is referred to as a giant
system. In addition, if a system has a numerous subsystems and layers and if the relationships among the
subsystems and layers are complicated, the system is referred to as a complex giant system.
As an interdisciplinary discipline, IIIE interacts with scientific disciplines such as mathematics,
computer science, and almost every engineering discipline among the twelve engineering disciplines
defined by the National Academy of Engineering in the U.S. The National Academy of Engineering is
organized into 12 sections, each representing a broad engineering category. IIIE interacts with almost
every one of them in separate layers. In terms of scientific and engineering methods, at the methodolog-
187
Engineering Management Handbook

ical layer, IIIE interacts with computer science and engineering, industrial systems engineering, informa-
tion systems engineering, and interdisciplinary engineering. In terms of developing and implementing
enterprise systems in different industrial sectors, at the application layer, IIIE interacts with aerospace
engineering, bioengineering, civil engineering, energy engineering, communication engineering, material
engineering, and earth resources engineering. In addition to the scientific and engineering disciplines, IIIE
also interacts with management and social sciences. For example, any effective engineering process relies
on effective management. As a result, the perspectives for the workflows that are commonly modeled and
represented include managerial perspective. Based on the definition of management defined (Xu and Xu,
2011), in a broad sense, management is the most comprehensive science that covers all the disciplines.
Judging from these, IIIE is defined as a complex giant system that can advance and integrate the concepts,
theory, and methods in each relevant discipline and opens up a new discipline for the industry informa-
tion integration purposes, which is characterized by its interdisciplinary nature. Figure 13.3 shows IIIE
at the top level; relevant scientific, engineering, management, and social science disciplines at the second
level; and application engineering fields at the third level. At the fourth level and the levels below, many
relevant frameworks, theories, and models can be listed.

Figure 13.3. Discipline Structure of IIIE

Figure 13.3 can be huge in size in order to cover all of the details involved. For example, enterprise
interoperability is involved with frameworks such as the ATHENA Interoperability Framework, Business
Interoperability Parameters, the CEN/ISSS eBusiness Roadmap, C4 Interoperability Framework (C4IF),
the IDEAS Interoperability Framework, the European Interoperability Framework, Levels of Conceptual
Interoperability, Levels of Information System Interoperability (LISI) C4ISR, NATO C3 Technical Archi-
tecture (NC3TA), and the Organizational Interoperability Maturity Model.

13.2.2 Engineering Integration

In today’s global competition atmosphere, industrial systems including engineering systems need to be
constantly and smoothly reengineered in order to allow them to respond to the fluctuating market and to

188
 Engineering Informatics – State of the Art and Future Trends

technological evolution. In 1980s, traditionally, MRP II systems interface with engineering design systems
to receive BOM and routing information. However, the interface is not always advanced, as it is unable to
pass critical information back to the engineering design system. In 2000, engineering integration became
one of the main components of enterprise systems (Langenwalter, 2000). Figure 13.4 shows the relation-
ship between engineering integration, manufacturing integration, customer integration, and enterprise
integration.

Figure 13.4. The Relationship Between Engineering Integration, Manufacturing Integration, Customer Inte-
gration, and Enterprise Integration

In general, about 90% of a product’s cost is determined during its design cycle; its quality charac-
teristics are also determined during the product design stage. In a typical product development process
(such as in plastic injection mold design), the design information flow may not be well supported by the
existing systems. If associative relations among engineering features were not available through the system,
data consistency and design changes would be difficult to manage. At different stages of a product’s life
cycle, from its requirement specifications to its conceptual design to its more detailed structure design
and finally to its production, engineering knowledge must be integrated. A complete integration includes
the design process, product data management, integration with customers, integration with suppliers,
integration with the rest of the organization, and project management. The ways in which the engineering
division integrates with the rest of divisions in an enterprise have been intensively researched.
According to Kulvatunyou and Wysk (2000), integration can be classified into three types:
1. Data-oriented integration, which integrates CAD, CAPP, CAM, and CIM;
2. Structure-oriented integration, which is an implementation of team-oriented concepts, such as the
use of a simultaneous engineering team, a concurrent engineering team, and an integrated product
and process development team;
3. Procedure-oriented integration, which refers to concurrent engineering-enabling technologies include
QFD, the Taguchi method, axiomatic design, and design for manufacturing and assembly.

In concurrent engineering, all of the engineering processes should be supported by integrated com-
puter-aided tools, and should be based on a consistent set of data with different application views. Such
applications include conceptual design, structural design, detailed design, design analysis for certain spe-
cific engineering aspects, computer-aided process planning (CAPP), and computer-aided manufacturing
(CAM) tool path generation, etc. However, this desirable scenario has not been fully realized due to the
interoperability limitations of different software packages.
189
Engineering Management Handbook

A concurrent design process consists of many design activities that are interrelated with each other.
Concurrent design has become increasingly important in designing complex products. When it is imple-
mented in manufacturing enterprise systems along with engineering integration, it is likely to generate
better design. Numerous concurrent design techniques have been developed, such as PERT (Project
Evaluation and Review Technique), ISM (Interpretative Structure Modeling), DSM (Design Structure
Matrix), Petri nets, and polychromatic sets. Each of these methods has some weakness. For example,
PERT is useful for the design processes in which activities have a clear sequential relationship. However,
it is inflexible and therefore unable to include feedback information and the iterative characteristics of the
concurrent design. Using the adjacent matrix, ISM and DSM can apply partitioning algorithms and other
algorithms in the concurrent design process. Although the Petri net is suitable for modeling concurrent
processes, it does not have sufficient capacity to represent data flow or handle computational complexity.
UML is a graphical and visual modeling language. Integrating UML with polychromatic sets provides a
powerful tool for modeling and analyzing concurrent design processes. UML has been applied in concur-
rent design such that a UML model of concurrent design process has been developed and mapped into a
polychromatic sets contour matrix model. Using this novel modeling and analysis method for a concur-
rent design process based on UML and polychromatic sets, the concurrent design process can be modeled
formally and analyzed quantitatively, and the major factors that affect the concurrent design process can
be considered.
In the CAD/CAM field, the comprehensive design of dimensional and geometric tolerances for
mechanical products using computers is called Computer Aided Tolerancing (CAT). This is a focal point
of research in CAD/CAM. In the process of product design and manufacturing, the tolerance values of
a mechanical part are closely related to its manufacturing process, which not only influences the quality
of product but also affects the manufacturing cost. So far, considerable research has been conducted on
CAT analysis and synthesis, tolerance information modeling and representation, concurrent tolerance
design, dynamic tolerance control, and tolerance information verification. The research covers: (1) the
concept for determining the geometric shape and the dimensional and geometric tolerance of a part using
a computer. Based on this, designed dimensions and tolerances of the part with a geometric shape can
be described using mathematical formulae; (2) the method to control the tolerance of design and man-
ufacturing using computerized dimension chain; (3) the theory of tolerance, which defines the concept
of tolerance according to the offset values of the real entity of a part and provides a theoretical basis for
its CAT design; (4) the concept of virtual boundary requirements (VBRs), which describe tolerance and
conditional tolerance; (5) TTRS (Topologically and Technologically Related Surfaces) theory, which
establishes the important theoretical foundation for dimensional tolerance and geometric modeling in the
CAD system; (6) and the theory based on wavelet and fractal technology with application in designing
the tolerance.
With the continuous development of CAT technology, a number of tolerance models have been
proposed, such as attribute models, parametric models, kinematic, and DOF models. In attribute models,
a tolerance can be directly stored as an attribute of either geometric entities or metric relations. Offset
models can obtain the maximal and minimal object volumes by offsetting the object by corresponding
amounts on either side of the nominal boundary. However, they cannot distinguish the interactions of
different tolerance types. Parametric models represent tolerances as ± variations of dimensional or shape
parameters. In current CAD systems, the modeling method for parametric models has been widely
applied. Kinematic models use vector additions to analyze tolerances. A kinematic link is used between a
tolerance zone and its datum features. TTRS models have many similarities to DOF models.
With the development of three-dimensional (3D) CAD system, it has become urgent to construct a 3D
dimension chain and to comprehensively design dimensional and geometric tolerances. Researchers have put
forward the Variational Geometric Constraint (VGC) theory, which can effectively handle the comprehen-
sive design of dimensional and geometric tolerance, although with some difficulties in computation.
In CAD/CAM technology, the importance of CAT research has been emphasized by researchers.
Consequently, CAT research is becoming more and more popular. The polychromatic sets theory has been
applied in CAT. Based on the VGC theory and TTRS theory, a hierarchical reasoning model of toler-

190
 Engineering Informatics – State of the Art and Future Trends

ance information is developed that applies the polychromatic sets theory to describe the model, optimizes
computer-aided generation of tolerance types, and provides a basis for developing tolerance network and
designing tolerance. The research introduces the application of the hierarchical reasoning model as well
as its reasoning method, based on assembly-oriented tolerance generation. Polychromatic sets theory is
a mathematical theory tool that is regarded as a promising approach for many applications. Due to the
idea and the theory that were developed, namely to use a standardized mathematical model to simulate
different objects, the techniques of polychromatic sets have been widely applied to areas such as product
life-cycle simulation, product conceptual design, concurrent engineering, and virtual manufacturing for
product modeling, process modeling, and process optimization.
In recent years, engineering design has required more and more multidisciplinary design activities.
Engineering designers from a number of different disciplinary areas may interact and exchange in the de-
sign process. Therefore, seamless integration and efficient processing of engineering data among numerous
heterogeneous data sources plays an important role in engineering design. Hence, engineering integration
is assumed to support multidisciplinary engineering design activities throughout product development
cycles. The ubiquitous characteristics of data diversity, irregularity, and heterogeneity will distinctively
differentiate engineering information integration from information integration in other domains in IIIE.
This poses a challenge to effective engineering integration. There has been much ongoing research in this
area. The topics cover: (1) the methodology for developing a virtualization-based simulation platform in
support of multidisciplinary design of complex products; (2) approaches for engineering software inte-
gration and product data exchange to support interoperability among different engineering phases; (3)
mathematical formulation and optimization method for engineering problems; (4) autogenetic design
theory and distributed computing approaches and their applications to multidisciplinary design optimi-
zation; and (5) web services-based multidisciplinary design optimization frameworks, which provide data
exchange services and integration.
The research on engineering integration is becoming more prevalent now. Research has recently been
conducted on the methods and models for large-scale engineering projects.

13.3 Enabling Technologies

In this section, we will introduce the main enabling technologies for engineering informatics as well as
IIIE, which include business process management, information integration and interoperability, enterprise
architecture and enterprise application integration, and service-oriented architecture (SOA).
Rapid advances in industrial information integration methods have spurred tremendous growth of
a variety of techniques. These techniques include business process management, workflow management,
EAI, SOA, and others. Many applications require a combination of these techniques. At present, we are
at a new breakpoint in the evolution of selected enabling technologies.

13.3.1 Business Process Management

Engineering design process modeling can inherit methods and approaches developed in business process
management. Theiben, Hai and Marquardt (2008) introduced a methodology for modeling, improving,
and implementing design processes in chemical engineering. The method inherits some methods devel-
oped in the domain of business process reengineering and workflow management (Theiben, Hai, and
Marquardt, 2008).
IIIE enables the integration of business processes throughout an organization with the help of Busi-
ness Process Management (BPM). BPM is an approach that is focused on aligning all of the aspects of an
industrial organization in order to promote process effectiveness and efficiency with the help of informa-
tion technology. Through business process modeling, BPM can help industries standardize and optimize
business process, increasing their agility in responding to the changing environment for competitive
advantage, accomplishing business process reengineering, and realizing cost reduction.
Process modeling is an interesting topic in IIIE and engineering informatics. The modeling, moni-
toring, and controlling of industrial processes is important, as it enables us to understand and optimize
191
Engineering Management Handbook

such processes. Manufacturing process modeling is a typical example. All process details in a manufactur-
ing process that relate to the desired outputs of the process need to be understood. In general, a precise
process model that relates processes is required. As such, modeling manufacturing processes is important
as it enables manufacturers to understand the process and to optimize the process operation. Modeling
industrial control is an example also. Such modeling draws the domain expertise of multiple disciplines/
subjects including ICT, process technology, and factory automation, and industrial communication sys-
tems. Process modeling results can be applied to process automation and factory automation. The control
and predictive capability of business process management also offers useful insights into quite a few engi-
neering fields covered in Figure 13.3. As previously mentioned, IIIE is interdisciplinary. Industrial process
modeling can be listed in Figure 13.3 at a level below Level 3; as such, the industrial process control
itself is a complex interdisciplinary subject. To track process-related information and the status of each
instance of the process as it moves through an organization, the concept of workflow becomes important.
Workflow systems have been considered as efficient tools that enable the business process management,
the business process reengineering, and eventually the automation of organizational business processes.
Workflow management provides increased process efficiency through improved information availability,
process standardization, task assignment on an automatic basis, and process monitoring using specific
management tools (i.e., WfMS). Although workflow monitoring and management spans a broad continu-
um, the key idea of workflow management is to track process-related information.
When the first prototype of a workflow system was developed, the early idea of automation of
business processes was initiated. Workflow management allows managing workflows for different types
of processes, facilitating process automation and providing predictive capabilities, and it enables organiza-
tions to maintain control over their processes. Business processes and their related workflow systems have
gained greater interest since the early 1990s; research about enterprise business processes and workflows
has become a prominent area that attracts attention both from academia and industry.
A workflow consists of a number of tasks that need to be carried out and a set of conditions that
determine the order of the tasks. The Workflow Management Coalition (WMC) defines a workflow as
a computerized facilitation for the automation of a business process, in whole or in part. Three types of
workflows are generally recognized in literature. A production workflow is associated with routine process-
es, and is characterized by a fixed definition of tasks and an order of execution. An ad hoc workflow is asso-
ciated with non-routine processes, which could result in a novel situation. In an administrative workflow,
cases follow a well-defined procedure, but alternative routing of a case is possible. Compared with the
other two types, production workflows correspond to critical business processes and possess high potential
to add value to the organization. Hence, the administrative workflow is usually the focus of most studies
on workflow modeling.
Workflow management has been considered to be an efficient way of monitoring, controlling, and
optimizing business processes through information technology support and is playing an important role
in improving an organization’s performance through the automation of its business processes. Process
modeling is not only expected to automate business processes within the organization, but also to auto-
mate inter-organizational business processes. As such, more efforts have been focused on the integration
of inter-organizational systems to form inter-organizational architecture. For this purpose, it is necessary
to study both intra- and inter-organizational business processes with a scientific approach. IIIE is required
for addressing complex business processes taking place within and beyond the enterprise. Not only does
the intra-organizational business process need to be addressed, but also so does the inter-organizational
process.
Today, workflow systems are increasingly applied to cooperative business domains including coop-
erative engineering design, and they are inter-organizational. As such, workflow management needs to
be completed on an inter-organizational basis. Inter-organizational business process management also pro-
vides enterprises the opportunity to reshape their business processes beyond their organizational bound-
aries. A changing business environment requires an organization to dynamically and frequently adjust
and integrate both its intra- and inter-organizational processes. Additional benefits of interconnecting
business processes across systems and organizations include higher degrees of integration and the facilita-
tion of the information and material flows.
192
 Engineering Informatics – State of the Art and Future Trends

Inter-organizational workflows are comprised of intra- and inter-organization workflows. Wolfert et

al. (2010) defined intra- and inter- integration and process and application integration in this way: in-
tra-organizational integration overcomes fragmentation between organizational units; inter-organizational
integration integrates enterprises in the supply chain; process integration aligns tasks through coordination;
and application integration aligns software systems to reach cross-system interoperability.
Process integration, as mentioned earlier, is one of main types of integrations and can be either intra-
or inter-organizational. Due to the closed connections and transformations between process management
and workflow management, an intra- and inter-organizational workflow management capability can en-
hance the performance of intra- and inter-organizational integration. Inter-enterprise workflow architec-
ture supports the interoperations between independent enterprises. Meanwhile, an intra- and inter-orga-
nizational workflow management capability can also enhance information sharing at both the intra- and
inter-organizational levels, eventually enabling all of the partners in the extended supply chain system to
better collaborate, to optimize operations, and to gain competitive advantage.
WfMS defines, manages, and executes workflows through the execution of software. WfMS has be-
come a standard solution for managing complicated processes in many organizations since its appearance
in the early 1990s. Despite a few failures associated with the introduction of WfMS, workflow technology
has managed to become an indispensable part of enterprise systems. Workflow technology can be used
to improve the business process and to increase performance, since the improvement can be quantified
with respect to lead-time, wait time, service time, utilization of resources, etc. WfMS can be employed as
a repository of valuable process knowledge and can act as a vehicle for collecting and distributing knowl-
edge across the supply chain. WfMS can also be used as a platform for knowledge sharing and learning
inter-organizationally, and allows the knowledge workers in each organization to perform creative intellec-
tual activities.
Practicing inter-organizational workflow management requires coping with technical challenges. The
complex nature of business processes, particularly processes spread across multiple organizations, presents
technical challenges. Most traditional workflow management systems assume one centralized enactment
service, are only able to support workflows within one organization, and have problems in dealing with
workflows crossing organizational boundaries. It is critical to ensure that technical problems such as in-
consistency do not arise due to the lack of transparency across different organizations.
Workflow research can be viewed in terms of three layers. The first layer pertains to issues about
intra-organizational workflows, which link activities between the different units within one organiza-
tion. The second layer corresponds to inter-organizational workflows, which cover distributed processes
between different organizations, both of which comprise the inter-organizational workflow. The third
layer concerns the workflows in e-business settings. Effective management of business processes relies on
sophisticated workflow modeling and analysis.
Among the modeling techniques, most of them have shown the capability in graphical representation
and formal semantics in modeling workflows in an intra-organizational context. Currently, there is an ur-
gent demand for translation between various models so that different workflow management systems can
interoperate with each other. This could lead to methods that will enable the integration of heterogeneous
models within a unified framework.
The existing modeling techniques have advantages as well as disadvantages. Efforts regarding inter-or-
ganizational workflow modeling are exploring the better architectures in order to combine different orga-
nizational workflows while continuing to reconcile the differences. Some approaches have been specifically
proposed for modeling inter-organizational workflows, such as the routing approach and the interaction
model. Some cognitive approaches have been proposed for the dynamic routing of information; mean-
while, new languages have been proposed to handle the routing of information among organizations.
In terms of evaluation, qualitative evaluation methods mainly focus on checking for structural
soundness, which can usually be done through the validation and verification of workflows. Quantitative
evaluation methods require the calculation of performance indices related to workflows. The existing tech-
niques include computational simulation, the Markovian chain, and queuing theory, among others.
At present, in the area of workflow management, there has been great interest in service workflow
modeling and security management. SwSpec is a service workflow specification language that allows arbi-
193
Engineering Management Handbook

trary services in a workflow to formally and uniformly impose requirements. System flexibility has been
considered to be a major functionality of workflow systems. More research is needed for such functional-
ity in order to provide sufficient flexibility for coping with complex business processes. Other topics for
research include the communication among multi-workflows in complicated business process, simplifying
the workflow modeling process, and automating workflows, among other topics. Existing techniques in
process modeling still have limitations as they attempt to address only some of the modeling aspects. For
example, business process models may contain numerous elements with complex intricate interrelation-
ships. Efforts are needed to address how to properly capture such complexities.

13.3.2 Information Integration and Interoperabilty

Subrahmanian and Rachuri (2008) indicated the numerous incompatibilities in information exchange
and coordination. The delays that occurred in Airbus 380 and Boeing 787 are examples of the problems
of this nature (Suvrahmanian and Rachuri, 2008). The information integration within or across industrial
sectors is still a dream. Regli and other researchers have indicated the key technological issue of engineer-
ing informatics is “the apparent lack of fundamental progress in areas of information integration” (Regli,
2007). Although there has been several different explorations of different theories of design and manu-
facturing, progresses yet to be made that can provide effective methods for information integration (Broy,
2006).
Today’s businesses of all sizes need to share data with suppliers, distributors, and customers. Informa-
tion integration is not only significant for large-scale enterprise or for supply chain integration, but also
at the microscopic level. Compressed product development cycles and lifetimes and just-in-time stocking
imply that management systems must be interconnected, and the applications composing the information
systems of enterprises increasingly need to work together. As such, the demand for integration has been
increasing.
As a consequence of such developments, enterprise systems are increasingly moving toward inter-or-
ganizational integration as the benefits of inter-organizational information sharing become obvious. An
inter-organizational system is aimed at providing a higher-level system related to activities that involve
the coordination of business processes (both intra- and inter-organizational) and is able to provide an
integrated architecture to organizations within the supply chain. Now, more efforts have been focused
on inter-organizational systems, and more and more enterprises have moved toward inter-organizational
integration in order to support supply chain management. Inter-organizational systems are able to allow
communication between partners in the supply chain. Integrated enterprise systems can collect valuable
management information for all of the related business processes across the supply chain. By using inte-
grated supply chain management, organizations can better predict their markets, can better innovate in
response to market conditions, and can better align their operations across supply chain networks.
The integration of inter-organizational systems is a complex task for most enterprises. Several frame-
works have been proposed for information integration. Fox, Chionglo and Barbuceanu (1993) indicated
that at the core of the supply chain management system lays a generic enterprise model. Hasselbring
(2000) proposed a three-layer architecture for integrating different types of architectures. In Puschmann
and Alt’s (2004) framework, the data level is considered as a separate layer. Giachetti’s (2004) framework
includes a typical characterization of the different types of integration. However, as indicated by Wolfert
et al. (2010), the contents of these frameworks are not comprehensive, and an overall framework of infor-
mation integration has yet to be developed.
The current level of engineering integration may be limited by the sophistication of the relevant
technologies or by the lack of techniques, and the successful execution relies upon more sophisticated
IIIE integration than what is currently available. It is expected that IIIE integration will attract more
efficient and effective methods for automated engineering management in which the seamless integration
of inter-organizational systems is highly expected. Among the new technologies, IoT and radio frequency
identification (RFID) have attracted much attention. RFID is a contactless and low-power wireless com-
munication technology that has application in many areas of the supply chain. The envisioned applica-
tions include information to be collected from a network of RFID sensors and IoT combined.
194
 Engineering Informatics – State of the Art and Future Trends

13.3.3 Enterprise Architecture and Enterprise Application Integration

“Interdisciplinary collaborations will be especially important for implementing comprehensive processes
that can integrate the design of mechanical systems with the design of electrical systems and software.
Successful collaborations, however, will first require overcoming incompatibilities between emerging
technologies and the existing technological infrastructure and organizational cultures” (National Science
Foundation, 2004). To industrial organizations, an enterprise can be an organization, a part of a larger
enterprise, or an extended enterprise. An enterprise architecture (EA) defines the scope of the enterprise,
the internal structure of the enterprise, and its relationship with the environment. As it describes the
structure of an enterprise, it comprises main enterprise components such as enterprise goals, organization-
al structures, and business process, as well as information infrastructure. An EA is generally considered
an important aid for understanding and designing an enterprise. Just as information infrastructure is a
component of EA and the term enterprise as used in EA generally involves information systems employed
by an industrial organization, EA is highly relevant to IIIE, since IIIE concerns information flow within
the entire industrial organization.
Enterprise architects use a variety of business models, conceptual tools, and analytical methods to
describe the structure and dynamics of an enterprise. Artifacts are used to describe the logical organization
of business processes and business functions, as well as information architecture and information flow. A
collection of these artifacts is considered to be its EA. Software architecture, network architecture, and
database architecture are partial components of an information architecture.
An EA’s landscape is usually divided into various domains that allow enterprise architects to describe
an enterprise from a number of important perspectives. One of the main domains in EA is the infor-
mation domain. The important components in this domain include information architecture and data
architecture. The other two domains with components that are also highly relevant to IIIE are the Appli-
cation Domain and its component “interfaces between applications” and Technology Domain with its
components as middleware, networking, and operating systems.
Representing the architecture of an enterprise correctly and logically will improve the performance of
an organization. This includes innovations about the structure of an organization, business process reengi-
neering, and the quality and timeliness of the information flow that represents material flows.
Enterprise integration has become a key issue for many enterprises looking to extend business pro-
cesses through integrating and streamlining processes both internally and with partners in the supply
chain. It consists of plans, methods, and tools. Typically, an enterprise has existing legacy systems that are
expected to continue in service while adding or migrating to a new set of applications. Integrating data
and applications is expected to be accomplished without requiring significant changes to existing applica-
tions and/or data. To address this issue, a solution that can help to achieve quality integration is referred
to as Enterprise Application Integration (EAI). Originally, EAI was only focused on integrating enterprise
systems with intra-organizational applications, but now it has been expanded to cover aspects of inter-or-
ganizational integration. EAI facilitates the integration of both intra- and inter-organizational systems.
Major EAI-enabling technologies range from EDI to web services and XML-based process integration and
provide a flexible, adaptable, and scalable EAI framework. Solutions comprise the efficient integration of
diverse business processes and data across the enterprises, the interoperation and integration of intra- and
inter-organizational enterprise applications, the conversion of varied data representations among involving
systems, and the connection of proprietary/legacy data sources, enterprise systems, applications, processes,
and workflows inter-organizationally.
EAI entails integrating enterprise data sources and applications so that business data and processes
can be easily shared. EAI must be able to integrate the heterogeneous applications that are created with
different methods and on different platforms. The integration of enterprise applications includes the inte-
gration of data, business processes, applications, and platforms, as well as integration standards. Through
creating an integrative structure, EAI connects heterogeneous data sources, systems, and applications
intra- or inter-organizationally. EAI aims to not only connect the current and new system processes, but
also to provide a flexible and convenient process integration mechanism. By using EAI, intra- or inter-or-

195
Engineering Management Handbook

ganizational systems can be integrated seamlessly to ensure that different divisions or even enterprises can
cooperate to each other, even using different systems. A complete EAI offers functions such as business
process integration and information integration, since the core of the EAI technology is business process
management. Through the coordination of the business processes of multiple enterprise applications and
the combination of software, hardware, and standards together, enterprise systems can exchange and share
data seamlessly in a supply chain environment.
In general, those enterprise applications that were not designed as interoperable need to be integrat-
ed on an intra- and/or inter-organizational basis. As such, legacy and newer systems are expected to be
integrated to provide greater competitive advantages. The constantly changing business requirements and
the need for adapting to the rapid changes in the supply chain may require help from service-oriented
architecture (SOA).
EAI provides the integration of both intra- and inter-organizational systems and databases and is
moving toward integrating ES with both intra- and inter-organizational applications. The objective of
EAI is to facilitate information exchange among business enterprises in a timely, accurate, and consistent
fashion, in order to support business operations in a manner that appears to be seamless.

13.3.4 Service-oriented Architecture (SOA)

Srinivasan, Lammer and Vettermann (2008) indicated the importance of SOA in engineering informatics.
Their paper describes how product information sharing service was architected and implemented using
SOA. SOA represents the latest trend in integrating heterogeneous systems that has great potential in en-
gineering informatics. It has received much attention as an architecture for integrating platforms, proto-
cols, and legacy systems, and it has been considered as a suitable paradigm that helps integration, since it
is characterized by simplicity, flexibility, and adaptability.
SOA represents an emerging paradigm for engineering informatics to use in order to coordinate
seamlessly in the environment of heterogeneous information systems, enabling the timely sharing of in-
formation in the cooperative systems, and developing flexible large-scale software systems for engineering
applications. Some example applications include the information integration based on SOA in agri-food
industry (Wolfert et al., 2010), among others.

13.4 Summary and Challenges

Although the technologies and applications introduced in this chapter are currently not yet fully used
in industry, they are expected to have great potential to play a major role in near future. Efforts focusing
on blending the capabilities of existing technology and the emerging technologies are needed. With this
blending, industries will be able to harness the power of current and emerging technologies to dramati-
cally improve the performance of industrial information integration including engineering informatics by
adopting new technologies.
Research indicates that the successful engineering informatics practice relies more upon sophisticated
technologies than those that are available now. Research also indicates that training engineers with the
capacity of using engineering informatics presents a challenge to us (Subrahmanian and Rachuri, 2008).
Although there has been several different explorations of different theories of design and manufacturing,
progresses yet to be made that can provide effective methods for information integration (Broy, 2006).
Lack of a single stakeholder is another challenge. As such, it is difficult to evaluate economic costs and
benefits of information interoperability (Broy, 2006). In addition, developing universal metrics for in-
formation integration and solving “system of systems” design can also be challenging (Broy, 2006). The
interdisciplinary nature of engineering informatics implies another challenge as the complexity level rising
as it involves a multiplicity of informatics and a variety of engineering subjects.
There are still many challenges and issues that need to be resolved in order for IIIE and engineering
informatics to become more applicable. Engineering informatics involves complexity that mainly stems
from their high dimensionality and complexity. In recent years, there have been significant developments
in this newly emerging technology, as well as actual and potential applications; however, the development
of advanced methodologies, especially formal methods and a systems approach, have to be synched with
196
 Engineering Informatics – State of the Art and Future Trends

the rapid technological developments. For engineering informatics, there exists a gap between the level
of complexity inherent and the rich set of formal methods that could potentially contribute. Despite
advancements in the field of IIIE and engineering informatics, both in academia and industry, significant
challenges still remain. Both IIIE and engineering informatics will continue to embrace cutting-edge tech-
nology and techniques, and will open up new applications that will impact industrial sectors. IIIE and
engineering informatics can and will contribute to the success of this endeavor.

13.5 References
Broy, M., “The ‘Grand Challenge’ in Informatics: Engineering Software-Intensive Systems,” IEEE Com-
puter, October 2006, pp. 72-80.
Elsevier, Journal of Industrial Information Integration, vol. 1, no. 1, 2016.
Fox, M., Chionglo, J., and Barbuceanu, M., The Integrated Supply Chain Management System, University
of Toronto, 1993.
Giachetti, R., “A Framework to Review the Information Integration of the Enterprise,” International Jour-
nal of Production Research, vol. 42, no. 6, 2004, pp. 1147-1166.
Hasselbring, W., “Information System Integration,” Communications of ACM, vol. 43, no. 4, 2000,
pp. 32-38.
Kulvatunyou, B., and Wysk, R., “A Functional Approach to Enterprise-based Engineering Integration,”
Journal of Manufacturing Systems, vol. 19, no. 3, 2000, pp. 156-171.
Langenwalter, G., Enterprise Resource Planning and Beyond. Boca Raton, FL: St. Lucie Press, 2000.
National Academy of Engineering, “Educating the Engineers of 2020: Adapting Engineering Education
to the New Century,” 2005, p. 10.
National Research Council, “Improving Engineering Design: Designing for Competitive Advantage,”
1991, p. 55.
National Research Council, “Information Technology for Manufacturing: A Research Agenda,” 1995,
p. 81.
National Science Foundation, “ED2030: A Strategic Plan for Engineering Design,” 2004, p. 10.
Puschmann, T., and Alt, R., “Enterprise Application Integration Systems and Architecture-the Case of the
Robert Bosch Group,” Journal of Enterprise Information Management, vol. 17, no. 2, 2004, pp. 105-
116.
Raffai, M., “New Working Group in IFIP TC8 Information Systems Committee: WG8.9 Working
Group on Enterprise Information Systems,” SEFBIS Journal, vol. 2, 2007, pp. 4-8.
Regli, W., “The Need for a Science of Engineering Informatics,” Artificial Intelligence for Engineering De-
sign, Analysis and Manufacturing, vol. 21, 2007, pp. 23-26.
Roode, R., “IFIP General Assembly September 2005. Report from Technical Committee 8 (Information
Systems),” Gaborone, Botswana, August 27, 2005.
Srinivasan, V., Lammer, L., and Vettermann, S., “On Architecting and Implementing a Product Informa-
tion Sharing Service,” Journal of Computing and Information Science in Engineering, vol. 8, 2008.
Subrahmanian, E., and Rachuri, S., “Guest Editorial Special Issue on Engineering Informatics,” Journal of
Computing and Information Science in Engineering, vol. 8, 2008.
Theiben, M., Hai, R., and Marquardt, W., “Design Process Modeling in Chemical Engineering,” Journal
of Computing and Information Science in Engineering, vol. 8, 2008.
Turk, Z., “Construction Informatics: Definition and Ontology,” Advanced Engineering Informatics, vol.
20, 2006, pp. 187-199.
Wolfert, J., et al., “Organizing Information Integration in Agri-Food-a Method based on a Service-ori-
ented Architecture and Living Lab Approach,” Computers and Electronics in Agriculture, vol. 70, no. 2,
2010, pp. 389-405.
Xu, L., Enterprise Integration and Information Architecture, New York: CRC Press, 2015.
Xu, S., and Xu, L., “Management: A Scientific Discipline for Humanity,” Information Technology and
Management, vol. 12, no. 2, 2011, pp. 51-54.

197
198
 Basic Accounting and Finance

14
Basic Accounting and Finance

Donald N. Merino
Stevens Institute of Technology

199
Engineering Management Handbook

14.1 Introduction
14.1.1 Importance of Accounting to Engineers
Why is accounting important to engineers? One reason was that engineers needed to know the cost and
profitability of the products they design. For example, look at the ever-changing technology of your PC.
What drives these changes? The continual increase in the cost performance of new chips, printed circuit
boards, disc drives, etc. all result in new and improved products being offered every year.
For companies and governments involved in research and engineering, Design for Cost (DFC) and
Cost as an Independent Variable (Systems Engineering, Concurrent Engineering) are the most recent con-
cepts that help define the synergy between economics and engineering. Knowledge of basic accounting
and finance are essential to understand this concept.

14.1.2 Accounting and Engineering Economics

Economic studies for capital project selection depend on estimates of cash flows. You do not have to be a
professional accountant or estimator to make an economic analysis. A practitioner of engineering eco-
nomics is expected to understand the fundamentals of both disciplines. The data on which such forecasts
are based come from many sources, but the most important source is accounting records.

14.1.3 What is Accounting?

Accounting in its simplest form is scorekeeping—it is observing, measuring, recording, classifying, and
summarizing the financial data associated with the multitude of transactions occurring in the operation of
a business. As such, the accounting function is historical, not predictive. Other non-accounting instru-
ments are predictive, such as sales forecasts, production plans, expense budgets, and cash flows. However,
they are usually based, at least in part, on solid historical accounting data. If that is the only purpose, one
might ask why keep score? In reality, the main purpose of maintaining good accounting data is to have it
available for use in decision-making.

14.1.4 Users of Accounting Information

Many people use accounting information in order to make financial decisions. The following are some
examples:
• Individuals: You and I use accounting information to manage bank accounts, to make investments,
and to make decisions concerning many different types of purchases.
• Business: In corporations, the managers of the organization use accounting information to determine
accountability for past activities and as a basis of decision-making for future events.
• Investors and Creditors: These are people who may decide invest money in the organization. They
use accounting information to evaluate risk and return on a prospective investment, i.e., as an aid in
making the decision to invest or not.
• Regulators: Examples of regulators include the Securities Exchange Commission (SEC), Internal
Revenue Services (IRS), and other Tax Collectors. These organizations use accounting information
to evaluate managers’ adherence to proper, prescribed procedures and their overall managerial perfor-
mance.

14.2 Basic Accounting

14.2.1 Introduction
The following tutorial will help you get a better understanding of the concepts and principles of basic
accounting. You should fully understand this tutorial before moving on to the next one. These ideas will
be critical to fully grasping the information that is presented later.
This section presents information on the various types of accounting entities, accounting transactions,
basic accounting terminology, and financial statement terminology, including the well-known “accounting
equation.” This basic section will not only help you better understand financial accounting and engineer-
200
 Basic Accounting and Finance

ing economics, but also give you insights and knowledge to help you read and interpret financial reports,
such as SEC filings and personal or corporate tax information.

14.2.2 Financial Accounting

Accounting is the management discipline that deals with the financial condition and the financial
performance of economic entities by recording, analyzing, and reporting the transactions in which they
engage in order to assess their current performance and to forecast their future performance.

Entities
Entities are the bounded systems whose financial records may be examined to determine their state of
financial health. There are two types of entities, for-profit and not-for-profit. A convenient classification
follows:
• For-profit (business) entities
• Sole proprietorships
• Partnerships
• Corporations
• Not-for-profit entities
• Private-sector organizations (usually charitable or religious)
• Public-sector organizations (government)

The above classification does not include you, the individual consumer, but when an accountant helps
you prepare your income tax return, you are an economic entity.
The capital selection process applies to both for-profit and not-for-profit entities. Business entities
are found in the private sector of the economy. However, there are public sector entities that compete and
function much like their private counterparts. Utility companies which are owned by national or local
governments are one of many examples. For these and other not-for-profit entities, the terms “profit” and
“loss” are replaced with “surplus” and “deficit” respectively.
For profit economic entities include sole proprietorships, which are owned by one individual; part-
nerships, which are owned by two or more individuals; and corporations, which are owned by a few or
many shareholders. The sole proprietorship is the most common form of business entity, but corporations
are dominant in terms of revenues and profits. Table 14.1 compares the three forms for the year 2000.

Table 14.1. Comparison of Types of Business Entities

Business Annual Receipts

Number Dollars
(Millions) Percentage (Billions) Percentage

Proprietorships (non-farm) 20.6 77.1% 1,139 4.94%

Partnerships 1.00 3.74% 2,316 10.04%
Corporations 5.10 19.1% 19,593 85.01%
26.70 100% 23,048 100%

Ref: U.S. Bureau of the Census, Statistical Abstract of the United States, 2004

201
Engineering Management Handbook

Proprietorships and partnerships are not “legal entities” in the eyes of the law. That is, they do not
have an independent identity under the law. Therefore, their owners are fully responsible for their acts and
obligations, and creditors can, if necessary, go beyond the assets of the business to seek the personal assets
of the owners in order to satisfy their claims.
Corporations, on the other hand, are “legal entities.” Their shareholders have limited liability, which
means that corporations are responsible for their own acts and obligations. Creditors can rely only on
corporate assets for the satisfaction of their claims, not those of shareholders, employees or members of
the board of directors.
Proprietorships and partnerships are generally managed by their owners; corporations are not. The
shareholders elect a board of directors, which appoints executives to serve as managers. In short, owner-
ship and management are divorced (and, as a result, the interests of the managers may conflict with those
of the shareholders!).
Examples of not-for-profit entities in the private sector include universities, schools, hospitals, muse-
ums, and charitable organizations. Examples are also found in the public sector, but these function under
the aegis of federal, state, and local governments, which are economic entities, along with school districts,
water sanitary districts, public utility and transit authorities, and all other governmental bodies subject to
financial review.
Thus, economic entities can be as large as a global corporation or as small as the corner newsstand.
They can be an entire organization or one of its parts, and, as mentioned, they can also include you and
the author of this tutorial.
Next, our attention will be focused on corporations and governmental entities because these are the
major disbursers of money for capital outlays.

14.2.3 Transactions
A transaction is a piece of business—a sale, a purchase, a borrowing, the repayment of a loan, the pay-
ment for a service, the issuance of stock, the repurchase of stock, and so on. Transactions allow entities
to function. Transactions, when properly recorded, analyzed, and reported give us the financial condition
and the financial performance of economic entities.

14.2.4 Financial Condition

The “financial condition” of an entity is its financial state of health or well-being at any given point in
time. It is an assessment based on information reported in the firm’s financial statements. One critically
important financial statement (report) is called the “balance sheet” or, more formally, “the statement of
financial condition.” This statement is a “snapshot” or an instantaneous view of the balances of the firm’s
accounts at the time that the statement is prepared. (Note: while the Balance Sheet represents the bal-
ance of accounts at one specific point in time, the Income Statement and Statement of Cash Flow show
the sum effect of all transactions entered into by the firm over a stated period of time.) The points of time
usually selected for publication of the financial statements are at the end of (1) each month, of (2) each
quarter, and of (3) each year. Monthly issues of the balance sheet are primarily for use by management
and might not be disseminated to the public. Quarterly and annual issues are generally published for use
by those stakeholders who need to know or wish to know an entity’s current financial condition; stake-
holders include lenders, suppliers, creditors, and shareholders.

14.2.5 Financial Statement Terminology

Account
The “account” is the basic unit for recording information of a firm’s financial database. Accounts are
grouped into three basic types—assets, liabilities and owner’s equity. An account is a detailed record of
the transactions affecting one or more of these three types. Under the present, widely-used system, each
transaction affects at least two accounts, hence the name “double entry accounting system.”
202
 Basic Accounting and Finance

Asset
An asset is a resource that an entity owns or controls in order to achieve a future benefit (profit, share of
market, and competitive advantage). Some examples of assets are cash, inventory, accounts receivable,
equipment, furniture, land, and buildings.
• Cash: This account shows the amount of money that a company holds in currency or in its bank
account.
• Inventory: This account reflects the cost (and possibly the quantity) of goods, held for use or
intended for sale, that a company owns. Merchandise (goods intended for sale to customers) is
recorded as an asset when it is purchased or when it is produced. In addition, raw materials (in-
tended for use in production) are also considered to be inventory. The inventory account increases
when inventory is purchased or produced and, conversely, decreases when the goods are sold or the
materials are used.
• Accounts Receivable: This account shows the amount of credit sales the firm has made, that is deliv-
ery of goods or services to customers who then say “Charge it!” or “Bill me…I’ll pay you later.” It is
the amount of money that customers owe to the company and have promised to pay in the future for
goods and services that they have already received. When the customers do pay, accounts receivable
decreases and cash increases.
• Notes Receivable: A promissory note that says that the customer is going to pay an agreed upon
amount in the future.
• Equipment and Furniture: The original (historical) cost of each item of equipment and furniture
is entered (written into, keyed into) an asset account. This account, then, shows the original cost of
individual items and the total cost (investment) for all of the items.
• Land: This account records the cost of the land that is owned by a business.
• Buildings: This account records the initial cost of buildings owned by the business. Some examples
are factories, office buildings, distribution centers, etc.

Land and buildings deliberately purchased for resale are entered into a different account called an
“investment account.”

Liability
A liability is an obligation or debt that is payable to a creditor. Some examples of liabilities include ac-
counts payable and notes payable.
• Accounts Payable: This account is the opposite of accounts receivable; it is the amount that the busi-
ness owes to its suppliers as a result of credit purchases.
• Notes Payable: This account is the opposite of notes receivable. It is a promissory note stating that
the business will pay in the future for goods or services (previously) acquired on credit.

Owner’s Equity
Imagine that all of the assets of a firm were sold and the cash received was used to pay all of the firm’s
liabilities. The remaining cash (value) is called “owner’s equity.” Equity represents the value of the invest-
ment in a business by its owners. Following are accounts that affect owner’s equity:
• Revenues: For proprietorships, partnerships and corporations, revenue is the total of prices for goods
and services that customers agree to pay; revenue is earned through the sale of goods or services. Rev-
enues increase equity.
• Expenses: For proprietorships, partnerships and corporations, expenses are the cost of resources used
for producing and delivering goods or services to customers, e.g., rent, salaries, electricity, gas, etc.
Expenses decrease equity.
• Retained Earnings: For corporations the retained earnings account holds the value of the accumu-
lative profits and losses of the firm since its inception. These retained earnings (profits) are a major
source of the firm’s investment capital.
203
Engineering Management Handbook

• Capital: For proprietorships, partnerships and corporations, capital is the amount of the owner’s
investments over the lifetime of the business. Usually this investment takes the form of cash payments
for shares of the firm’s stock.
• Dividends and Withdrawals: For a proprietorship or partnership, cash amounts withdrawn (for-
mally) by the owner from the business to be used to pay personal expenses is called “withdrawals”
or “draw.” After making a withdrawal, the asset cash and the owner’s equity both decrease. For a
corporation, cash amounts paid to stockholders (not all corporations do this) is called “dividends.”
Interestingly, corporations cannot deduct dividends paid for income tax purposes. However, as with
withdrawals, dividends paid reduce both the cash account and equity.

Equity = Capital (initial and subsequent investments by owners)

+ Retained Earnings (through last year)
+ Revenue for this year
Expenses for this year
– Dividends/Withdrawals made this year

14.2.6 Financial Performance

An entity can be in good financial health and still perform badly—although not for long—by living off what
it has accumulated in the way of past profits. It can be in poor financial health and perform well; indicating
that its health is improving and, if good performance continues, then it will eventually “get well.” Financial
performance over a period of time—a month, a quarter, a year—is recorded, analyzed, and reported in the
“income statement” and in two additional statements that together constitute the key financial reports for an
economic entity—the “balance sheet” (see above), and the “statement of cash flows.”
Not-for-profit entities use similar statements with somewhat different names. The income statement,
for example, is often called the “statement of receipts and expenditures.” The owner’s equity statement is
the “statement of fund balances.” For many such entities, it is not possible to prepare balance sheets, be-
cause there is no way of determining the value of certain of their assets. This is particularly true for federal,
state, and local governments. How, for example, do you estimate the value of Yellowstone National Park?

14.2.7 Accounting Equation

The fundamental equation of accounting is the following:

Assets = Liabilities + Owner’s Equity

If the accounting statements do not result in the above equation being in balance, an accounting error has
taken place (or a fraud in as occurred!). CPA firms catch errors like unbalanced balance sheets.

14.3 Income Statement

14.3.1 Introduction
Income statements are read by managers, the SEC (Securities and Exchange Commission, a federal agen-
cy) and anyone who either owns stock or is interested in buying stock in a particular firm. The income
statement can give the reader a fair idea of management’s overall performance as measured in terms of
profitability revenue and revenue growth, costs, and changes in costs from year to year. The information
in the income statement is the basis for important ratios that can provide additional insights into the
efficiency and effectiveness with which the firm is being operated. It is important to note that the perfor-
mance portrayed in an income statement can differ substantially from one firm to another, depending in
large part on the industry in which the organization competes. For example, a natural resource company
(e.g., Phelps-Dodge) would likely have a different percentage of its revenue going to research and develop-
ment than would a pharmaceutical company (e.g., Merck).

204
 Basic Accounting and Finance

14.3.2 The Income Statement

When a product is sold to a customer “ready, willing, and able” to buy, the seller can immediately re-
cord the transaction as earned revenue. Because there are very few cash transactions in business these
days, it is quite common for the customer to ask the seller to put the amount of the sale
“on account” or to “bill me” for the price of the transactions. Therefore, even though no cash
changes hands at the time of the transaction, the seller must reflect in the income statement not
only the revenue (as noted above) but also the expenses incurred in earning the revenue. (This is in
accord with what is called the “Matching Principle,” an important concept within the “Generally
Accepted Accounting Principles” (GAAP) that govern accounting in the United States.) (Note: In
the Balance Sheet the effect of this type of transaction would be as follows: recognition of the reve-
nue would increase the value of the firm’s Equity; the customer’s promise to pay later would increase
Accounts Receivable, with the two aspect of the transaction not only keeping the Balance Sheet in
balance, but also exemplifies the “double entry” nature of the accounting system, because the trans-
action affected both of the two accounts “equity” and “accounts receivable.” In the unlikely event
that a customer does pay in cash, the only difference between that and the cashless example de-
scribed above is that the Cash account, not Accounts Receivable would be affected on the asset side
of the Balance Sheet.)
The expenses involved in producing goods or services that have been sold, matched as described
above in the Income Statement with the Revenue earned, are also amounts owed to their respective
suppliers. Once again, the Balance Sheet would be affected depending on how the suppliers are paid,
i.e., in cash (very unusual) or later when an invoice is received. If the suppliers are paid in cash, the
Balance Sheet would see a decrease in Equity by the amount of the expense incurred, and an increase in
(the Liability) Accounts Payable. If paid in cash, the (Asset account) cash would decrease and Accounts
Payable would not be affected. Either way, the balance sheet remains in balance and the equity accounts
accurately reflect the difference between the assets and the liabilities that belong to the owners.
If revenues exceed expenses during any given period, the earnings for the period are positive (that is, a
Profit is earned). If the difference is substantial (or, occasionally, even if it is not), management may decide
to distribute some of the earnings to the owners. These distributions, which are called “dividends” for
corporations and withdrawals (“draw”) for proprietorship and partnerships, reduce the equity of the firm
as well as (usually) the Cash account.
The portion of the earnings that is not distributed to owners accrues to the firm’s benefit as an in-
crease in Equity; the firm’s Retained Earnings and is a source of investment capital.
The statement of income equation for any given accounting period can be expressed as follows:

Revenues – Total Costs and Taxes = Earnings=Net Income

Letting R stand for revenue, C for costs and expenses and ∆E for increase in equity over the period (be-
fore any distribution to owners) gives us
R-C=∆E

The above equation is the model for statements of income. A typical example is given in Table 14.2

For our example, the revenues for the period are $800,000 (1). The total expenses before taxes are $
710,000 (CoGS of $500,000 (2) + G&A of $200,000 (4) + interest of $10,000 (6)), and the earnings be-
fore taxes, often referred to as the net income before taxes, would be the difference, or $ 90,000 (7). The
“net earnings” or income after taxes would be $75,000 (9). The total expenses of $710,000 are broken
down into three categories: the cost of goods and services sold (CoGS), which total $500,000 (2); the
Operating Expenses (includes General and Administrative expenses (G&A)), which total $200,000 (4);
and the miscellaneous expenses, such as interest payments on borrowed funds which total $10,000 (6).

205
Engineering Management Handbook

Table 14.2. A Typical Income Statement

XYZ Company
Income Statement for the Year Ending December 31, 200X
(1) Revenues $800,000
(2) Less cost of goods and services $500,000
(3) Gross profit $300,000
Less operating expenses
(4.1) Sales and marketing expenses $100,000
(4.2) General and administrative expenses $100,000
(4) Total operating expenses $200,000
(5) Income before taxes $100,000
(6) Less: Miscellaneous revenue and expenses (interest) $10,000
(7) Net income before income taxes (NIBT) $90,000
(8) Less: Income taxes $15,000
(9) Net income after income taxes (NIAT) $75,000

Earnings Before (After) Income Taxes are synonymous with Net Income Before (After) Income
Taxes. There may be depreciation expenses included in either or both cost of goods sold (for production
facilities and equipment) and operating expenses (for administrative facilities and equipment).
In general, Income Statements cover a one-year period, with the period or “fiscal year” ending at a
specified date, often December 31 of the corresponding calendar year. Many firms for various reasons
operate on a fiscal year that ends at a time other than December 31. Annual reports for public firms must
be audited by a certified public accounting (CPA) firm, and, if approved, carry the certification of the
auditors as well as of the firm’s top managers.

14.4 Balance Sheet

14.4.1 Introduction
The Balance Sheet represents the information related to the fundamental accounting equation outlined
in the prior chapters. Please review that section and any definitions of the accounts classified as Assets,
Liabilities, and Equity before continuing with this section. Companies report this information in annual
reports to shareholders and to the SEC, as this is a document that is required to be published annually.
The balance sheet will always be in balance unless there is an accounting error (or fraud).

14.4.2 The Balance Sheet

The financial condition of an entity is given by its assets (what it owns) and its liabilities (what it owes).
The difference between the two is ‘’owner’s equity,” which is also referred to as “net worth,” “net assets”
or just “equity”. As we have seen, the Balance Sheet summarizes and exhibits the account balances of the
firm in the categories: Assets, Liabilities and Equity. The Balance Sheet is sometimes called the “Statement
of Financial Condition.”
An important distinction is made between current assets and long-term assets, and current liabilities
and long-term liabilities. Assets, Liabilities, and Owner’s Equity are tied together by the fundamental
equation of accounting, which is as basic to accounting as the law of conservation of energy is to the natu-
ral sciences. The equation is:
Assets - Liabilities = Owner Equity

206
 Basic Accounting and Finance

Or, as it is usually written,

Assets= Liabilities + Owner Equity

Rewritten in equation form:

A= L + E
Where A = Assets, L = Liabilities, and E = Owners’ Equity

You can see and touch tangible assets. You can see and touch the pieces of paper that document
liabilities. However, you can’t touch equity, because it is nothing more than the difference that brings
balance sheets into balance. (That occurs when the two sides of the fundamental equation are, in fact,
equal.) Consider the house that you might have bought for $200,000 with a $175,000 mortgage. The
house is an asset; the mortgage is a liability. Your equity is the difference: $25,000. You can’t see, hear,
smell, or touch this difference, but you can see the house and you can touch the mortgage note in your
desk drawer.
Assets may be broken down into three categories, current, fixed and other. Current assets consist of
cash and items that can be quickly (usually within a year) converted into cash. Fixed assets (often called
“non-current” or “long term”) consist of land (property, which cannot be depreciated), plant (buildings)
and equipment (which are depreciable, if owned). Other assets include such intangibles as patents, copy-
rights and any other asset that is not classified as current or fixed. Sometimes these intangible assets are
considered long term because they have long expected useful lives.
Usually assets are listed beginning with the most liquid asset at the top and the least liquid at the
bottom. Therefore, current assets would precede fixed assets. Marketable securities such as U.S. Treasury
bills or certificates of deposit represent very liquid and short-term investments. Hence, they are frequently
viewed as a form of cash. Accounts receivable represent the total money owed to the firm by its customers.
Inventories include raw materials, work in process (partially finished goods), and finished goods held by
the firm. All of these would be considered to be current assets.
All assets are entered into the financial data base at their actual (“historical”) cost, which includes
transportation and installation costs, if applicable. The term “Net Fixed” means that the value displayed is
the difference between total fixed asset costs and the accumulated depreciation related to those assets. The
net value of fixed assets is called their “Book Value.”
Liabilities are broken down into two major categories, current and long-term (non-current). Current
liabilities are amounts due in one year or less. Long-term liabilities are due more than one year into the
future. Like assets, the liabilities and equity accounts are listed on the balance sheet from short-term to
long-term. Current liabilities include Accounts Payable (amounts owed for credit purchases by the firm),
Notes Payable, outstanding short-term loans (typically from commercial banks) and accruals, amounts
not yet paid, but owed for which a bill may not yet have been received. (Examples of accruals include tax-
es due to the government and wages due to employees.) Long-term debt represents that part of any debt
for which payment is not due in the next twelve months.
One important Balance Sheet term you should be familiar with is “Working Capital.” This is tech-
nically the difference between the values of the current assets and the current liabilities. Estimates of the
investment required for (the “infusion of ”) working capital enter into the capital project selection process.
A General Ledger is a summary of all of the organization’s accounts. An adjusted Trial Balance is pre-
pared from the General Ledger. It is used to organize the information from the general ledger to create the
Balance Sheet and Income Statement.
Equity is usually broken down into at least two major accounts. The first, paid-in capital (also called
Capital, Common Stock) is that portion of the difference between the assets and liabilities that was
contributed by owners both initially and whenever additional capital was needed. The second, retained
earnings, is that portion of the difference between assets and liabilities coming from Net Income, earned
from the production and sale of goods and services, that is, from earnings that were retained in the
business and not distributed as dividends to shareholders or as withdrawals to sole proprietors or partners.
Managers strive to make the difference between the assets and liabilities at the end of an account-
ing period larger than it was at the beginning of the accounting period by increasing retained earnings
207
Engineering Management Handbook

by earning profits for the firm. When achieved, this means that the value of the firm for the owners has
increased. We can formulate this objective very simply, as follows:
Let A1, L1 and E1 be the assets, liabilities, and equity at the beginning of the period and A2, L2 and
E2, the assets, liabilities and equity at the end of the period. By the balance sheet equation,

A1 –L1 = E1 and A2 – L2 = E2

Subtracting the first equation from the second gives

(A2-A1) – (L2 –L1) = (E2 – E1) or ∆ A - ∆ L = ∆ E

If ∆ E is positive, management has succeeded in increasing the difference between assets and liabilities
over the time period under study.
The assets total $ 550,000 (9) and the liabilities $200,000(14). The difference of $350,000((9)-(14))
is the equity. As shown in Table 14.3, ASEM LLC had the following items on its December 31, 200X
balance sheet:

Table 14.3. Assets, Liabilities, and Equity for ASEM LLC

Dates 200X
Cash and equivalents $73,000 31-Dec
Notes payable $33,000 31-Dec
Long-term debt $175,000 31-Dec
Accounts receivable, net $55,600 31-Dec
Non-depreciable assets $196,000 31-Dec
Deferred income tax liability $19,500 31-Dec
Accumulated retained earnings $180,000 1-Jan
Income taxes payable $23,000 31-Dec
Inventories $24,000 31-Dec
Prepaid expenses $9,000 31-Dec
Accumulated Net Worth $35,600 1-Jan
Property, plant and equipment, at initial cost $418,000 31-Dec
Accounts payable $33,700 31-Dec
Goodwill, patents and trademarks $12,300 31-Dec
Short-term Debt $21,200 31-Dec
Accumulated depreciation $178,000 31-Dec
Retained Earnings $19,900 31-Dec
Additional paid-in capital $69,000 31-Dec

208
 Basic Accounting and Finance

Table 14.4 contains the Balance Sheet for ASEM LLC, as of Dec 31, 200X.

Table 14.4. Balance Sheet for ASEM LLC

BALANCE SHEET (as of Dec. 31, 200X)

ASSETS LIABILITIES
Current Assets (<= 1 yr) Current Liabilities (<= 1 yr)
Cash and equivalents $73,000 Accounts payable $33,700
Accounts receivable, net $55,600 Short-term debt $21,200
Inventories $24,000 Income taxes payable $23,000
Prepaid expenses $9,000 Notes payable $33,000

Total Current Assets $161,600 Total Current Liabilities $110,900

Fixed Assets (>= 1 yr) Long Term Liabilities (>= 1 yr)

Non-depreciable assets $196,000 Long-term debt $175,000
Depreciable assets: Deferred income tax liability $19,500
Property, plant and equipment, at initial
$418,000
cost
(Less) Accumulated depreciation $178,000
Net depreciable asset, at book value $240,000
Total Long Term Liabilities $194,500
Total Fixed Assets $436,000 Total Liabilities $305,400

Intangible Assets STOCKHOLDER’S EQUITY

Goodwill, patents and trademarks $12,300 Accumulated retained earnings $180,000
(Add) Retained earnings carried over from
$19,900
Income Statement
Accumulated Net Worth $35,600
Additional paid-in capital $69,000
Total Intangible Assets $12,300
Total Stockholder’s Equity $304,500
Total Liabilities &
Total Assets $609,900 $609,900
Stockholder’s Equity

14.5 Stockholder’s (Owner’s) Equity

14.5.1 Introduction
The stockholder’s equity was chosen to be expanded upon because it is often the most confusing aspect
of the balance sheet and the basic accounting equation. Assets and liabilities are more easily understood,
whereas stockholder’s equity is a more abstract concept. It is always important to note that if the accoun-
tant knows the value of assets and liabilities, he or she can easily calculate stockholder’s equity.

209
Engineering Management Handbook

14.5.2 Stockholder’s Equity

This tutorial is an extension of section 4—the Balance Sheet. While there are multiple sources of equity,
the two primary sources of equity are:
• The amount provided directly by equity investors, which is called the total Paid-In Capital.
• The amount retained from profits (or earnings)—that is, the amount of net income that has not been
paid to owners in the form of dividends—which is called Retained Earnings.

Creditors can sue the entity if the amounts due to them are not paid. Owners (Equity Investors)
have only a residual claim; that is, if the entity is dissolved, they are entitled to whatever is left after the
liabilities have been paid. Therefore, liabilities are the primary claim against the assets and equity is the
secondary claim.
We can describe the right-hand side of the balance sheet in two distinct, but correct ways:
1. As the amount of funds supplied by creditors and owners
2. As the claims of these parties against the firm’s assets

The equity section is often labeled “Shareholder’s Equity” or “Owner’s Equity.” Equity consists of
capital obtained from sources that are not liabilities. Table 14.3 shows the two sources of equity capital:
1. $275,000, which is labeled “Paid-in Capital”; and
2. $75,000, which is labeled “Retained Earnings”

Table 14.5. Two Sources of Equity Capital for Shareholder’s Equity

Dec. 31, 200X

Paid-in Capital* $ 275,000
Retained Earnings** $ 75,000
Total Stockholder’s Equity $ 350,000

Assume that a company’s retained earnings in the fiscal year 200X + 1 is $100,000 (Paid-In Capital is
held constant). Then, the Stockholder’s equity for the following year is shown in Table 14.6:

Table 14.6. Stockholder’s Equity Based Upon Two Sources of Equity Capital

Dec. 31, 200X + 1

Paid-in Capital* $ 275,000
Retained Earnings** $ 175,000
Total Stockholder’s Equity $ 450,000

* Paid-in capital amount comes from previous year’s balance sheet.

** Retained earnings are computed as follows

Retained Earnings for 200X + 1 = Retained Earnings for 200X + Net Income after Taxes (less dividends, if any)
for 200X + 1.

14.5.3 Paid-In Capital

Paid-In Capital is the amount of capital supplied by equity investors. They own the corresponding equity
(shares of stock representing the value to the owners of the firm). The details of how this item is report-
ed depend on the type of organization. XYZ Company is a corporation, and its owners receive shares
of common stock as evidence of their ownership. Therefore, they are called Shareholders (or Stockhold-
ers). Individual shareholders may sell their stock to another person, but this has no effect on the balance
sheet of the corporation. The market price of shares of Microsoft changes practically every day, but the
210
 Basic Accounting and Finance

amount of Paid-In Capital reported on the Microsoft balance sheet is not affected by these changes. This
is consistent with the entity concept: that is, transactions between individual shareholders do not affect
the Balance Sheet of the entity (the economic entity “Microsoft” is distinct from the economic entities
“individual stockholders”).

14.5.4 Retained Earnings

The other equity item, $75,000, shows the amount of equity that has been earned by the profitable opera-
tions of the company and that has been retained in the entity; hence the name, Retained Earnings.
Retained Earnings represents those amounts that have been retained in the entity after some part (or
none, for some firms) of the company’s earnings (i.e., profits) has been paid to shareholders in the form of
dividends. In the form of an equation:

Retained Earnings = Earnings – Dividends

Retained Earnings are additions to equity that have accumulated since the entity began, not those of a
single year. The amount of Retained Earnings shows the amount of capital generated by operating activi-
ties and retained in the entity. It is important to note that retained earnings are not cash. Cash is an asset.

14.5.5 Example of Retained Earnings

ASEM Corp. had the following items on its December 31, 200X Stockholder’s Equity Statement as
shown in Table 14.7.

Table 14.7. ASEM Corporations Stockholder’s Equity Statement on December 31, 200X

Dates 200X
Accumulated Retained Earnings $273,500 1-Jan
Retained Earnings ($29,600) Jan 1 - Dec 31
Accumulated Net Worth $320,000 1-Jan
Additional Paid-In Capital $71,000 31-Dec

Using the given data, prepare the Stockholder’s Equity Statement for ASEM Corp., as of December 31,
200X is shown in Table 14.8.

Table 14.8. Stockholders’ Equity Statement for ASEM Corp as of December 31, 200X

TOTAL STOCKHOLDER’S EQUITY (as of Dec. 31, 200X)

Accumulated retained earnings $273,500
(Add) Retained earnings carried over from Income Statement ($29,600)
Accumulated retained earnings $243,900
Accumulated net worth $320,000
Additional paid-in capital $71,000
Total Stockholder’s Equity $634,900

14.6 Cash Flow Statement

14.6.1 Introduction
You have already become familiar with the Income Statement and Balance Sheet. The Cash Flow Statement
is the last of the major financial statements that would be taught in an introductory course in accounting.

211
Engineering Management Handbook

The Cash Flow Statement essentially converts the accrual basis of accounting that is used to create the
Income Statement and Balance Sheet into a cash basis. Although the accrual style is helpful in analyzing
revenues and expenses, organizations also find it useful to have an understanding about the amount of
cash the organization has at its disposal.

14.6.2 The Cash Flow Statement

Financial management probably spends more time recording, analyzing, and forecasting cash flow than any
other financial matter. The reporting is summarized in a statement of cash flows (cash flow statement) in
which the analysis starts at the beginning of the period Table 14.9 shows an example. The difference, which
is either positive or negative (or possibly zero), is analyzed by breaking down the cash flow into three parts:
• Cash flow from operating activities, that is, running the business on a daily basis (i.e., cash received
from selling a product/service and paying the related expenses)
• Cash flow from investing activities (i.e., cash flows related to buying and selling the facilities in which
the firm operates and from purchasing/selling businesses—mergers and acquisitions)
• Cash flow from financing activities (i.e., cash related to taking out and repaying loans, buying and
selling stocks/bonds and paying dividends).
• Or economic studies on project selection, estimates of future cash inflows and outflows from operat-
ing activities are prepared with the help of pro forma income statements (forecasts of income).

Table 14.9 contains an example of cash flow reporting.

Table 14.9. Cash Flow Statement

XYZ Company
Statement of Cash Flows, 200X
Cash Flow from Operating Activities
Net Income………………………………………………………………$75,000
Adjustments:
Depreciation Expense… …………………$100,000
Changes in working capital accounts:
Decrease in accounts receivable……..…$20,000
Increase in Inventory……………………..$(40,000)*
Decrease in accounts payable…………..$(30,000)*
Increase in accrued wages………..…… $40,000
Change in working capital……………………..$(10,000)*
Total adjustments to net income……………................................$90,000

Total cash flow from operations………………………….…….…..$165,000

Cash Flow from Investing Activities

Purchase of plant………………………………$(60,000)*
Total cash flow from Investing Activities....................................$(60,000)*

Cash Flow from Financing Activities

Issuance of long-term debt………………………. $10,000
Dividends paid…………………………………… $(12,000)*
Total cash flow from Investing Activities.....................................$(2,000)*

Net increase in cash and cash equivalents……….………………$103,000

* Parentheses indicate decreases in cash

Note: Cash Flow statements can be prepared using two different methods, each of which determines the same, correct end-
ing balance of cash; the methods are the direct method and the indirect method. Differences in the two methods lie only in the
212
 Basic Accounting and Finance

Operating Activities section. The description below uses the indirect method to prepare the Cash Flow statement.
The first section of the cash flow statement (Table 9.4) reports how much cash was generated by the
operating activities of the period; that is, from the day-to-day activities that bring cash in from customers
and pay cash out to employees and suppliers. To do this, we must first convert net income—the bottom
line of the net income statement—from an accrual basis to a cash basis. “Cash flow from operating activ-
ities” is the difference between operating cash inflows and operating cash outflows.
The second part of the cash flow statement reports cash flows from investing activities: acquisition
of new fixed assets and cash inflows from sale of existing assets. The acquisition amount may not be an
immediate net decrease in cash because the payment of cash may have been partially or completely offset
by borrowing an equal amount (loans). Nevertheless, whatever amount of cash was paid is recorded as a
cash outflow, and the amount of the borrowing is recorded separately as a financing activity.
Companies may obtain cash by issuing debt securities, such as bonds or stock. These are called
financing activities. Cash flows from financing activities include cash receipts or disbursements from
one or all of the following: the sale of stock by a corporation to provide paid-in capital, entering into a
long-term loan, repaying the loan, and distributing dividends or drawings. However, Interest payments on
borrowed funds are not treated as financial activities but as operating activities.
In the selection process, we usually start with the assumption that the first cost and the working cap-
ital (the funds needed to “set up shop” before cash flows in from sales) for a new venture are supplied by
equity financing, that is, by investors rather than creditors. If the results are favorable, we then examine a
mixture of equity and creditor financing or even consider leasing to conserve cash.
The three groups of activities that affect cash flow—operating, financing, and investing—are all
involved in the cash flow patterns to help analyze capital investment opportunities. The above discussion
shows the cash flow statement for a company.

14.6.3 Example of Cash Flow Statement

Table 14.10 and 14.11 contains for Merino Realty had the following items on its December 31, 200X
Income Statement and the associated Cash Flow Statement. Note that the income tax bracket for the
company is 35%.

Table 14.10. Revenue and Expenses for Merino Realty

Dates 200X
Revenues $334,000 Jan 1 - Dec 31
Interest expense $14,600 Jan 1 - Dec 31
Cost of sales (Cost of Goods Sold) $197,400 Jan 1 - Dec 31
Administrative Salary Expense $23,400 Jan 1 - Dec 31
Insurance Expense $12,300 Jan 1 - Dec 31
Depreciation Expense $27,700 Jan 1 - Dec 31
Dividends paid $3,200 Jan 1 - Dec 31
Interest income $6,500 Jan 1 - Dec 31
Selling and administrative expenses $58,000 Jan 1 - Dec 31

The income tax bracket for the company is 35%.

213
Engineering Management Handbook

Using previously given information, Table 14.11 is the Cash Flow from the Income Statement.

Table 14.11. Cash Flow from Merino Reality Income Statement

CASH FLOW FROM INCOME STATEMENT (Jan. 1 - Dec. 31, 200X)

Revenues $334,000
(Less) Cost of sales (Cost of Goods Sold) $197,400
Gross Margin $136,600
(Less) Selling and administrative expenses $58,000
(Less) Administrative Salary Expense $23,400
Operating Income $55,200
(Add) Interest income $6,500
(Less) Interest expense $14,600
(Less) Insurance Expense $12,300
(Less) Depreciation $27,700
Income Before Taxes $7,100
(Less) Provision for income taxes $2,485
Net Income $4,615
Dividend Paid $3,200
Net Income after Dividend $1,415
Add back Depreciation $27,700
Cash Flow from Income Statement $29,115

14.7 Depreciation
14.7.1 Introduction
Depreciation is a methodology used by organizations to distribute the cost of a capital asset over a long
period of time. For example, if a company invests in an expensive super computer, the company is
required by tax law in the U.S. to allocate the cost of that computer over a span of a few years, using the
depreciation technique. If the company did not do this, the year in which the company bought the super-
computer would probably result in financial statements that are significantly worse than the year before. It
is important to note that depreciation is considered a non-cash expense.
Depreciation is often a difficult subject to grasp for students. You may need to review this tutorial
two or more times before you fully grasp the concept, or you can review the textbook.

14.7.2 Depreciation
Depreciation is the expense associated with allocating the cost of a capital asset (except land) over its
useful life. Land, being appreciable, is not depreciated. All other capital assets that a company buys are
depreciated. The portion of the first cost of an asset that is consumed through use over a period of time is
called depreciation (depreciation expense).

14.7.3 Depreciation Terminology

First Cost (Historical Cost)

It is the original price paid for an asset, i.e., the price at which the asset was acquired, including transpor-
tation and installation.

214
 Basic Accounting and Finance

Estimated Useful Life

It is the length of service the business expects to get from an asset. Some define useful life as the length of
time that a “prudent manager” would decide to use the asset.

Accumulated Depreciation
This account is used to show the cumulative sum of all depreciation expense for an asset from the date
on which the asset is acquired. The balance of this account increases over the life of the asset that is being
depreciated.

Book Value
It is the first cost of a depreciable asset, less its accumulated depreciation.

Book Value = First Cost - Accumulated Depreciation

Depreciable Cost
Depreciable cost can be defined as:

Depreciable Cost = First Cost of the Asset – Estimated Salvage Value

Estimated Salvage Value

It is also known as estimated residual value, or scrap value. It is the expected cash value of an asset if sold
at the end of its useful life.

Plant Assets Disposal

Plant assets have a useful life. When these plant assets cease to be productive, they are usually disposed of.
They can be sold, exchanged or scrapped. When they are sold, a gain or loss on the transaction may be
incurred. It is a gain (technically called a “depreciation recovery”) if the asset is sold for more than its book
value and it is a loss if the asset is sold for less than its book value. We will explain how to calculate the
after tax amounts in section 14.8.3.

14.7.4 Depreciation Methods

The depreciable cost of eligible capital assets is expensed over its estimated useful life. Tax authorities allow
various depreciation methods to be used, and so there are a number of methods for calculating depreci-
ation. We will discuss (1) the straight-line method, (2) MACRS, and (3) the double-declining balance
method.

Straight-Line Method
Straight Line Depreciation Per Year = First Cost - Salvage Value
Useful Life in Years

An equal amount of depreciation expense is assigned to each year of the asset’s useful life. The depre-
ciable cost is divided by the useful life in years to determine the annual depreciation expense.

SL Example: A computer is purchased for $2,200 on January 2001. The salvage value of the comput-
er is $200 and its useful life is four years.
Calculate, using Straight Line method,
• Depreciation expense
• Accumulated depreciation at end of each year
• Book value at the end of the year for each year of useful life of the asset
215
Engineering Management Handbook

SL Depreciation = Cost – Salvage

No.Years

SL Depr. = 2200 – 200 = 500

4
SL Depr Rate = 1 = 1 = 0.25 = 25%
Useful life 4

Table 14.12 presents depreciation schedule for this example.

Table 14.12. SL Depreciation Example

Initial Asset Depreciation Depreciable Depreciation Accumulated Asset Book

Year Cost Rate Cost Amount Depreciation Value
$2,200 $2,200
1 0.25 $2,000 $500 $500 $1,700
2 0.25 $2,000 $500 $1,000 $1,200
3 0.25 $2,000 $500 $1,500 $700
4 0.25 $2,000 $500 $2,000 $200

Thus, Annual Depreciation Amount = Depreciation Rate X Depreciable Cost = (.25 X 2000) = $500 / yr

Depreciable Cost = Cost - Salvage Value = $2200 -$200 = $2000

Note that at the end of amortization, the Book Value must equal the estimated Salvage Value.

MACRS: Modified Accelerated Cost Recovery System

MACRS is mandatory for the federal tax returns under Tax Reform Act of 1986. An accelerated method
similar to the double-declining balance method, it allows deducting larger amounts during the first years
of the asset’s life. The depreciation of a particular asset depends on the classification of that asset. MACRS
defines eight property classes (3 years, 5 years, 7 years, 10 years, 15 years, 20 years, and two real proper-
ty classes). These property classes and the applicable MACRS rates can be referred from Chapter 16 of
Lang/Merino text. To determine the annual depreciation expense for an asset using MACRS, first locate
the asset in the appropriate property class table. In the table, find the year of ownership for the asset and
multiply the first cost of the asset by the percentage given in the table for that year of ownership.

MACRS Example
Stevens acquired, for an installed cost of $40,000, a machine having a recovery period of five years. Using
the applicable MACRS rates, the depreciation expense each year is shown in Table 14.13.

216
 Basic Accounting and Finance

Table 14.13. MACRS Depreciation Example

Year Cost (in $) (1) Percentages (%) (2) Depreciation (in $) (1 * 2 = 3)

1 40,000 20 8,000
2 40,000 32 12,800
3 40,000 19 7,600
4 40,000 12 4,800
5 40,000 12 4,800
6 40,000 5 2,000
TOTAL 100% 40,000

Double-Declining Balance Method

This method is an accelerated depreciation method as MACRS is. This method calculates depreciation
by allocating larger amounts to the depreciation expense account in the earlier periods of the useful life
compared with the later periods.
It computes annual depreciation by multiplying the asset’s book value by a constant rate, which is two
times the straight-line depreciation rate.
There is much more on depreciation. However, at this time you should be aware that the depreciable
life of an asset (the period of time over which its cost is prorated) does not have to be, and often is not,
the same as its useful life. Accelerated depreciation and inflation often bring the book value of an asset far
below its market value, which is why the discussion that follows on gains and losses from the disposal of
assets is important.1

14.7.5 Gains and Losses from the Disposal of Assets

Gains and losses from the disposal of assets result from the differences between market value and book value.
If market value exceeds book value, there is a gain; if it is less, there is a loss. Consider the following example:

Fair Market Value = FMV; Book Value = BV

Tax Rate = TR; FMV – BV = Taxable Gain/ Loss
Taxable Gain/ Loss * TR = Taxes; After Tax Entry = FMV – Taxes

Example: (Gains and Losses)—The car bought for $30,000 is sold for a cash payment of $20,000 at
the end of two years, at which time its book value is $18,000 ($30,000 less two years of accumulated de-
preciation at $6,000 per year). Its market value on the day of sales is therefore $2,000 more than its book
value. The tax rate is 40%.

FMV-BV = Taxable
Capital Gains: $20,000 – $18,000 = $2,000
Taxes: $2,000 * 0.4 = $800
After Tax Cash Flow: $20,000 - $800 = $19,200

This completes our overview of accounting. The concepts presented here can be understood by one
more example given later in the tutorial. We hope you have found this discipline a more conceptual and
stimulating subject than its image as “bookkeeping” usually conveys.

14.8 After Tax Analysis

14.8.1 Introduction
The section is related to prior chapters on the Income Statement, Balance Sheet, Cash Flow Statement
and Depreciation. You may wish to review those topics before continuing with this section.
217
Engineering Management Handbook

The tax code is very complicated for individuals and corporation in the United States. You probably,
at some point in your life, have filled a tax return with the Internal Revenue Service (IRS). Organizations
have an even more daunting task with more complicated rules.

14.8.2 After Tax Analysis and Cash Flow

The taxes paid and tax related items like depreciation and investment tax credits have a significant impact
on the economics of all aspects of corporate activity, but particularly on Capital Investment.
Economic decision-making is based on Cash Flows (not accounting profit). If you take a course in
Corporate/Managerial Finance you will find that corporations are managed on the Cash Flow.
In Section 14.6 (Cash Flow) you saw that Cash Flows can be generated as part of:
• Operating Activities
• Capital/Finance Activities

Operating cash flows can be determined from the Income Statement. Note that an operating cash
flow is Net Income after Tax plus depreciation. Remember that depreciation is a non-cash (accrual) ex-
pense. Operating cash flows are periodic over a number of years.
Capital Cash Flows can be determined from the Balance Sheet. There are a number of activities that
impact the Capital Cash Flows. Change in inventory levels, financing activities and capital expenditure
are some of these activities. For engineering economics we are interested in investments for depreciable
(plant, equipment, etc.) and non-depreciable (land) capital. For capital projects we are also interested in
loans (to finance capital) and the after tax sale/disposal of capital at the end of the project.
In the following sections we will provide the calculations and format for
• Net Cash Flow from Operating Activity
• Net Cash Flow from Capital Activity

as well as the After Tax Cash flows for

• Depreciation
• Loans/Borrowings
• Salvage/Disposal of Capital Items

14.8.3 After Tax Cash Flow from Depreciation Charges

Section 14.7 described various depreciation methods and how to calculate them. Note that depreciation
is a non-cash (accrual) entry and as such is added back to the Net Income after tax to yield the cash flow
from operating activities.

14.8.4 After Tax Cash Flow from Investment Tax Credit

From time to time government/agencies (U.S., State and sometime local) give incentives for business to
make capital Investments. This is usually during a recession or natural disaster (like Hurricane Katrina)
and is designed to increase capital spending.
Why Capital Spending? The concept is that for every dollar spent on capital goods, the Gross Na-
tional Product (GNP and GDP) will increase many fold (6 to 8 times). In Macro-economics this is called
the “Multiplier Effect.” The Investment Tax Credit (ITC) allows a company to subtract some part of the
Capital purchase price from the Income Tax it pays.
For example, if the ITC is 10% and the company makes a $200,000 capital investment then the
company can deduct $20,000 from its taxes (usually in year 0 or 1). It is assumed that the company
will keep the Capital asset in service for a certain number of years. If it does not, it may have to give
back some of the ITC. This is called re-capture. You need to seek Tax Counsel on this matter because
the rules are complex. ITC for solar panels or energy saving items like Hybrids cars are examples that
apply to consumers.

218
 Basic Accounting and Finance

14.8.5 After Tax Cash Flows from Loans

The after tax analysis with loan repayment includes are the steps in Table 14.13 plus interest expenses. In-
terest is subtracted from the net cash flow before income taxes are calculated since interest is tax deduct-
ible, requiring it to be eliminated from the taxable income.
Interest charges benefit the organization because it reduces the taxable income and, hence, the income
taxes. The principal payments are being subtracted in Table 14.5 since principal is NOT tax deductible.
When dealing with loans, we need to understand the difference between interest and principal. Principal
is the actual amount you have borrowed or the remaining, unpaid balance owed to the lender. Interest is
most easily described as the fee charged by the lender for lending you the principal. It is usually expressed
in as annual percentage of the principal. Interest is generally tax deductible, meaning it REDUCES tax-
able income.
Table 14.14 provides an example on how to “amortize” a loan. The example assumes that the interest
rate is 10% and the loan is repaid in four years. The amount of the loan is $80,000. Annual payment is
calculated using the time value of money equation:
A = P (A/P, I, N) = $80,000(A/P, 10, 4)
A = $80,000 x .3155 = $25,240/year

Table 14.14. Loan Balance / Amortization Table

Beginning-of- year Annual Principal

Year Annual payment* Annual Interest End-of-Year Balance
balance Repayment
(1) (2) (3) (4) (5) (6)
10% of (2) (3) - (4) (2) – (5)
01 $80,000 $25,240 $8,000 $17,240 $62,760
02 $62,760 $25,240 $6,276 $18,964 $43,796
03 $43,796 $25,240 $4,380 $20,860 $22,936
04 $22,936 $25,240 $2,294 $22,936 0
Total 80,000

14.9 Accounting Process

14.9.1 Introduction
The accounting process is governed by laws to prevent fraud, insider trading, and unfair practices. This tu-
torial does not introduce these laws; however, you should note that if there is any doubt as to the ethics of
the accounting process in your organization, you should consult references available on the subject. Most
references guide you to practice methods introduced below.

14.9.2 The Accounting Process

The accounting process is a systematic and logical methodology for processing a myriad of transactions to
produce the financial statements on which managers, bankers, creditors, suppliers, and shareholders rely.
We highlight this process below but suggest that you also go to one or more of the suggested references
provided by your professor.

14.9.3 Double Entry Accounting

Double entry system of accounting means that each business transaction influences at least two accounts.
The accounting equation needs to balance, so if there is a change on one side of the equation, some
item(s) on the other side need to be changed to maintain the balance.

219
Engineering Management Handbook

The process begins with the journal or daily record of transactions. We know that every transaction
must be recorded in at least two accounts; otherwise, balance sheets would not balance. One of these ac-
counts is debited (entered on the left or “debit” side of the T-account), and the other is credited (entered
on the right of “credit” side of the T-account).
The words debit and credit refer to the left and right side of the T-account respectively for the purpos-
es below. Their abbreviations are dr. (debit) and cr. (credit). Each “simple” journal entry (a simple entry is
one that affects just two accounts) is therefore recorded as shown in Table 14.15.

Table 14.15. T-account Method of Recording Debits and Credits

Debit Credit

Name of first account $ XXXXXXX

Name of second account $ XXXXXXX

Note that accounting requires that the sum of all the debits pertaining to a transaction must equal the
sum of all the credit for those same transactions. Not shown, but part of the journal record of the transac-
tion, are the date, the amounts to be “posted” in the affected accounts and, if needed, a brief description
of the transaction.
Table 14.16 shows how assets, liabilities, and equity should be recorded.

Table 14.16. Location of Typical Items That are Posted

Increase in assets Debits

Decrease in assets Credits
Increase in liabilities Credits
Decrease in liabilities Debits
Increase in equity Credits
Decrease in equity Debits

14.10 Financial and Managerial Accounting

141.10.1 Introduction
This section covers cost-volume-profit (CVP) analysis. CVP analysis is the study of effects of output
volume on revenue (sales), expenses (costs) and net income (net profit). The most basic CVP analysis
computes the monthly break-even point in number of units and in dollar sales. To apply this analysis,
some simplifications must be assumed. The costs have to be simplified into fixed and variable costs.
Total Sales Revenue - Total Costs = Profits
Sales - Costs = Profits
Sales = Costs + Profits
Sales = Fixed Costs + Variable Costs + Profits

Therefore, the CVP equation can be written as:

Units sold * Selling Price per Unit = Fixed Costs + (Variable Cost per Unit * Units Sold) + Profits

14.10.2 Breakeven Analysis

The breakeven point is the point where the sales revenue equals the total costs and is demonstrated in
Figure 14.1. The breakeven point is the point where the sales revenue equals the total costs.

220
 Basic Accounting and Finance

Figure 14.1. Concept of Breakeven Analysis

Units Total Revenue

Total Cost

Profit

Breakeven Sales
(In Units)
Variable Cost

Fixed Cost

Loss

Dollars

As you can see, the net income is zero at the breakeven point.

14.10.3 Contribution Margin

It is the amount that covers fixed costs first and then provides profits for the period. When the contribu-
tion margin is higher than the fixed costs we have a profit, and when the contribution margin is lower
than the fixed costs, we have a loss. If the contribution margin is equal to the fixed costs, the profit is zero
and this point is called breakeven point.

Contribution Margin = Sales Revenue - Variable Costs

14.10.4 Contribution Margin Ratio

Contribution Margin Ratio is the proportion of each sales dollar available to cover fixed costs and provide
profits. It is the ratio of contribution margin to sales.

Contribution Margin Ratio = Contribution Margin

Sales

14.10.5 Breakeven Sales in Dollars

We get this equation in terms of the contribution margin ratio.

Sales = Fixed Costs + Variable Costs + Profits

Sales - Variable Costs = Fixed Costs + Profits

This equation can be rewritten in terms of the Contribution Margin if the equation is divided by
Sales on both sides.

Contribution Margin Ratio = Contribution Margin

Sales

Hence, Contribution
Margin Ratio = Fixed Costs + Profits
Sales

To calculate the breakeven sales, the profits are set at zero, and it gives us the following equation:

Contribution Margin Ratio = Fixed Costs

Breakeven Sales
221
Engineering Management Handbook

From this equation we get the Breakeven Sales,

Breakeven Sales = Fixed Cost
Contribution Margin Ratio

Breakeven Sales in Units = Fixed Costs

(Unit Selling Price – Variable Unit Cost)

14.10.6 Target Net Profit

To achieve the target net profit, the minimum amount of units that must be sold can be calculated as follows:

Selling Price per Unit * Units Sold = Fixed Costs + (Variable Cost per Unit*Units Sold) +
Target Net Profit

Units * (Selling price per unit - Variable Cost per Unit) = Fixed costs + Target Net Profit
Units * Unit Contribution Margin = Fixed Costs + Target Net Profit
Units to Earn Target Net Profit = (Fixed Costs + Target Net Profit) / Unit Contribution Margin

14.10.7 Sales to Achieve Target Return on Sales

Return on Sales, also known as Income percentage of revenue, helps you determine if the organization is
generating enough returns on the sales effort. Following is the formula used to calculate Return on Sales:

Return on Sales = Income / Revenue

14.10.8 Degree of Operating Leverage

Operating leverage ratio is the ratio of fixed to variable costs. A company has less leverage when the fixed
costs are lower than the variable costs. When the proportion of fixed costs in relation to variable costs is high,
the operating leverage is high, and the profits are more sensitive to changes in sales volume. The degree is a
measure of how changes in sales volume affect the profits. The lower the costs are for manufacturing a unit,
the higher the contribution margin per unit. This is why it is important to manage a good cost structure.

14.11 Advanced and Other Topics

This chapter covered the fundamentals of accounting, basic financial accounting, and some of the ad-
vanced topics in cost costing and cost estimation. Section 14.13 provides a mapping of all of the topics to
two standard references in the field.
The topics not covered in this chapter are as follows:

I. Basic Accounting—Fundamentals
A. Asset & Inventory: LIFO; FIFO
II. Basic Financial Accounting
A. Financial Ratios
B. Capital Structure of Firm
C. Stocks, Bonds and Financial Instruments
III. Advanced Cost Accounting—Fundamentals
G. Activity Based Costing (ABC)
H. Flexible & Master Budgets
I. Performance Assessments
J. Ethical Considerations—SoX
IV. Advanced Cost Estimation
A. Statistical Cost Estimation
B. Use of Cost Indices and Cost Factors
C. Design for Cost / Affordability / Target Costing

222
 Basic Accounting and Finance

14.12 Summary
One chapter can hardly cover the basics of accounting and finance other than a cursory presentation of
the subject matter. Yet, few subjects are more important in modern business than the understanding of
the finances of a corporation or an individual project. Engineering managers must understand the financ-
es of a business to provide value.

14.13 References
The following are two standard references in this field. The following table maps the topics in this chapter
to these references.

Merino, Donald N., Accounting for Engineers, Engineering Management Body of Knowledge, American
Society of Engineering Management, vol 1.1, Nov. 2007.
Riggs, Henry E., Financial and Cost Analysis for Engineering and Technology Management, John Wiley
& Sons, Inc., 1994, ISBN: 0-471-57415-5; ISBN (13): 978-0471574156.
Easton, Peter, Halsey, Robert, McAnally, Mary, and Hartgraves, Al, Financial & Managerial Accounting for
MBAs, 1st edition, Cambridge Business Publishers, 2008, ISBN: 0-9787279-1-6.

Topics Referenced to Standard Texts in the Field

References 1 2
Authors Riggs Easton, ..
I. Basic Accounting—Fundamentals
A Debits and Credits 3 1
B. Assets, Liabilities 3 1
C. Income, Expenses 3, 4 1,2
D. Equity Definitions 2 1-3
E. Income Statement 4 1-3
F. Balance Sheet 3 1-3
G. Cash Flow Statement 11 1-3
Integration of Income Statement; Balance Sheet and Cash Flow
H. 2, 3
Statement
I. Asset & Inventory 1, 6 6
II. Basic Financial Accounting
A. Financial Ratios 10 4–6
B. Capital Structure of Firm 10 7–9
C. Stocks, Bonds and Financial Instruments 10 part 12, 13
III. Advanced Cost Accounting—Fundamentals
A. Fixed and Variable Costs 13 15
B. Break-even Analysis 13 16
C. Job, Process and Standard Costs 17 18
D. Direct and Indirect Costs 16 19
E. Cost of Goods Sold; Overhead Costs 16 19
F. Contribution Analysis—Profit and Loss Calculations 18 20
G. Activity Based Costing 16 19
H. Flexible & Master Budgets 12 20, 21
I. Performance Assessments 10 part 22
J. Ethical Considerations—SoX Readings Readings
IV. Advanced Cost Estimation
A. Statistical Cost Estimation NA 15
B. Use of Cost Indices and Cost Factors NA 16
C. Design for Cost / Affordability / Target Costing NA 23

223
224
 Engineering Economics

15
Engineering Economics

Donald N. Merino
Stevens Institute of Technology

225
Engineering Management Handbook

15.1 Capital Expenditures

15.1.1 Importance of Capital
How efficiently a country, industry, company, or individual uses capital decides whether they prosper economi-
cally and whether they survive. Generally, capital investments increase the wealth of the investors. In the case of
a country this would be the Gross Domestic Product (GDP). This increase is called a multiplier effect. How-
ever not all capital investments yield that multiplier and in some cases the capital spent may not increase GDP.
Entities need to choose wisely. The “right” investments in equipment or education can yield great returns.

15.1.2 Capital Selection Process

In order to allocate capital efficiently a rationale selection process is needed. The Strategic Plan of an entity
that contains capital expenditures usually drives this process. These capital expenditures can be for plant
and equipment, software development, hardware manufacture or any activity is required to meet the plan.

15.1.3 Minimum Attractive Rate of Return

The minimum acceptable rate of return (MARR) for investments that investors choose including allow-
ance or risk.

15.2 Mathematics of Finance

15.2.1 Rates of Return
Money has a time value. The best example is lottery prize payments. You win a Megabucks prize of USD
$1,000,000. Based on the rules and regulations, the prize was to be paid in 20 equal annual payments
starting this year. However, you wanted to receive the prize as a lump sum payment. Different lottery
financing companies are ready to offer you various amounts as a lump sum payment to buy the prize of
USD $1,000,000 that is going to payout in 20 years. The reason the dollar amounts vary is due to the fact
each company has a different time value and money (% / year).
Financing companies are ready to give up current purchasing power for future purchasing power.
The offer of each company is different, which means that giving up current purchasing power has differ-
ent values for different companies. For example, one financing company might be willing to pay USD
$573,495 [A(P/A, i, N) where A = 1,000,000 / 20, i = 6% and N = 20] while another one might pay only
USD $490,905 [A(P/A, i, N) where A = 1,000,000 / 20, i = 8% and N = 20]. We can calculate rate of
return (the rate that creditors and investors will accept for giving up a current purchasing power for future
purchasing power), from current and future purchasing power of money by using engineering economics
calculation methods.

15.2.2 Simple and Compound Interest

They are two kinds of interest: (1) simple interest and (2) compound interest. The basic difference
between these two is that with simple interest, you do not earn interest on interest, but with compound
interest, you do.

Simple Interest
You earn interest only on the principle, which is the money that was initially invested. For example, if you
invested USD $1,000 (P) with 10% (i) simple interest for five years (N), you would earn USD 100, 10%
of USD 1,000, the first year, USD 100, 10% of USD 1,000, the second year, and so on for as long as
your money remained in the bank.
In five years, you will receive USD $500 as an interest and your USD $1,000 as the principal.
Therefore, your future bank balance from leaving your money at bank for 5 years will be USD $1,500
(F). As you can see the interest on your money is P x i for each period and the total interest amount is
P x i x N.
226
 Engineering Economics

The equation for simple interest for any combination of F, P, i, and N is;
F = P (1 + i x N)
where F= Future Value; P = Present Value; I = interest rate; N = no. of years

For the example above:

The future balance (value) F = $1,000 (1 + 0.10 X 5) = $1,000 X 1.5 = $ 1,500

Compound Interest
You earn interest on the principle, which is the money that was initially invested and on the interest that
you earn in previous periods. For example, if you invested USD $1,000 (P) with 10% (i) compound
interest, compounding yearly, for 5 years (N), your earnings on this USD $1,000 would be:
At the end of the year five, you will receive USD $610.51 as an interest and your USD $1,000 as the
principal. Therefore, your future bank balance from leaving you money at bank for 5 years will be USD
$1,610.51 (F). As you can see the total interest amount on your money is
P x ((1+ i)n- 1)
The equation for compound interest for any combination of F, P, i, and N is;
F = P (1 + i) ^ N

For the example above:

The future balance (value) F = $1,000 (1 + 0.10)5
= $1,000 X 1.61051
= $ 1,610.51

Comparison of Simple Interest and Compound Interest

If we analyze the results of interest calculations for sections 15.2.2.1 and 15.2.2.2, the total return on
the investment was USD $110.51 more for compound interest due to the fact that we earned interest on
interest.
Now, we know the effect of interest method. What about the effect of formula components and
length of compounding period? Let us analyze them one by one for both simple and compound inter-
est methods. We are using the example in sections 15.2.2.1 and 15.2.2.2 to make the comparisons. We
will change only one component each time to analyze the effect of that component.

Principal (P)
Let us assume that the available fund to be invested is doubled to USD $2,000 from USD $1,000 for
both simple and compound interest examples above. Let us calculate the future balances (values) for both
methods.
Simple Interest: FNEW = $3,000
Compound Interest: FNEW = $3,221.20

We can easily notice that when we doubled the investment amount, the future balance, value, is dou-
bled for both methods. Note: USD $1,000 is the initial principle.

Interest Rate (i)

Let us assume that we are still investing USD $1,000 and got better interest rate for both simple and
compound interest methods. The new interest rate is 20%. Let us calculate the future balances (values) for
both methods.
Simple Interest: FNEW = $2,000
Compound Interest: FNEW = $2,488

In simple interest, the total interest earned doubled from USD $500 (USD $1,500 -USD $1,000) to
USD $1,000 (USD $2,000 – USD $1,000) while the total interest earned increased more than double for
227
Engineering Management Handbook

compound interest from USD $610,51 (USD $1,610,51 - USD $1,000) to USD $1488 (USD $2,488 -
USD $1,000). Note: USD $1,000 is the initial principle.

Number of Periods (N)

Let us assume that we are still investing USD $1,000 with the same interest rate (10%). Moreover, we will
invest money for longer term, 10 years. Let us calculate the future balances (values) for both methods.
Simple Interest: FNEW = $2,000
Compound Interest: FNEW = $2,594

In simple interest, the total interest doubled from USD $500 (USD $1,500 - USD $1,000) to USD
$1,000 (USD $2,000 – USD $1,000) while it increases more than double for compound interest from
USD $610,51 (USD $1,610,51 - USD $1,000) to USD $1,594 (USD $2,594 - USD $1,000). Note:
USD $1,000 is the initial principle.

Compounding Period
Compounding period is the length of the time period that elapses before interest compounds. Therefore,
at the end of each compounding period you receive interest. Because simple interest does not pay interest
on interest, the length of compounding period does not have any effect on calculations. Therefore, we will
analyze the effect of compounding for compound interest only.
We are about to invest USD $1,000 with 12% nominal interest rate, which is the periodic rate multi-
plied by the number of compounding periods per year. Moreover, we have four compounding options: (1)
yearly compounding, (2) semiannually compounding, (3) quarterly (every three months) compounding,
and (4) continuous compounding. The future balances and interest earned at the end of first and tenth
year are shown in Table 15.1.

Table 15.1. Demonstration of Simple vs. Compound Interest

Future Value F of Present Sum P

Simple vs. Compound

P = $1000 Future Balance
Example: Bank Interest N @ EOY 1 @ EOY 10

A 12% Simple 0 1120 2200

B 12% Compounded Annually 1 1120 3106

C 12% Compounded Quarterly 4 1126 3262

D 12% Compounded Monthly 12 1127 3300

E 12% Compounded Continuously 360 1127 3320

Future Value of F
The shorter the compounding cycle the higher is its effect. The table above illustrates this phenomenon.
The interest rate is 12% annually, but in case A it is applied as simple interest, in cases B through E we
are shortening the compound cycle from one year to quarterly to monthly to continuously.
The last column shows the balance at the end of 10 years. As you can see the balance increases as the
cycle is shorten, but eventually levels off to $3320 by considering continuous compounding.

For Yearly Compounding

We will invest USD $1,000 and receive 12% interest. USD $120 will be paid as at the end of first year.
Therefore, our future balance at the end of first year is USD $1120 and USD $120 is our interest.
228
 Engineering Economics

For Semiannually Compounding

First, we need to find how much interest we will earn for compounding period. Therefore, we need to
calculate our periodic rate, the rate for the specified compounding period. Because our nominal interest
rate is 12% and we have two periods in a year, our periodic rate is 6%.
In this case, when we invested USD $1,000 at the beginning, we will earn 6% for the first 6 months.
Then, we will earn another 6% on both the initial amount and the interest earn in the first six months.
Fyear= $1,123.60

Our future balance at the end of first year is USD $1123.60 and USD $123.60 is our interest.

For Quarterly Compounding

Let us calculate the periodic rate for a quarter. We have four quarters in a year and our yearly interest rate
is 12%. Therefore, periodic rate is 3%.
In this case, when we invested USD $1,000 at the beginning, we will earn 3% for the first 3 months.
Then, we will earn another 3% on the balance. This will repeat until the end of year 1.
Fyear = $1,125.51

From the results, it is obvious that our future balance at the end of first year is USD $1125.51 and
USD $125.51 is our interest.
We have learnt about the definition and calculation steps of both simple and compound interest. We
know that formulas of simple and compound interest calculations include P, i, and N to determine future
value (balance). Let us compare those two interest techniques.
Payback is the length of time, usually expressed in years, needed to recover initial cost of a capital
investment. It can also be defined as the number of years it takes for the sum of the annual net cash flows
to equal zero.
For a capital project, yearly cash flows can be either equal or unequal. We can segregate payback peri-
od calculations into these two classes.

15.2.3 Effective Interest Rates

Periodic Rate: The periodic rate is the compounding rate of interest for a specific compounding cycle,
like, daily, monthly, quarterly. If the interest is compounded daily, then it is a rate for 1 day, if it is com-
pounded monthly then the rate is for 1 month.

Nominal Rate: The nominal rate is the periodic rate scaled to an annual basis. If the rate is 1% per
month, then its nominal rate is 12% / year. In other words, what is the rate per year in terms of straight
extrapolation of rate of the year? To go from periodic rate to the nominal rate we must drive the rate by
the number of periods that happens within the span of a year.

Effective Rate: The effective rate is the equivalent of the periodic rate compounded for the number of
periods per year.

In the effective rate, of periodic rate is 1% per month, then at the end of the year we will get more
than 12%. The 1% monthly has been compounded 12 times. So the effective rate is (1+0.01)^12 – 1.
Table 15.2 illustrates the effect if compounding if the compounding cycles change. The nominal rate
is 10%. The periodic rate for semiannual, quarterly or daily is calculated by dividing the nominal rate by
the number if compounding in a year. The last column shows that the effective rate increases with shorter
compounding cycle and levels off at 10.52% by increasing the number of cycles to infinity.

229
Engineering Management Handbook

Table 15.2. Effects of Compounding Period

Nominal and Effective Rates - Examples

Example: Interest Effective
I
Compounding Periods / Yr Rate
Period M r r/M i
Annual 1 10 10 10
Semiannual 2 10 5 10.25
Quarterly 4 10 2.5 10.38
Monthly 12 10 0.833 10.47
Daily 360 / 365 10 0.002 10.51
Continuous Infinity 10 0 10.52

Note, that as the compounding period decreases (example from yearly to daily to continuously), the
effective rate increases.

15.2.4 Compounding and Discounting

Compounding and discounting is done mainly to convert from current worth to future worth and vice
versa. As you check these equations, we deal with four items, F, P, N, and i. So to simplify calculations, we
introduce a shorthand notation to represent these relationships and is shown in Figure 15.1.

Figure 15.1. Shorthand Notation Used for Engineering Economics

 Compounding
F = P (F/P, i, N)
- F = P (1 + i)^N
- money grows into the
future
P = F (P/F, i, N)
 Discounting

- F = P (1 + i)^-N
- in today’s dollars

Shorthand Notation

For compounding we are looking for a future sum F. This is given by multiplying the current value P
by a factor that given P yields P at a given I and N... Hence, one can calculate the value of these factors
for any combinations of i’s and N’s. This has been done for the factors we normally use and values are
presented in a set of tables at the back of the Lang and Merino (1993).
The inverse of F/P is the discounting factor and is shown by P/F.
Knowing this notation, we can calculate a future sum, by multiplying the present worth by its factor
that we look up at the back of the text, for the given i and N.

15.2.5 Cash Flow Patterns

While companies have a wide range of capital projects to select from, the resources for these projects are
constrained. Therefore, different projects are to be evaluated from various perspectives before being under-
taken. We will concentrate on the economics of projects in this tutorial. When it comes to the evaluation
230
 Engineering Economics

for economic purposes, we need to estimate cash flows.

Cash flows are the amount of cash a company/project generates and/or uses during a period of time.
It also tells us about the company’s/project’s financial health.
During the life of a project, various cash flows occur. Some of cash flow streams are:
• Cash flows in from sales of goods and services.
• Cash flows out for expenses incurred in producing goods and services.
• Cash flows out for interest payments on borrowed funds.
• Cash flows out for the payment of taxes.
• Cash flows in from the disposal of assets throughout the life cycle and its termination.
• Cash flows out for replacing assets throughout the life cycle.
• Cash flows in from borrowed funds.
• Cash flows out to pay back the principal on borrowed funds.

The above list identifies almost all of the important cash flows except the “initial cost,” “working capi-
tal,” and the “imputed cash flows from benefits and disbenefits.”
The initial cost is the first cost of a project and includes both depreciable and non-depreciable assets.
It can be called by different names such as “investment cost,” “initial investment,” “capital investment”
and “capital expenditure.” Then come the “working capital,” which are the funds needed to operate a cap-
ital facility before revenue becomes available for covering expenses. Working capital is not a depreciable
item.
“Imputed cash flows” are the benefits and disbenefits produced by non-profit entities. For example,
in a highway project, if the new highway will reduce the travel expenses for the highway users, this is an
imputed cash flow for this project. Figure 15.2 illustrates how a cash flow diagram should be drawn.

Figure 15.2. Cash Flow Notation

S = Salvage
Value

1
2 3 4 5

F F’s = difference between revenue and expense

Net cash flow for a period shown at the end of

period

P P = first cost plus working capital

To draw the cash flow diagram, you start from the current time, time 0. In this diagram we can see
that P is the first cost plus working capital, which is what the company invests in the project and is shown
downward (negative side). At the end of the first year we have to make an additional investment, F.
In the first year there is not enough revenue (or no revenue) to cover the cost. From the second year
we can see positive net cash flow each year and the amount increasing.
At the end of the project, there is also the salvage value of the plant and equipment from the initial
investment. Salvage value is an inflow, so it is shown as positive. This diagram typifies the cash flow for a
simple startup business. Note that salvage value can be negative or positive. Examples of negative salvage
value include cleaning up toxic water and nuclear power disbanding.

231
Engineering Management Handbook

15.2.6 Loan Programs and Personal Finance

This model is the most common loan or mortgage model used. For instance, if you take a fixed rate
loan for your car or your house, your payments to the bank looks like what is represented as shown in
Figure 15.2.
This is called amortization and is shown in Figure 15.3. That is the amount to be paid during the pay-
ment period is the same, but the proportions between the interest and principal change. Initially, more of
the payment goes toward the interest and less toward the principal. However, toward the end, more of the
payments go towardConstant Payments - Interest and Principal Combined
the principal.
(amortization)
Figure 15.3. Constant Payments - Interest and Principle Combined (amortization)

Interest Variable Principal Variable

0 1 2 3 4 5

The advantage of the model is the fixed payments, which help people with relatively fixed income
(like salary) to better plan and manage their budgets.
Up until the end of WWII, loans were mostly interest payment only. The result was that most people
could not accrue equity in their home. After WWII, with VA and FHA loans, the amortized loans (mort-
gages) became the norm—and with it equity for millions in their homes, firms, and businesses.

15.3 Figures of Merit (FoM)

There are generally five figures of merit that are used to compare and rank alternative capital investment
opportunities. They are:
• Present Worth (PW) or Present Value (PV) or Net Present Value (NPV)
• Future Worth (FW) or Future Value (FV) or Net Future Value (NFV)
• Annual Worth (AW), or if the annual worth is negative, then Annual Cost (AC) or Equivalent Uni-
form Annual Cost (EUAC).
• Internal Rate of Return (IRR)
• Benefit Cost Analysis (BCA)

The three worths—present, annual and future—are directly linked through the rate of return factors
derived before. AW is FOM used in retirement or replacement problems. FW is FOM used for insurance,
pension, and bond analysis. Any worth can be converted to any other worth because of equivalence.
• Present Worth—most commonly used
• Annual Worth—used where annual comparisons are appropriate
• Future Worth—used in insurance, pensions, etc.

15.3.1 Present Worth

This is the most widely figure of merit and is based on the discounted cash flow. Present Worth (PW) is
defined as the monetary sum that is equivalent to a future sum when the interest is compounded at a given
rate. It can be also defined as the discounted value of a future sum when discounted at a given rate. It is also
referred as Net Present Value (NPV), PV or NPW.
232
 Engineering Economics

So, the Present Worth (PW) is given by,

PW = A (P/A, i, N) + S (P/F, i, N) - P

where: PW = Present Worth; A = Uniform Series of Annuities, i = Interest Rate per period; N = Number
of periods; S = Salvage Value; P = Present Value.

Example 1: Automatic Welder

Problem Data:
- Cost of Automatic welder = $100,000 - Installation cost = $15,000
- Expected annual income = $40,000 - Duration of life = 5 years
- Salvage value = $10,000 - Interest rate = 20%

Figure 15.4. Cash Flow Diagram for Purchasing an Automatic Welder

S = $10,000

A = $40,000
0

1 5
i = 20%

$115,000

PW = A (P/A, 20, 5) + S (P/F, 20, 5) - P

= ($ 40,000 x 2.9906) + ($10,000 x 0.4018) – 115,000
= $ 119,624 + 4,018 – 115,000
= $ 8,642 for 5 years

15.3.2 Annual Worth

The Annual Worth (AW) can be obtained by simply multiplying the PW that have just been calculated by
the A/P factor. So,
AW = PW (A/P, I, N)
Also, AW can be found out by using the following formula too:
AW = S + S (A/F, i, N) – P (A/P, i, N)

where: AW = Annual Worth; A = Uniform Series of Annuities, i = Interest Rate per period; N = Number of
periods; S = Salvage Value; P = Present Value; (A/F) = Sinking Fund Factor; (A/P) = Capital Recovery Factor.
• To Convert AW to PW: Multiply by P / A factor = A (P / A) = P
• To Convert AW to FW: Multiply by F / A factor = A (F / A) = F

15.3.3 Future Worth

The Future Worth (FW) is the value of an asset or cash at a specified date in the future that is equivalent in
value to a specified sum today. Future Worth could be obtained by multiplying the present or annual worth
by the proper F/P and F/A factors, respectively. The FW can also be calculated using the following formula:

FW = A (F/A, i, N) – P (F/P, i, N) + S

233
Engineering Management Handbook

where: FW = Future Worth; A = Uniform Series of Annuities; i = Interest Rate per period; N = Number
of periods; S = Salvage Value; P = Present Value; (F/A) = Compound Amount Factor for Equal Payment
Series; (F/P) = Compound Amount Factor for Single Payment.

15.3.4 Capital Recovery

Capital Recovery of an investment is a uniform series representing the difference between the equivalent
annual cost of the first cost and the equivalent annual worth of the salvage value.
Capital Recovery of an investment is a uniform series representing the difference between the equiva-
lent annual cost of the first cost and the equivalent annual worth of the Salvage Value.
The generalized formula for the Capital Recovery is given as:

CR = P (A/P, i, N) – S (A/F, i, N)

where: CR = Capital Recovery; P = First Cost; S = Salvage Value at the end of the time period.

Now, let us move on to the CR for an infinite horizon. In the case of an infinite time horizon, the
A/P factor equals i and the A/F factor equals zero.
This means that we do not consider salvage value in situations like this. So, in other words, for a project
with infinite time horizon, S = 0. Therefore, the formula for CR over an infinite time horizon is given by:

CR = Pi

where: CR = Capital Recovery; P = First Cost; i = MARR

15.3.5 Capitalized Cost

Capitalized Cost is defined as the sum of the first cost P of an investment plus the present worth of per-
petual periodic cash disbursements and is demonstrated in Figure 15.5.

Figure 15.5. Capitalized Cost      

0 1

A to infinity

MARR = i

P
Now, in a situation like this, where the planning horizon is infinity, the Capitalized Cost is given by:

CC = P + A/i

where, CC = Capitalized Cost; P = First Cost; A = Uniform Annuity; i = MARR.

This is because, as N approaches infinity, A/P factor for any interest rate i, approaches i. P/A, which is the
inverse of A/P, approaches 1/i. Therefore, we get the formula of CC given above.

234
 Engineering Economics

15.3.6 Internal Rate of Return (IRR)

As mentioned before the IRR is the return investors will get if the cash flow estimates in the cost studies
prove true. The IRR can also be defined as the rate of return that makes the net present worth of a set of
cash flow streams equal to zero. IRR is also known as the hurdle rate, or cutoff rate, or targeted rate, or
the profitability index
PW = A (P/A, i, N) – P + S (P/F, i, N)

When calculating IRR, we set the PW equal to zero. Then using the provided information and the above
equation we solve for the IRR.

A Simple IRR Problem

Given that capital cost of a project is $100,000. With yearly savings of $30,000 over the service life of 5
years, calculate the IRR.
First, we set the PW to zero,
P = $100,000
A = $30,000
N = 5 years

PW = A (P/A, i, N) – P + S (P/F, i, N)

Remember (P/A, i, N) = ((1+i) N – 1) / (i (1+i) N)

Using a calculator it is easy to solve for the IRR.

Using a calculator, Goal Seek in Excel, interpretation it is easy to solve for the IRR thus producing i = 15.27%.
Present Worth and IRR are often used to determine the best course of action to follow. First, the Pres-
ent Worth is calculated using the MARR. If the present worth is positive, IRR is then determined to find
out what rate of return the cash flow estimates might produce.
The IRR methodology is also applied to incremental cash flow patterns to determine the return on
incremental investments due to lower expenses or higher revenues, or both. However, there are several
shortcomings when calculating IRR. The first shortcoming is “Multiple Solutions.” This occurs when the
cumulative cash flow crosses the x-axis and changes signs. In cases where additional capital is invested
after year 0, the added capital may cause multiple changes in signs and result in multiple solutions. The
second shortcoming is the ‘Reinvestment Fallacy.” Can the funds from a particular project be invested at
the IRR rate?

15.3.7 Benefit Cost Analysis (BCA)

Introduction to BCA
The last figure of merit to be discussed in this course is the benefit cost ratio (BCR). For projects aiming
to improve the welfare of the public, BCR is often the preferred figure of merit. This is because it does not
solely focus on the financial return of a project, but measures if the benefits of a project outweigh its costs.
This is the figure of merit often used by government entities to justify their selection of projects from the
large pool of projects placed before them.

Cash Flows
A key difference between the BCR and other figures of merit is noted in the cash flows. Cash inflows in
relation to the benefit-cost analysis consist of the benefits to the public. Whereas cash outflows in relation
to the benefit-cost analysis consist of the costs to the government for providing those benefits.
235
Engineering Management Handbook

For example, let us consider the cash flows in relation to the Mississippi Levee; the cash inflows in this
case include the initial capital investment and periodic maintenance costs. The cash outflows include benefits
like flood control and recreation, besides protecting the economic well-being of cities like New Orleans.
Cash flows in relation to the benefit-cost analysis can also be further divided into the following five groups:
• Positive Benefits (B)
• Disbenefits (D)
• Initial Cost (I)
• Cash Costs (C)
• Cash Receipts (R)

As mentioned earlier a project is deemed worthwhile only if the benefits derived from it exceed the
costs of the project. The benefit cost ratio (BCR) can thus be expressed as either B – C or B/C.

For a project to be deemed feasible; B – C > 0 or B/C > 1

Conventional and Modified BCR Formulas

The conventional formula for the BCR is

BCR = (B – D) / (I + (C – R))

The modified formula for the BCR is

B/C = ( (B – D) – (C – R)) / I

where: B = Benefits derived from the project; D = Disbenefits derived from the project; I = Initial invest-
ment in the project; C = Operating and maintenance cost involved with the project; R= Revenue earned
from the project.
The key difference between the two formulas is in the treatment of the term (C – R). In the conven-
tional BCR formula the term (C – R) is part of the denominator, while in the modified BCR formula it
is in the numerator, leaving Initial cost as the sole term in the denominator. In the conventional formula,
all costs are taken as cash outflows while the net benefit is taken as the cash inflow. In the modified BCR
formula only the initial cost is taken as a cash outflow, while the net benefit minus the O&M costs is tak-
en as the cash inflow. It should be noted that while calculating BCR in either formula, one should ensure
that all cash flows are brought back to their present worths or annualized.

Example using Conventional and Modified BCR

Given the following;
- Benefits = $2,000,000/yr = B - Disbenefits = 0 = D
- Initial Costs = $ 1,000,000/yr = I - O&M Costs = $ 500,000/yr = C
- User Fees = 0 = R

Conventional BCR
B/C = (B - D) / (I + (C – R))
= 2,000,000 / (1,000,000 + 500,000)
= 1.333

Modified BCR
B/C = ((B – D) – (C- R)) / I
= (2,000,000 – 500,000) / 1,000,000
= 1.500
236
 Engineering Economics

15.4 Retirements and Replacements

Retirement and replacement problems are of great importance in a capitalistic economy. Retirement
and replacement studies are essential for any company to remain competitive. Every machine used by a
company undergoes a certain amount of wear and tear as time goes by. After a certain point, the machine
needs to be replaced. Either because it is no longer suitable for use, or it is no longer economical to main-
tain and operate.
Replacement problems are typically handled as a least cost problem. This means that the
decision-makers are interested in minimizing cost. Retirement and replacement studies also include
non-economic factors in the decision-making process. However, in this chapter we will deal only
with the economic factors. For the retirement and replacement problems we deal with in this
chapter, we will generally assume discrete cash flows and that we are dealing with before tax rate
of returns.

15.4.1 Types of Retirement and Replacement Problems

Type 1—Simple retirement/without replacement
This is a problem that offers a very simple alternative; to keep the asset or to retire it without replacing
it. Here, the net cash flows over the remaining life are discounted by the MARR and then compared to
the opportunity cost of not selling the asset. If the resulting PW is less than zero the asset is retired.

Type 2—Retirement with an identical replacement

In this case, the asset being considered as a replacement is similar to the asset considered for replacement.
In this case we find the optimal economic life and the life of the asset. If the asset is older than the opti-
mal economic life it is replaced. If it is not, it is kept.

Type 3—Retirement with different replacements but similar to each other

In this case, the challenger assets are different from the defender. However, the challengers themselves are
different.

Type 4—Retirements with different replacements not similar to each other

Generalized retirement and replacement problems require knowledge of dynamic or mixed integer pro-
gramming.

15.4.2 Total Costs and Economic Life

The following covers the most frequent type of retirement and replacement problems—Type 2 problems.
Figure 15.5 shows the optimal economic life of a machine. The total cost reaches a minimum when
the Operating and Maintenance (O & M) costs equal the capital cost. The corresponding N value to this
point is the optimal economic life. This is point is also considered to be the best time to replace or retire
the asset.

237
Engineering Management Handbook

Figure 15.6. Generalization of an R&R Problem

EUAC

Total Costs

O&M Costs

Capital Costs

N Time
Figure 15.6 shows the optimal economic life of a machine. The total cost reaches a minimum when the
Operating and Maintenance (O&M) costs equal the capital cost. The corresponding N value to this point is
the optimal economic life. This is point is also considered to be the best time to replace or retire the asset.

15.4.3 Capitalized Costs

There are three simple steps needed to calculate the total capital cost.
1. Calculate the annualized first cost (P) by converting P to an annuity over the project life, using the
capital factor (A/P, i, N).
2. Calculate the annualized salvage value by converting the future value (F) to an annuity using the
sinking fund factor (A/F, i, N)
3. Add the two capitalized costs obtained from steps 1 and 2.

Standard formula used for calculating total capital costs.

EUAC = P (A/P, i, N) – S (A/F, i, N)

Note: Alternative formula.
EUAC = (P-S)*(A/P, i, N) + S (i)

Example for Capitalized Costs

SM Industries is looking into expanding its operations with a new facility in Rio. The first year salvage
value is $8,000,000 and will decrease each year after. O&M costs are $1,500,000 and will increase each
year after. Assume a life of 4 years, and initial costs of $40,000,000. Assume discrete end of year cash
flows and a before-tax rate of return of 8%. Find out when this facility would have to be replaced.

Step 1
The first thing is to calculate the salvage values and O&M costs for each year as shown in Table 15.3.

Table 15.3. Salvage Value and O&M Costs by Year

Rio
EOY Salvage Value O&M Costs
1 $8,000,000 $1,500,000
2 $6,400,000 $1,875,000
3 $6,120,000 $2,343,750
4 $4,096,000 $13,929,688
Initial Cost $40,000,000
238
 Engineering Economics

Step 2
We calculate the capitalized cost for each year as shown in Table 15.4.

Table 15.4. Capitalized Costs by Year

1 2 3 4 = 2x3 5 6 7 = 5x6 8 = 4-7

Initial Cost
EOY (A/P,8%, j) Annualized IC Salvage (Sj) (A/F,8%, j) Annualized Sj CR
(IC)
0 $40,000,000
1 1.0800 $43,200,000 $8,000,000 1.0000 $8,000,000 $35,200,000
2 0.5607 $22,428,000 $6,400,000 0.4807 $3,076,480 $19,351,520
3 0.3880 $15,520,000 $6,120,000 0.3080 $1,884,960 $13,635,040
4 0.3019 $12,076,000 $4,096,000 0.2219 $908,902 $11,167,098

15.4.4 Operating and Maintenance Costs

O&M costs cover the costs of running a factory, office, or a plant. It includes labor, materials, etc.
O&M costs usually increase with time, but there are a few exceptions, for example, computer software.
There are three steps required to calculate the annualized O&M costs.
1. Obtain the yearly cost by converting the future cost to present worth. Use the present worth
factor (P/F, i, N).
2. Find the cumulative PW.
3. Find the annualized cost by converting the cumulative PW to annuity. Use the capital recovery
factor (A/P, i, n).

An example for EUAC O&M Costs is shown in Table 15.5.

Table 15.5. EUAC Calculation for O&M Costs

1 2 3 4 = 2x3 5 6 7 = 5 x6
EOY O&M (P/F,8%, j) PW of O&M Cum. PW (A/P,8%, j) O&M EUAC
1 $1,500,000 0.9259 $1,388,850 $1,388,850 1.0800 $1,499,958
2 $1,875,000 0.8573 $1,607,438 $2,996,288 0.5607 $1,680,018
3 $2,343,750 0.7938 $1,860,469 $4,856,756 0.3880 $1,884,421
4 $13,929,688 0.7350 $10,238,321 $15,095,077 0.3019 $4,557,204

The total EUAC is calculated by adding the capitalized recovery costs and the O&M costs. The optimal
economic life is determined by finding the year with the lowest EUAC figure. The asset in question should
be replaced after this point. Table 15.6 shows the calculation for total EUC for an O&M example.

Table 15.6. Total EUAC for an O&M Example

EOY CR O&M EUAC Total EUAC

1 $35,200,000 $1,499,958 $36,699,958
2 $19,351,520 $1,680,018 $21,031,538
3 $13,635,040 $1,884,421 $15,519,461
4 $11,167,098 $4,557,204 $15,724,301

From Table 15.6 it is seen that the lowest EUAC occurs at the end of year 3. Hence, the facility should
be replaced at the end of year 3.
239
Engineering Management Handbook

15.5 Inflation
Inflation can be defined as an increase in the general price level of goods and services. It can also be de-
fined as a decrease in the purchasing power of the dollar. Inflation is an important part of life and business
for both individual consumers and corporations.

15.5.1 Causes of Inflation

Inflation is variable in nature and is influenced by several factors.
1. Consumer Demand: When consumer demand for a certain product or service increases, it usually
leads to the increase in the price of the product or service.
2. Product Improvements: Certain product improvements cause price increases because the improved
product has more or better features. An example would be switching to Color TV from a Black and
White TV.
3. Technological change: Price increases are also caused by technological changes. The product using
a new technology usually cost more because the new product cost reflects the cost of research and
development. An example would be switching from wired networks to Bluetooth networks.

15.5.2 Types of Inflation

1. 1. Cost Push Inflation: This type of inflation is caused by increases in the cost of production (e.g.,
minimum wages or increased safety). With all other factors remaining the same, the higher the cost of
production, the lower the amount of goods produced. At a given price level, rising wages or increas-
ing raw material costs, result in companies downsizing labor forces and lowering production rates.
2. Demand Pull Inflation: When supply is unable to meet demand, there is a resultant increase in prices.
This may happen because of a sudden spike in demand and production levels cannot be ramped up
fast enough. It may also occur because producers are deliberately curtailing supplies.
3. Structural Inflation: These are price increases triggered by Cost of Living Allowances (COLASs) or
other contractual objectives.
4. Energy: The impact of the increase in the price of energy on products is significant and complex and
its effects on inflation merit its own category. Increased energy costs are reflected in production costs
and transportation costs.

The common method of measuring inflation is through the use of price indices. “Price indices for
measuring price level effects are dimensionless ratios that compare prices of a specified set or combination
of goods and services in a selected base period to the prices of the same or functionally equivalent set at
any other period.” Increasing price indices indicate inflation, while falling price indices indicate defla-
tion. These price indices are based on models constructed through surveys, definitions, examinations of
published prices, etc. The base year is assigned a cost of 100 and following years are measured against this
level. Thus, future years may have lower or higher price levels.

Consumer Price Index (CPI)

This is one of the best-known price indices and is issued and complied by the U.S. government. The CPI
is further subdivided into two indices. The CPI-W which is the cost of the “the market basket” of goods
and services bought by wage earners. The second is the CPI-U, which is measured for all urban dwellers.
Inflation can also be defined in relation to the CPI. The inflation rate is defined as the percentage change
in the annual CPI.

Wholesale Price Index (WPI)

Also known as the Producers Price Index (PPI), this is the cost of the “market basket” of goods and ser-
vices brought by the industry.

240
 Engineering Economics

GNP or GDP Deflator

The GNP or GDP deflator measures the cost of all goods and services in the GNP or GDP.

Industry Specific Index

These are cost indices for individual disciplines/industries. These indices take an in-depth look at an indi-
vidual discipline/industry and the movement of capital and operating costs through the years. For exam-
ple, the Chemical industry has the Marshall/Swift indices.

15.5.3 Using Price Indices

The first step is to ensure you have selected the right price index. The second step is to use an appropriate
time period. Often ratios are used to determine the amount of inflation.

Example Using the CPI Index

When John joined the Clysedale Brewery in September 1980, his starting salary was $24,000. What
would his equivalent starting salary be if he joined in the year 2000?

Starting Salary CPI

1980 $24,000 84
2000 ??? 171

Using the F/P Future worth factor we calculate “i”.

F = P(1+i)n => F/P = (1+i)n => 171/84 = (1+i)20 => i = 3.62%

Thus, the equivalent starting salary would be:

F = 24000 (1+0.0362)20 = $48,969

15.5.4 Inflation and MARR

We will now examine the relationship between MARR and inflation. There are three elements to this
relationship.
‘i’ = The MARR with inflation
‘f ’ = Rate of Inflation
‘ieq’ = The MARR without inflation
(1 + ieq) = (1 + i) / (1 + f ) => ieq = (i - f ) / (1 + f ) => i = ieq + f + ieqf
=> I = ieq + f or ieq = i - f

Thus, we can see that the i (MARR with inflation) is approximately equal to ieq (MARR) plus f (inflation).
On the other hand, that ieq (MARR without inflation) is approximately equal to i (MARR with infla-
tion) minus f (the inflation).

15.5.5 Cash Flows and Inflation

Cash flow estimates over a life cycle based on constant dollars are not adjusted for price level effect. These
are also know as actual dollar cash flows and keyed into a specific year. Cash flows can also be adjusted to
current or real dollars. These cash flows are in the years specified. We will now look at three cases of cash
flows and inflations.

241
Engineering Management Handbook

Case 1: No Inflation and Constant Dollars

In this case we use ieq as the rate. The case is represented below in a cash flow figure with A denoting con-
stant dollars and N the number of years.

Case 2: With Inflation and Constant Dollars

In this case we use ieq as the rate. The case is represented below in a cash flow figure with A denoting con-
stant dollars and N the number of years. In this case before calculating the figure of merit, we ensure that
all cash flows have been converted to constant dollars.

Case 3: With Inflation and Current Dollars

In this case we use i as the rate. The case is represented below in a cash flow figure with A denoting cur-
rent dollars and N the number of years.

15.5.6 Common Problems Relating to Inflation

We will focus on two common types of inflation problems.

A: Inflating Constant Dollars to Current Dollars:

In this case, we have been given a value in constant dollars (for example, the current rate of soft lumber)
and we want to convert this figure to current dollars over the life of the project. To do so we need to in-
flate our constant dollar value. We apply the F/P (Future Worth Factor) to inflate constant dollars.

B: Deflating Current Dollars to Constant Dollars:

In this case, we have been giving a value in current dollars and we want to convert them to constant
dollars. For example, we have been given the cash flows of operating expenses across the life of the project
and we want to convert those cash flows to their present constant dollar value. To do so we need to deflate
our current dollar value. We apply the P/F Factor to deflate current dollars.

15.6 After Tax Analysis

The taxes paid and tax related items like depreciation and investment tax credits have a significant impact
on the economics of all aspects of corporate activity, but particularly on Capital Investment.
Economic decision-making is based on Cash Flows (not accounting profit). If you take a course in
Corporate/Managerial Finance, you will find that corporations are managed on the Cash Flow.
Cash Flows can be generated as part of:
• Operating Activities
• Capital/Finance Activities

Operating cash flows can be determined from the Income Statement. Note that an operating cash
flow is Net Income after Tax plus depreciation. Remember that depreciation is a non-cash (accrual) ex-
pense. Operating cash flows are periodic over a number of years.
Capital Cash Flows can be determined from the Balance Sheet. There are a number of activities that
impact the Capital Cash Flows. Change in inventory levels, financing activities and capital expenditure
are some of these activities. For engineering economics we are interested in investments for depreciable
(plant, equipment, etc.) and non-depreciable (land) capital. For capital projects we are also interested in
loans (to finance capital) and the after tax sale/disposal of capital at the end of the project.
In the following sections we will provide the calculations and format for:
• Net Cash Flow from Operating Activity
• Net Cash Flow from Capital Activity
As well as the After Tax Cash flows for:
• Depreciation
• Loans/borrowings
• Salvage/disposal of capital items
242
 Engineering Economics

15.6.1 Net Cash Flow from Operating Activities

Table 15.7 is the modified (Normal) Income Statement format used in Engineering Economics for the
selection of Capital Projects.

Table 15.7. Net Cash Flow from Operating Activities

Line Cash Flow Operations

1 Operating Revenue
2 Cash Expenses
3 Operating Income Before Depreciation 1-2
4 Depreciation
5 Operating Income 3-4
6 Interest Expenses
7 Pretax Net Income 5-6
8 Income Taxes Per Year
9 Investment Tax Credit
10 Net Income 7+8+9
11 Depreciation
12 Net Cash Flow from Operating 10 + 11

Note that the format is very similar to the income statement format in Chapter 3. The format in
Chapter 3 was expanded to include separate items for:
• Line: 4:- Depreciation
• Line: 6:- Interest Expenses from Loans
• Line: 9:- Investment Tax Credit
Depreciation was added back to the Net Income after Tax to yield the operating cash flow. Note that
the $ amounts in this format are for N years where N = Project Life.

15.6.2 Net Cash Flow from Capital Related Line

Table 15.8 is the modified balance sheet format used in Engineering Economics for the selection of Capi-
tal Projects.

Table 15.8. Net Cash Flows from Capital Related Activities

Line Cash Flows Operations

13 Principal Repayment
14a Depreciable Capital
14b Non-Depreciable Capital
14c Loan Proceeds
15 Capital Gains/Losses
16 Working Capital
17 Net Capital Cash Flow 13+14+15+16

Note that the format of Table 15.8 is similar to the Balance Sheet and Cash Flow Statement discussed
in Chapter 14 (Basic Accounting).
You will note that there are other items that will impact on balance sheet cash flows. For the selection
of Capital Projects these include:
• Principal Repayment of Loans used to purchase capital goods
• Depreciable and non depreciable capital
• Loans proceeds
243
Engineering Management Handbook

• Capital gains/losses when capital is disposed of (salvage)

• Working Capital

You should know the definition of these items and how they differ. Consult Chapter 14 (Basic Ac-
counting).

15.6.3 After Tax Cash Flow from Depreciation Charges

Various depreciation methods is discussed earlier in the handbook. Note that depreciation is a non-cash
(accrual) entry and as such is added back to the Net Income after tax to yield the cash flow from operat-
ing activities.

15.6.4 After Tax Cash Flow from Investment Tax Credit (ITC)
From time to time government/agencies (U.S., State, and sometime local) give incentive for business to
make capital Investments. This is usually during a recession or natural disaster (like Hurricane Katrina)
and is designed to increase capital spending.
Why Capital Spending? The concept is that for every dollar spent on capital goods, the Gross Na-
tional Product and Gross Domestic Product (GNP and GDP) will increase many folds (6 to 8 times). In
macroeconomics, this is called the “Multiplier Effect.”
The Investment Tax Credit (ITC) allows a company to subtract some part of the Capital purchase
price from the Income Tax it pays. For example, if the ITC is 10% and the company makes a $200,000
capital investment then the company can deduct $20,000 from its taxes (usually in year 0 or 1).
It is assumed that the company will keep the Capital asset in service for a certain number of years.
If it does not, it may have to give back some of the ITC. This is called re-capture. You need to seek Tax
Counsel on this matter because the rules are complex. ITC for solar panels or energy saving items like
Hybrids cars are examples that apply to consumers.

15.6.5 After Tax Cash Flows from Loans

The after tax analysis with loan repayment includes are the steps in Table 15.1 plus interest expenses.
Interest is subtracted from the net cash flow before income taxes are calculated because interest is tax
deductible, requiring it to be eliminated from the taxable income.
Interest charges benefit the organization because it reduces the taxable income and, hence, the income
taxes. The principal payments are being subtracted in Table 15.2 because principal is NOT tax deductible.
When dealing with loans, we need to understand the difference between interest and principal. Principal
is the actual amount you have borrowed or the remaining, unpaid balance owed to the lender. Interest is
most easily described as the fee charged by the lender for lending you the principal. It is usually expressed
in as annual percentage of the principal. Interest is generally tax deductible, meaning it REDUCES tax-
able income.
Table 15.9 provides an example on how to “amortize” a loan. The example assumes that the interest
rate is 10% and the loan is repaid in 4 years. The amount of the loan is $80,000. Annual payment is cal-
culated using the time value of money equation:
A = P (A/P, I, N) = $80,000(A/P, 10, 4)
A = $80,000 x .3155
A = $25,240/year

244
 Engineering Economics

Table 15.9. Loan Balance / Amortization Table

Annual
Beginning-of- Annual Annual End-of-Year
Year Principal
Year Balance Payment* Interest Balance
Repayment
(1) (2) (3) (4) (5) (6)
10% of (2) (3) - (4) (2) – (5)
01 $80,000 $25,240 $8,000 $17,240 $62,760
02 $62,760 $25,240 $6,276 $18,964 $43,796
03 $43,796 $25,240 $4,380 $20,860 $22,936
04 $22,936 $25,240 $2,294 $22,936 0
Total 80,000

As you are shown in Table 15.7 the interest is a periodic expense that reduces operating income before
taxes. From Table 15.4 notice that the principal repayment is a capital related item (return of capital). To
summarize:
• Table 15.9 Interest (Column 4) goes to Table 15.7 Line 6
• Table 15.9 Principal Repayment (Column 5) goes to Table 15.84 Line 13

15.6.6 After Tax Cash Flow for Salvage/Disposal of Assets

This topic was covered in Chapter 14 – Gains & Losses for the Disposal of Assets 14.4.

15.6.7 Total Cash Flow Discounted

Table 15.10 adds the total periodic cash flow (Line 12 – Table 15.7) to the Capital related cash flows
(Line 17 – Table 15.8).

Table 15.10. Total Cash Flow (Operating and Capital) Discounted

Line Cash Flows Operations

18 Total Cash Flow 12 + 17
19 Discounted Factor
20 Net Present Value
21 Cumulative NPV

Line 1: is truly the “bottom line” in all Economic Analyses. This is used for choosing among capital
projects, mergers and acquisitions, long-term corporate planning and in all sorts of financial decisions.

Because Engineering Economics is built on the Time Value of Money we use the Discounted Cash
Flow (DCF). This is line 20 and 21 (accumulated).

To calculate the DCF you need to use a MARR (Minimum Attractive Rate of Return) and apply this
to the project cash flows.

The cumulative DCF is the Net Present Value (NPV) for the project and is a widely used Figure of
Merit.

15.6.8 ATA Example

Innovation Inc. is planning to start a new business in order to increase the efficiency of their consulting
operations. Listed in Table 15.11 are the economic data for their proposed investment.

245
Engineering Management Handbook

Table 15.11. Economic Data for the ATA Problem

1 Depreciable Capital - year 0 $2000

2 Salvage Value (FMV) (at the end of project life)-BV $900
3 Non-depreciable Capital - year 0 $500
4 Non-depreciable Capital (returned at the end of project life) $750
5 Expected Revenue ($ / yr.) $9500
6 O&M Cost ($ / yr.) $120
7 Useful life –years 2
8 Working Capital - year 0 $600
9 Working Capital - (returned at the end of the project life) $600
10 Loan Proceeds - year 0 $1200
11 Interest on Loan - per year 10%
12 Loan Period – years 2
13 Tax rate - per year 40%
14 ITC - year 0 $150
15 ITC - year 1 $0
16 MARR per year 18%

(Note: All units are in ‘000 dollars)

This system qualifies a special two-year MACRS Depreciation (with factors 0.55 and 0.45). Assume
working capital is returned in year 2. Also assume that the company has income from other projects and
this system is sold at the end of year 2. ITC is $150 and being given at the end of year 0.

Solution to the ATA Example

As a first step we need to calculate the interest and principal repayments for the loan which is shown in
Table 15.12.

Table 15.12. ATA Loan Amortization Table

Beginning Annual Principal Ending

Year Interest
Balance Payment Repayment Balance

0
1 $1,200.00 $691.43 $120.00 $571.43 $628.57
2 $628.57 $691.43 $62.86 $628.57 $0.00
Total $182.86 $1,200.00

The second step is shown in Table 15.13 in which we find the depreciation expenses and accumulated
depreciation expenses (using the special MACRS rate) for this system.

246
 Engineering Economics

Table 15.13. Depreciation Expenses for the ATA Problem

Initial Depr. Dep. Accum. Ending

Yr.
Cost Rates Exp Dep BV
0 $2,000
1 55% $1,100 $1,100 $900
2 45% $900 $2,000 $0
Total $2,000

Next we determine the after tax cash flows from salvage of depreciable and non-depreciable capital:

Depreciable:
Taxes = (FMV - BV) * TR
= ($900 – 0) * 40%
= $360
After tax cash flows FMV – salvage = $900 - $360
= $540
Non - depreciable:
Taxes = (FMV - BV) * TR
= ($750 - $500) * 40%
= $100
After tax cash flows FMV - salvage = $750 - $100
= $650

We then calculate the Net Cash Flow from operating income as shown in Table 15.14.

Table 15.14. Net Cash Flows from Operating Income

0 1 2 Total
1 Operating Revenue 0 9500 9500 19000
2 Cash Expenses 0 120 120 240
3 Operating Income 0 9380 9380 18760
4 Depreciation 0 1100 900 2000
5 Operating Income 0 8280 8480 16760
6 Interest Expense 0 120 62.86 182.86
7 Pretax Net Income 0 8160 8417.14 16577.14
8 Income taxes 0 3264 3366.86 6630.86
9 Investment Tax Credit 150 0 0 150
10 Net Income AT 150 4896 5050.29 10096.29
11 Depreciation 0 1100 900 2000
12 Net C.F. from Operations 150 5996 5950.29 12096.29

247
Engineering Management Handbook

Table 15.14. Net Cash Flows from Operating Income (continued)

13 Principal Repayment ($571.43) ($628.57) ($1,200.00)

14a Depreciable Capital ($2,000.00) $0.00 $540.00 ($1,460.00)
14b Non-depreciable capital ($500.00) $0.00 $650.00 $150.00
14c Loan Proceeds $1,200.00 $1,200.00
15 Capital Gains/Losses $0.00
16 Working Capital ($600.00) $0.00 $600.00 $0.00
17 Net Capital Cash Flow ($1,900.00) ($571.43) $1,161.43 ($1,310.00)

18 Total Cash Flow ($1,750.00) $5,424.57 $7,111.71 $10,786.29

19 Discount Factor @ 18% 1 0.8475 0.7182 -
20 Net Present Value ($1,750.00) $4,597.32 $5,107.63 $7,954.96
21 Cumulative NPV ($1,750.00) $2,847.32 $7,954.96

15.7 Decision Analysis

15.7.1 Types of Problems
There are three classes of problems in economic decision-making.
• The first is decision under certainty – where you assume that you have sufficient information on the
inputs. That is, you are certain about input estimates. To explore alternatives, we use sensitivity analysis.
• The second involves decisions under risk mean that you have inputs that have probabilities. These can be
expressed as distributions. Risk management uses simulation techniques (example, Monte Carlo Simula-
tion) to look at various alternatives.
• Lastly, there are problems where you do not have any data or the data is random (like in stock market)
and cannot be expressed as a distribution. To solve these problems, you can use certain rules or heuristics.
These are known as principles of choice.

15.7.2 Choosing Among Alternatives Using ATA

The most prevalent industry approach to choose among competing alternatives is the After Tax Analysis
(ATA) (Lang and Merino, 1993). Figure 15.6 describes a typical ATA decision process followed by a
written description of the decision-making process.
Why is After Tax Analysis the standard methodology for industry? ATA is necessary because the gov-
ernment is a “partner” in every capital decision. Depreciation rates, tax rates, investment tax credits and
capital gains taxes greatly influence the attractiveness of capital expenditures.
In addition, ATA is used to determine the impact of borrowing on the project’s profitability. Borrow-
ing at after tax interest rates that are below the project’s Internal Rate of Return (IRR) will increase the
overall Rate of Return (RoR). Note that the opposite is true. These borrowing options are called Financial
Leverage.
Companies first look at a project’s RoR assumptions with full equity (100% of company’s cash with
0% of loans) to determine if the investment should be included in the capital expenditure budget. Finan-
cial leverage is considered for some subset of projects. Those projects tend to be ones that are required by
law and are mandatory and not optional or elective. Also financial leverage is considered when there is a
readily available pool of funds and/or lease options.1

1. A lease could be considered the same as a loan in certain circumstances.

248
 Engineering Economics

Figure 15.7. General Decision Model to Determine Economic Feasibility

1. Develop Alternative / Scenarios

- Specific Alternatives - Mutually Exclusive (MEAs)
- Develoop Scenarios

2. Cost Estimation 3. Benefit Estimation

- Capital - Revenues
- Operating Expense - Other Savings

4. Economic Analysis
- Establish Economic Critiera (MARR, FoM, Tax Rate, etc.)
- Use After Tax Analysis (ATA Model)
- Calculate Life Cycle Costs (EUAC)

5. Evaluate Intangibles / Non-economic

- Environmental, Aesthetic, Legal, etc.
- Set Goals / Criteria

6. Decision Analysis
A. Conduct Economic Analysis
B. Conduct Sensitivity Analysis & Determine Vital Few
C. Conduct Non-Economic Analysis
D. Combine A, B, C into Decision Model

7. Does Alternative Meet Criteria?

No - Economic
- Non-Economic

Yes

8. Final Decision

15.7.3 Decision Model

Figure 15.7 illustrates a typical decision process used to choose among competing alternatives.

Step 1 develops feasible alternatives that are mutually exclusive. In this case alternatives are various bus
fleet sizes. In addition to alternatives, scenarios can be constructed which could combine alternatives
along with other factors such as potential breakdowns or disaster scenarios.

Step 2 estimates the capital and operating costs. The appendix explains the estimates for the case under
consideration.

Step 3 is the most critical step because of the need to estimate the benefits. Benefits can be savings in operat-
ing cost compared to a base case. This could be caused by a more fuel-efficient design than the base case.

Step 4 is the economic analysis. The first part is to establish economic criteria like Minimum Attractive
Rate of Return or MARR. The MARR reflects the opportunity cost for the investor’s capital. Risk plays a
role because some investments may be more risky than others may.
The time horizon needs to be determined. The owners need to decide to use full equity (% of loans)
or some sort of financial leverage (10% to 90% of loans). Generally, most companies conduct the eco-
nomic analysis using full equity and then, after choosing the most economical alternative, look at financ-

249
Engineering Management Handbook

ing options. Because this is an after tax analysis an applicable tax rate needs to be estimated for the chosen
time horizon.
The last criteria are the Figure of Merit (FoMs). Given that the ATA model is run on an Excel spread-
sheet it is relatively easy to report on more than one FoM. FoMs include the Net Present Value (NPV)
and the Equivalent Uniform Annual Cost or EUAC. EUAC is Life Cycle Costs (LCC).

Step 5 involves evaluation of the intangibles and non-economic factors impacting the decision. There
are a number of multi-attribute tools that can be used. Analytical Hierarchy Process (AHP) and Utility
Analysis are two common techniques.

Step 6 involves the decision process. Sensitivity analysis should be employed to determine the most sensi-
tive attributes that impacts / influences the decision. This helps to separate the “vital few” from the “trivial
many.” It is an aid in decision-making because it focuses the effort on the most important variables. Next,
a decision needs to be made whether an economic or non-economic analysis is to be employed. If all the
attributes can be monetized and converted into dollars then the standard ATA with a FoM such as NPV
or EUAC can be used to either maximize benefits or minimize costs. However, if the downtime cannot be
monetized then some form of non-economic analysis must be employed. There are at least three different
process flows depending upon the downtime values and costs. This will be discussed in the next section.

Step 7 involves the decision whether the analysis yields an alternative that meets the economic and/or
not-economic criteria. If it does than a decision is made. If it does not, the process needs to be repeated
starting with step number 1. This process needs to continue until a mutually exclusive feasible solution is
reached.

Step 8 is the final decision. If all the economic and non-economic criteria are met then a decision can be
made to accept the alternative under review.

15.8 References
Newman, Donald, Eschenbach, Ted and Lavelle, Jerome, Engineering Economic Analysis, Oxford Univer-
sity Press, 2004, ISBN: 0195168070; Library Number: TA177.4 N48 2004.
Merino, Donald and Lang, Hans, The Selection Process for Capital Projects, John Wiley & Sons, Inc., 1993,
ISBN: 0471634255; Library Number: TA177.4.L42.
Eschenbach, Ted, Engineering Economy – Applying Theory to Practice, Oxford University Press, 2002,
ISBN: 0195161521; Library Number: TA177.4.E833 2003.

250
 Project Management’s Role in Engineering Management

16
Project Management’s Role in
Engineering Management

Kenneth W. McDonald
United States Military Academy

251
Engineering Management Handbook

16.1 Introduction
Engineering management (EM) is a unique and specialized form of management that is focused on the
application of engineering principles to business practice. The EM discipline relates to management and
engineering by bridging the gap between the disciplines. As stated in Chapter 1, EM has undergone
tremendous adjustments to the discipline as trends in business and education have changed. This meta-
morphosis of EM is important to understanding how EM remains a very relevant and applicable disci-
pline in today’s world. As different areas of engineering have emerged, EM has adjusted to offer courses
in those disciplines and to produce quality EM engineers. As well, EM has ebbed and flowed with the
adjustments to the management career field. If one looks the EM profession, you will see a dynamic,
relevant and exciting field that embraces the changes associated with the professions of engineering and
management. It is through this open embrace of change that the EM profession maintains a tremendous
edge over other engineering disciplines. The EM professional becomes an expert in the field of engineer-
ing as well as management. In the engineering profession, the Accreditation Board for Engineering and
Technology (ABET) accredits EM programs and in doing so, EM majors can achieve the Professional
Engineering (PE) license and thus become recognized as an expert in the EM profession. Likewise, with
an EM degree, EM majors can also earn the Project Management Professional (PMP) certification, which
society recognizes those earning the PMP as experts in the field of project management. How is this pos-
sible? A degree in EM can produce experts in both fields of study (PE and PMP). What a tremendous
recognition of the value of the EM profession. This chapter focuses on the management aspect of the EM
profession. Specifically, project management.
When we look at project management’s (PM) role in EM, we need to understand where PM and EM
intersect in the real world. As stated before, EM is the bridging of disciplines of engineering and manage-
ment (Hicks, Utley, and Westbrook, 1999). In this context, the application of engineering principles to
an industrial challenge will in some way apply PM principles, tools and techniques. In industry, there are
constantly projects cropping up that fall in the realm of EM. Just from perspective of the realm of EM,
one can see that there is a natural tendency for engineer managers to run and participate in projects. From
developing improvements to production lines, bringing new technology online, etc., the engineer man-
ager will inevitably have to work in the realm of PM. Most everything becomes a project. It is what one
could consider a natural “tool set” that most engineer managers will need to master. In Figure 16.1, PM
encompasses the intersections of EM and engineering and management. It is in this realm that PM inte-
grates directly to EM. All engineer managers will run projects sooner or later throughout their careers.

Figure 16.1. Project Management Related to Engineering Management

Engineering
Engineering Management
Management

Project Management

16.2 Project Management

A project is a temporary endeavor undertaken to create a unique product, service, or result (PMI, 2013).
In the EM profession, projects are a major part of the profession and will be encountered over and over
252
 Project Management’s Role in Engineering Management

again. A project has a definite beginning and end and therefore temporary; however, it is does not mean
it is necessarily short in duration. Many projects can last for years and keep the EM professional engaged
throughout. Properly moving a project to completion requires knowledge and experience in PM. By
definition, PM encompasses the knowledge, skills, tools and techniques applied to tasks so that project
objectives can be met (Kerzner, 2006). PM is a discipline that requires study and experience to master.
Entire academic programs and books are devoted to PM and the tools and techniques used to implement
proper PM. As a profession, PM is well-known through the Project Management Institute, Inc. (PMI).
PMI developed the Project Management Book of Knowledge (PMBOK®) as a repository for up-to-date
PM processes, tools and techniques as approved by the PM profession.
PM integrates the PM processes known as initiating, planning, executing, monitoring and con-
trolling, and closing. In Figure 16.2, these processes are laid out as they are encountered in the PM
process. There is more than one way to manage a project to successful completion, and one could argue
that PM is more of an art than a strict science. One enters into the PM process by starting a project. The
project charter and scope are delivered during this phase. It provides the launching point from which the
project begins. After the project is started, the project moves into the monitoring and controlling aspect
of PM. The monitoring and controlling aspect of PM is critical. Failure to properly monitor and control
a project leads directly to cost over runs for a number of reasons the biggest of which is improper PM.
The monitoring and controlling processes observe project execution so that any potential problems and
challenges to successful completion may be identified as early as possible. Once challenges/issues are iden-
tified, corrective action is taken to avoid schedule slippage, cost overruns, and other detrimental effects
imposed by deviations from the plan. Monitoring and controlling must be performed frequently enough
to allow the PM sufficient cognizance of the health of the project so that any corrective action required
may be taken prior to events having an adverse impact on the project’s cost, schedule, or performance
(Parnell, Driscoll, and Henderson, 2010). These processes required to track, review and regulate the prog-
ress and performance of the project and identify any areas in which changes to the plan are required and
initiated the applicable changes. Making up the monitoring and controlling processes include initiating,
planning, executing and closing. The initiation process requires those items for initiating the project are
those required to define a new project by obtaining authorization to start the project (PMI, 2013).

Figure 16.2. Project Management Process Groups (PMI, 2013)

Monitoring &
Controlling Processes

Planning
Processes

Enter Phase/ Initiating Closing Exit Phase/

Start Project Processes Processes End Project

Executing
Processes

The planning process is critical for ensuring the project is completed on time, on budget and on
schedule. Poor planning is the number one contributor of project failure. Planning defines scope, ob-
jectives and the course of action required to attain the project objectives. Following the planning process
253
Engineering Management Handbook

is the execution. Execution is the processes required to perform and complete the work defined in the
plan. Planning and executing are represented by arrows forming a circular pattern. This pattern rep-
resents the iterative process of these two areas. The circular pattern indicates that planning and executing
both impact the other and that the two should be updated continuously through the project and adjusted
accordingly (PMI, 2013).
Nearing the completion of the project, closing the project becomes of great importance. The closing
processes are those performed to finalize any activity not completed across all aspects of the project to for-
mally close the project. Projects can continue on for extended periods of time if this phase is overlooked.
It is quite important to ensure that close-out procedures are executed with vigor similar to the beginning
of the project. In some cases, the end of the project seems to be given a less than enthusiastic effort be-
cause the team is tired and ready to move on. Indeed, most team members will be released (depending on
the project team structure) prior to the end of the project so that workforce becomes an issue. Finally the
project enters the exit phase the project is completed (PMI, 2013).
Obviously, there is more than one way to manage a project and bring it to successful completion.
The key is understanding how to apply the proper PM techniques associated with the six PM processes to
ensure success. PM becomes more of an art than a science.

16.2.1 Initiating Processes

The initiating processes are those processes that define the project and gain authorization to start. It is not
limited to starting new projects but it includes a new phase of an existing project, which is separate and
distinct. For in-phase changes, the project is normally very large or complex. The initiating process may
be performed at different levels (project, organizational, program, or portfolio). Likewise, the initiating
process can take on different approaches depending on the company/firm. One approach that is quite
successful if done correctly is stakeholder (customers, sponsors, etc.) involvement during the initiation
phase. This allows for more interaction and a shared understanding of the scope, success criteria and
deliverable acceptance. It can also allow for “value focused thinking” to become part of the process from
the beginning. Value focused thinking is the concept by where you inculcate stakeholder values into your
decision-making process. In the case of the initiation process, stakeholder values are addressed in the
initiating process by including stakeholders at the beginning to help shape the scope, process and delivera-
bles. It also ensures shared buy-in to the project management process (Parnell et al., 2010).
Initiating defines and authorizes the project through a project charter. It provides the project manager
the authority to execute the project using company/firm resources. A major aspect of this document is a
defined start, defined project boundaries, and the establishment of formalized project record (PMI, 2013;
Meredith, Mantel, and Shafer, 2015). The major inputs that assist in developing the project charter are:
a. Expert judgment: Expert judgement is expertise provided from within the company/firm as well as
any group or individual with specialized knowledge or training applicable to the project.
b. Statement of work: The project statement of work is a detailed description of the project deliverables
(products or services). The statement of work can come from within the company/firm if the project
is internal or from a number of external sources if the project is from outside the organization.
c. Business case: The business case describes the required information from a business perspective to
determine whether or not there is enough benefit to the company/firm to do the project. There are
several methods (numeric and non-numeric) for determining the level of cost vs. benefit of the project.
d. Agreements: Agreements are necessary and help define the objectives of the project. Agreements can take
various forms but regardless of form, the intent is to establish intent of the customer and service provider.
e. Enterprise environmental factors: Simply stated, enterprise environmental factors are those aspects
of the company/firm’s operating procedures as well as government and industry standards of practices.
Finally, marketplace conditions also come into play here and help set the conditions from which the
project will operate.
f. Organizational process assets: Are those processes established by the company/firm that are stan-
dard operating procedures. This includes templates (e.g., project charters), historical records, lessons
learned, after action reviews, etc.
254
 Project Management’s Role in Engineering Management

Hopefully, the results of these inputs will produce an effective project document that will lay the
foundation of a successful project. The project charter is a senior-level document that defines the scope
of project. It formally authorizes the project and gives the project manager authority to begin the project
and to employ company/firm resources toward the project. It includes, but is not limited to the following
(PMI, 2013; Meredith et al., 2015):
a. Purpose: A short and concise statement which includes the general goals of the project and their
relationship to the company/firm’s objectives.
b. Project objectives: More detailed statements of the goals, their priorities, defining success and how
the project is terminated.
c. Project overview: This is a higher level description of the project. A discussion of the management
and technical aspects of the project is included.
d. Project schedule: The project schedule is outlined to include major milestones and “phase gates.”
Major tasks are listed with associated time.
e. Project resources: Project budget is discussed in this section. There is detailing of capital and
expense requirements. All contractual items are listed in detail. The cost monitoring the control
procedures are addressed here as well.
f. Stakeholders: All key stakeholders are listed with appropriate insights and analysis accompanying
the list. The expected personnel requirements of the project are listed here as well. Additionally, any
special personnel requirements and training are addressed. Essentially, all unique requirements associ-
ated with personnel should be addressed.
g. Risk management plan: The risk management plan addresses mainly the high level risks that are
anticipated against the project. The risks are spelled out in detail so that they are clearly understood
to include the potential impacts to the project and company/firm. This section is quite critical and
requires tremendous effort. Although the effort is placed into this section, it cannot cover all poten-
tial catastrophes. However, if done correctly, the major anticipated risks can be identified and proper
mitigation measures taken to lessen their impact.
h. Evaluation methods: How a project performs is a matter of properly evaluating it against standards
and methods that are spelled out initially. The evaluation methods lay out a description of the proce-
dures used during the monitoring controlling of the project.

These are the basic elements of the project charter and constitute the foundation from which the proj-
ect management plan is developed. It should at a minimum set the high-level boundaries of the project.
The size and detail of the project charter depends on the size and complexity of the project.

16.2.2 Planning Processes

The planning process is critical to setting the conditions for overall success of the project. Indeed, inadequate
planning is the greatest contributor to most project failures. Poor planning makes achieving project schedule,
cost and performance objectives almost impossible. In the project planning process, the project management
plan is the deliverable. The project management plan allows for project scope and objectives to be clearly
defined and established. There are several techniques and approaches to assist in this planning effort.
The major inputs that assist in developing the project management plan are:
a. Project charter: As previously described, the project charter is the foundational document that sets
the project up for success.
b. Outputs from other processes: These represent a number of different outputs that can be used to
assist in developing the project management plan.
c. Enterprise environmental factors: As stated previously enterprise environmental factors are those
aspects of the company/firm’s operating procedures as well as government and industry standards of
practices.
d. Organizational process assets: Processes established by the company/firm that are standard oper-
ating procedures. This includes templates (e.g., project charters), historical records, lessons learned,
after action reviews, etc.
255
Engineering Management Handbook

The first step in the planning process is analyzing the preliminary project charter and project management
processes in order to develop a project management plan. The project management plan uses all the nec-
essary subordinate plans and integrates them into a cohesive effort directed toward achieving the project
goals. The project management plan encompasses the activities needed to identify, define, combine,
unify and coordinate the various processes to successfully accomplish the project. The subordinate plans
include, but are not limited to, (Kerzner, 2006; PMI, 2013; Meredith et al., 2015; Parnell et al., 2010):
• Scope management plan
• Requirements management plan
• Schedule management plan
• Cost management plan
• Quality management plan
• Process improvement plan
• Human resource management plan
• Communication management plan
• Risk management plan
• Procurement management plan
• Stakeholder management plan

These subordinate plans include project management techniques that allow the specific plans to be
implemented, monitored and controlled. For example, the project schedule management plan is used to
ensure that the project schedule is followed and maintained to ensure the project time and performance
objectives are achieved. The schedule management plan is a major input to the planning schedule man-
agement, defining activities, estimation of activity resources and durations and schedule development.
These plans become integral pieces to an overall complex planning process and require special attention
in order to achieve overall project success. For the purposes of this chapter, the specific management
plans listed will not be detailed. Suffice it to say, the project management plan takes tremendous effort to
pull off correctly; however, it is effort well spent if there are minimal instances of “changes” to the project
further into the project schedule. Changes that occur further into the schedule can have a tremendous
impact the overall cost of a project (PMI, 2013).
There are a number of project management methods and techniques that assist in developing the
project management plan. Understanding and mastery of these techniques are critical to the success of
the project manager and the project. Table 16.1 lists a number of the project management techniques.
For example, the work breakdown structure (WBS) is an effective technique to assist in the project scop-
ing process. The WBS is prepared to help determine the tasks required to complete a specific project.
The WBS is not limited to one particular format or structure. What is important is the process of break-
ing down larger tasks into smaller tasks. This becomes a hierarchical process – starting with an overall
project objective followed by successive smaller tasks until all tasks are identified. A WBS can appear as
a tree diagram (Figure 16.3) with level one tasks directly below the overall project objective followed by
level two tasks. In the case of a university cafeteria improvement project example, Figure 16.3 illustrates a
simplistic WBS (Meredith et al., 2015).

256
 Project Management’s Role in Engineering Management

Table 16.1. Project Management Tools and Techniques

a. Linear responsibility charts h. Earned value analysis

b. Scheduling i. Schedule baseline
- Schedule milestone list j. Cost baseline
- Activity sequencing k. Quality baseline
- Activity resource estimating - Quality assurance
- Activity duration estimating - Quality control
c. Project configuration management Requirements l. Risk
d. Order and magnitude cost estimate - Risk identification
e. Product acceptance criteria - Qualitative risk analysis
f. Resource allocation - Quantitative risk analysis
- Critical path method - Risk response
- Resource loading m. Critical path method
- Resource leveling n. Value engineering
- Constrained resource scheduling o. Stakeholder communication plan
g. Staffing management plan p. Document control register
q. Change control system

Figure 16.3. Work Breakdown Structure

University Cafeteria
Operations
Inprovement
Project

Food Delivery to Clean Up

Logistics Food Preparation
Customers Operations

Defrost
Food

Prep Food

Cook Food

The overall objective of this project is to increase the efficiency of the university cafeteria operations.
Under the level one task #2—food preparation—the three listed subtasks include defrost food, prepare
food and cook food. This logical breakdown allows planners working the project scope management
plan to accurately identify the requirements associated with every task supporting the objective of im-
proving cafeteria operations. Although this example may seem simplistic, the WBS is a highly effective
tool in supporting the project scope management plan. Other effective tools and techniques identified
during the planning process to include, but are not limited to, those identified in Table 16.1 (PMI, 2013;
Kerzner, 2006; Meredith et al., 2015; van Gigch, 1991; Forsberg, Mooz and Cotterman, 2000; Smith and
Reinertsen, 1998; Parnell et al., 2010).
Following work with the WBS the linear responsibility chart (LRC) is used in conjunction with
the WBS. When larger tasks are broken down to the basic tasks, a LRC can take those tasks and assign
proper personnel responsibility. The LRC shows the critical interfaces between tasks and individuals
and highlights areas that require special management attention (Meredith et al., 2015). Such a chart is
illustrated in Figure 16.4, which takes the cafeteria WBS in Figure 16.3 and assigns a number of tasks to
different individuals and teams. Note: a number of implied tasks are not listed on the WBS and include
project plan and budget.
257
Engineering Management Handbook

Figure 16.4. Linear Responsibility Chart

Senior Vice President for

Engineering Manager

Operations Manager

Lead Budget Analyst

Resource Manager
Logistics Manager
Program Manager

Engineering Team

Operations Team
Project Manager

Resource Team
Planning Team

Logistics Team

Budget Team
Lead Planner
Programs
Establish Project Plan 5 6 2,4 1,2 1 3 4 3 4 3 4 3 4 3 4
Establish Project Budget 5 6 2,4 4 4 3 4 3 4 3 4 1,2 3 3 4
Plan Efficient Cafeteria Layout 5 6 1,2 3 4 1,2 1 3 4 3 4 3 4 3 4
• Identify Planning Factors 5 6 6,2 3 3 4 3 4 3 4 3 4 3 4
• Determine Cost Factors 6 6 3 3 3 3 3 3 3 3 1,2 3 3 3
Plan Food Distribution Layout 6 6,2 3 4 1,2 3 3 3 4 4 4 4 3 3
Plan Resource Requirements 5 6,2 3 3 4 4 3 3 3 4 4 4 1,2 3
• Identify Material Requirements 5 6 3 4 4 4 3 3 3 4 4 4 1,2 3
• Identify Inventory Requirements 5 6 3 4 4 4 3 3 3 4 4 4 1,2 3
Acquire Kitchen Equipment 6 6,2 3 4 3 3 3 3 1,2 3
Plan Personnel Training 5 6,2 3 4 3 3 3 3 3 4 1,2 3

1 - Responsible 4 - Consultation Possible

2 - Supervision 5 - Must be Notified
3 - Consultation Mandatory 6 - Formal Approval

The associated generic managers and teams are included to demonstrate the complexity of the overall
organization and the interfaces between departments. As you move from left to right in the chart, you
will notice relationships with particular individuals and teams. The project management plan is import-
ant because it is the foundation for executing the project. Indeed, formal approval is most likely to occur
all the way through the chain of command from the project manager, through the program manager, to
senior vice president for programs. The LRC illustrates the relationships between the lead planner, his or
her team and the other departments. For planning purposes, it is important to consult each department
because they have valuable information that the planner uses. At a minimum, the lead planner needs to
consult with each department manager. As would be expected, a 3 is used to identify a mandatory con-
sultation requirement on the part of the lead planner. You can argue that the lead planner has a mandato-
ry requirement to consult with the team as well but may not be how the organization is set up. In
this case, it is assumed that the department managers are the “gatekeepers” to their departments and
that the lead planner needs to consult with them versus going directly to the department team (Parnell
et al., 2010).
Solid work must be part of planning process to ensure success of the project. Many projects fail,
regardless of size, when left to planners or individuals who have limited practical experience. Therefore,
experienced project managers must be part of the planning team for the plan to be a success. Their expert
advice brings a level of practical experience that equates to time and money savings when the final project
management plan moves to execution. As Figure 16.2 illustrates, the planning process is an iterative
process that includes the executing and monitoring and controlling processes. As execution begins, there
are inevitable changes (information updates, challenges with resource allocation, scheduling delays, value
engineering ...), which are identified in either the executing or monitoring and controlling processes.
Once identified, the change/information is fed back into the planning phase to allow for project manage-
ment plan updating. No one can predict the changes that occur and therefore the close integration of the
258
 Project Management’s Role in Engineering Management

planning, execution and monitoring and controlling processes is essential for success. The project man-
ager must constantly seek this type of feedback in order to adjust the plan and execute accordingly. The
only certainty is change so the project manager must be ready to adjust (Parnell, 2010).

16.2.3 Executing Processes

The executing processes consist of those processes that are executed to complete the scope of work identi-
fied in the project management plan. Very concisely, the executing process involves tremendous coordi-
nation of personnel and resources, stakeholder expectation management, and executing all directed and
implied tasks associated with the project management plan. It is complete project integration manage-
ment. The executing processes integrates the management areas of quality assurance, human resources,
communications, procurement and stakeholder. The executing process requires the PM team to perform
a myriad of actions to execute the project management plan.
As discussed, the project management plan is made up of several specific management plans that
utilize several tools and techniques to execute the project. The PM team is required to orchestrate the in-
tegration of these plans. Additionally, the PM team must track the deliverables (products, results and/or
services) from each of the subordinate plans. Of particular importance is the communications plan. The
distribution of accurate information allows the PM team to track progress and status of the project. An-
other important task is managing stakeholder expectations. Stakeholder’s involvement during this process
is troublesome at times. The project manager should always be aware of what information is passed along
to stakeholders. Projects do not go well all the time but, if executed correctly, they do become successful.
Stakeholders, not unexpectedly, react to downturns and poor performance that naturally occur during the
project’s lifecycle. If the project manager the information passed to stakeholders is not handled correctly
it becomes problematic. Additional tasks during the executing process include but are not limited to
(PMI, 2015):
• Direct and manage project work
• Perform quality assurance
• Acquire project team
• Develop project team
• Manage project team
• Manage communications
• Conduct procurements

It is in the best interest of the project manager and the company/firm to ensure information that
affects the project management plan be updated as quickly as possible to ensure appropriate corrective/
improvement action is implemented in a timely manner. Most deliverables take the form of tangible
items such as a road, building, etc., but intangible deliverables such as training, information, etc. are also
provided. The executing process is complex and requires integration of many areas (PMI, 2015).

16.2.4 Monitoring and Controlling Processes

The monitoring and controlling processes consists of those processes whose function is to track and
manage the progress and performance of the project. In controlling the project, data is gathered, which
requires a change to the project, and changes are made to the project plan according. The monitoring
and controlling process is an iterative process, which ebbs and flows accordingly. In Figure 16.2, the
monitoring and controlling process encompasses all the other processes and rightly so. It is through these
processes that adjustments are made throughout the project in response to heartbeat of the project. Like
a flowing stream, when faced with an obstacle, adjusts its flow but continues its journey until it reaches its
final destination. It never stops but continues to progress and adjusts accordingly. The fundamental pur-
pose of the monitoring and controlling process is to monitor the other processes so that effective control
measures be directed to keep the project performing to expected performance expectations, on time, and
below cost (Meredith et al., 2015).
259
Engineering Management Handbook

One of the first steps to proper monitoring is identifying those essential elements requiring control.
The first item for consideration for a project manager is control of performance, time and cost. The proj-
ect manager must establish clear boundaries for control and identify the level of importance for each cat-
egory. It is safe to say that the boundaries and level of importance are not the same for each project and
are driven by the project’s overall project charter (Meredith et al., 2015; Fisk et al., 2004; Palmer, 2006).
Continuous monitoring in each of the subordinate plans allows the PM team to keep current with the
changing dynamics of the project and to register the project’s health through the prism of performance,
time and cost.
In Figure 16.5, the three main project concerns are scope, time and cost. A project manager is always
concerned with these three and they are referred to as the golden triangle. Figure 16.5 demonstrates
how continuous monitoring of a project motivates confidence for a project manager that the project is
on-track or that it requires action to restore it to the proper status. Figure 16.5 is a three-dimensional
“snapshot” of the project status at a specific time and compares the cost and required results. The project
manager can see where the actual project is in relation to the “performance target.” For example, if the
actual results right of the performance target, the project manager can see that for the given performance,
the cost is too high, which means that the project is exceeding the budgeted amount for a given value.
Therefore, corrective action by the project manager is required.

Figure 16.5. Project Performance Target = Scope, Time, and Cost

The actions of the project manager are varied depending on his/her level of authority. The project
manager can either, increase resources (money, equipment or personnel) or shorten the time. An exam-
ple of shortening time is called “crashing the schedule.” Crashing the schedule is a technique used in the
critical path method to bring a project back on schedule if a particular task is going over the scheduled
time allowed. This technique requires placing resources against the task in order to reduce its duration.
The obvious outcome of using this technique is increasing the cost of the project. The project manager
and the team understands the importance of these monitoring and controlling techniques and will ensure
analysis of the results provide an accurate picture of the project’s status (Parnell et al., 2010).
There is also earned value (EV), which is also a method for monitoring a project. EV analysis is a
commonly used method for measuring the overall performance of a project (PMI, 2013, Meredith et al.,
2015, Parnell et al., 2010). It is a comparative analysis of the projected budget, actual costs and the work
accomplished (value). Figure 16.6 illustrates an EV graph representing the facility layout portion of the
university cafeteria facility renovation in Figure 16.3. In this example the EV is lagging behind the bud-
geted amount and the actual expenditures. The project manager will conclude that the project is behind
schedule. The project cost to-date exceeds the value accumulated for the work performed.
260
 Project Management’s Role in Engineering Management

Figure 16.6. Earned Value Graph

The chart also tells another story beyond a summary of goals being achieved or not. The contractor is
surging as indicated by the stair stepping pattern of the EV line. This pattern normally indicates chal-
lenges with the contractor. At the 25 February date, the contractor is stagnant (EV does not increase) as
expected with most project start dates. The project manager responds with an increase in actual budget
expenditure. Cash flow is extremely important for the contractor as well as the project manager. Both
have expectations (project manager—value for the money expected and the contractor—money necessary
to create value) and these expectations must be balanced by both parties. Even though the EV is below
what the project manager would want, there are situations where paying the contractor ahead of the EV
is the best course-of-action for project success. This occurs most often when a good working relationship
is established between the project manager and contractor. In this case, continuing to work with the
contractor to keep progress going instead of, for example, dismissing him from the project and pursuing
litigation is probably the best course of action for the PM in this case. The data past the 11 March date
shows that the contractor responded with an upsurge in the EV. However, on 25 March, the contractor
slows down again and EV begins to plateau. In this instance, the PM reacted differently and lowers the
payment to the contractor in order to get him to respond. Of note is near the end of the project, there
is great gain in EV for the overall project. This is a very typical pattern for a renovation project. Engi-
neers have a tendency to estimate a concave shape over the project, indicating optimism in terms of how
quickly value (functionality, performance) can be developed. In reality, the EV curve assumes a convex
shape because of rework imposed by test failures, delayed schedules and response surges in activity, and
cost-conserving measures put in-place to mitigate the threat of running out of budget before the expected
(or required) value has been delivered. Although it is not what a project manager would like to see, this
is not uncommon for a project that was behind schedule as depicted in this example (Parnell et al., 2010;
Meredith et al., 2015).
The monitoring and controlling process uses (PMI, 2013):
a. Expert judgment: Use of the judgment of the project manager and the PM team. They interpret the
information provided and develop appropriate actions.
b. Analytical techniques: These techniques help forecast budget and value outcomes. These include but
are not limited to:
• Regression analysis
• Grouping methods
261
Engineering Management Handbook

• Causal analysis
• Root cause analysis
• Forecasting methods
• Failure mode and effect analysis
• Fault tree analysis
• Decision tree analysis
• Reserve analysis
• Trend analysis
• Earned value management
• Variance analysis
c. Project management information system: This is part of enterprise environmental factors and encom-
passes a host of information systems and are limited only by the company/firms commitment to these
systems.
d. Meetings: Meetings are critical if done efficiently and effectively. Effort must be placed into proper
meeting management. If not done correctly time and resources are wasted.

The outputs from the monitoring and controlling process establish guidance for change to the proj-
ect. A number of products are produced from the tools and techniques mentioned earlier. These include,
but are not limited to, (PMI, 2013):
e. Change requests: Change requests are the result of the comparison of planned results and actual
results. Change requests can impact project scope (expand, adjust, and/or reduce). Impact from
change requests must be followed through by the project manager and PM team. Attention to the
secondary and tertiary effects of any change cannot be understated. Therefore, it is understood that
policies and procedures should be developed by the company/firm. Several changes can occur and
listed below are a few more common ones (PMI, 2013).
• Corrective action
• Preventive action
• Defect repair
f. Work performance reports: Work performance reports are essentially documentation of actual work
performed. It is important that a physical or electronic copy of the work performed be cataloged and
stored for the duration of the project. Although not mentioned earlier, document control is critical
here. In most companies/firms, document control is a full-time job, requiring a certain skill level.
g. Project management plan updates: These updates are focused on all the project management plans
used to keep the project tracking on time, on budget and at performance. Each of these management
plans are listed (PMI, 2013):
• Scope management plan
• Requirements management plan
• Schedule management plan
• Cost management plan
• Quality management plan
• Scope baseline
• Schedule baseline
• Cost baseline
h. Project documents update: This is the process of updating all project documents required to manage
the project. These documents include, but are not limited to (PMI, 2013):
• Schedules
• Cost forecasts
• Work performance reports
• Field changes
• Challenge logs

262
 Project Management’s Role in Engineering Management

16.2.5 Closing Processes

The closing process is the most difficult of the process groups for a number of reasons. A good project
manager will ensure that closeout procedures are closely adhered to so that the project can be properly
turned over to the client and that anything required legally is completed correctly. The closing process
involves all the necessary administrative and contractual closing procedures to ensure proper project close-
out. This process includes all the subordinate project plans as well as any phases (complex/large projects)
that are associated with the project. The administrative closing procedures are those procedures and
project relationships dealing with different aspects of the project (PMI, 2013).
The largest portion of the administrative work required includes documentation control and ar-
chiving. This process is important just in case there is possible legal action taken against the company/
firm. All contracts start out with good intentions on the part of both parties, but there are lawsuits
brought against a company/firm by a contractor for numerous reasons. Good document control plan
allows the project manager and the PM team too quickly and efficiently respond to any legal request. The
contract closure procedure includes those activities needed to complete contractual obligations. These
include, but are not limited to, (PMI, 2013):
• Formal acceptance by the customer
• Post-project review
• Record impacts
• Document all lessons learned
• Apply appropriate updates (organizations, billing, operational procedures, etc.)
• Archive all relevant documentation
• Close out procurement activities and termination of all applicable agreements
• Perform team members’ assessments
• Release project resources

One important process is ensuring proper contractor documentation completion. Near the end
of most projects, the daily progress reports will tend to get overlooked in the last few weeks, especially
if a contractor is near 100% paid. If a project manager fails to hold the contractor to full compliance
for contractual requirements such as progress reporting, the project manager is liable. It is imperative
that the PM team ensures all aspects of close out procedures are adhered too and followed (Parnell
et al., 2010).

16.3 Summary
Engineering management is a tremendously relevant and important discipline. It bridges the gap between
management and engineering. This bridge is supported by a number of difference disciplines. Of most
import is PM. PM as it relates to EM is nestled in an arching way to assist the EM professional in being
able to manage projects. Many of those skills found in EM are found in PM. Proper PM consists of
initiating, planning, executing, monitoring and control and closing processes.
The initiating processes are those processes that define the project and gain authorization to start. It
is not limited to starting new projects but it includes a new phase of an existing project, which is separate
and distinct. For in phase changes, the project is normally very large or complex. The initiating process
may be performed at different levels (project, organizational, program, or portfolio). Likewise, the initiat-
ing process can take on different approaches depending on the company/firm. A major deliverable coming
out of the initiating processes is the project charter. Several inputs occur during this initial process phase,
which include expert judgment, statement of work, business case, agreements, enterprise environmental
factors and organizational process assets.
The planning process is critical to setting the conditions for overall success of the project. Poor
planning makes achieving project schedule, cost and performance objectives almost impossible. In in the
project planning process, the project management plan is the deliverable. The project management plan
allows for project scope and objectives to be clearly defined and established. There are several techniques
and approaches to assist in this planning effort. The major inputs that assist in developing the project
263
Engineering Management Handbook

management plan include the project charter, outputs from other processes, enterprise environmental
factors and organizational process assets.
The executing processes consist of those processes that are executed to complete the scope of work
identified in the project management plan. Very concisely, the executing process involves tremendous
coordination of personnel and resources, stakeholder expectation management, and executing all directed
and implied tasks associated with the project management plan. It is complete project integration man-
agement. The executing processes integrates the management areas of quality assurance, human resources,
communications, procurement and stakeholder. The executing process requires the PM team to perform
a myriad of actions to execute the project management plan. These requirements include but are not lim-
ited to direct and manage project work, perform quality assurance, acquire project team, develop project
team, manage project team, manage communications and conduct procurements.
The monitoring and controlling processes consists of those processes whose function is to track
and manage the progress and performance of the project. The monitoring and controlling process is an
iterative process that ebbs and flows accordingly. It is through these processes that adjustments are made
throughout the project in response to heartbeat of the project. The monitoring and controlling never
stops but continues to progress and adjust accordingly. The fundamental purpose of the monitoring and
controlling process is to monitor the other processes so that effective control measures be directed to keep
the project performing to expected performance expectations, on time, and below cost. The monitoring
and controlling process uses expert judgment, analytical techniques, project management information
system and meetings.
The closing process is the most difficult of the process groups for a number of reasons. A good proj-
ect manager will ensure that closeout procedures are closely adhered to so that the project can be properly
turned over to the client and that anything required legally is completed correctly. The closing process
involves all the necessary administrative and contractual closing procedures to ensure proper project close-
out. The closing process requires formal acceptance by the customer, post-project review, record impacts,
document all lessons learned, apply appropriate updates, archive all relevant documentation, close out
procurement activities and termination of all applicable agreements, perform team members’ assessments
and release project resources.

16.4 References
Forsberg, K., Mooz, H., and Cotterman, H., Visualizing Project Management. 2nd Ed. New York: John
Wiley & Sons, Inc., 2000.
Hicks, P., Utely, D., and Westbrook, J., “What are we teaching our engineering managers?” Engineering
Management Journal, vol. 11, no. 1, March 1999, pp. 29-34.
Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 9th ed.,
Hoboken, NJ: John Wiley & Sons, Inc., 2006.
Palmer, D., Maintenance Planning and Scheduling Handbook. 2nd ed. New York: McGraw-Hill, 2006.
Parnell, G., Driscoll, P., and Henderson, D., Decision Making in Systems Engineering and Management.
2nd Ed., New York: John Wiley and Sons, 2010.
PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th ed., Newtown Square,
PA: Project Management Institute, Inc., 2013.
Smith, P. G. and Reinertsen, D. G., Developing Products in Half the Time. 2nd ed. New York: John Wiley
& Sons, Inc., 1998.
van Gigch, J. P., System Design Modeling and Metamodeling. New York: Plenum Press, 1991.

264
 Systems Engineering

17
Systems Engineering

Robert Cloutier
Stevens Institute of Technology

Mary Bone
Stevens Institute of Technology

265
Engineering Management Handbook

17.1 Introduction
17.1.1 What is Systems Engineering?
Although the discipline called systems engineering (SE) may seem self-descriptive, the concept is de-
ceptively difficult to define. One must begin with an understanding of what constitutes a system. The
International Council on Systems Engineering (INCOSE), which is the largest professional organization
dedicated to the practice and advancement of SE, defines a system as “a combination of interacting ele-
ments organized to achieve one or more stated purposes” (INCOSE, 2011).
Possibly a more descriptive definition was provided by Rechtin (1991) who said a system is “a set of differ-
ent elements so connected or related as to perform a unique function not performable by the elements alone.”
Rechtin went on to explain that one could disassemble an automobile (which can be defined as a
system that has the function of transportation) and spread the parts out on the ground. While all the parts
are there, no single part is able to transport a person from one place to another. It takes the assemblage of
those parts, in a specific manner, for the system to be able to provide the unique function of transporta-
tion not found in any individual part, nor in a partial collection of the parts—it takes the whole set.
Therefore, if a system is a collection of parts, which when assembled in a specific manner, are able to
perform a purpose, then SE must be the practice of designing such a system. However, going back to our
automobile, many different engineering disciplines are required for that design to be accomplished. Ex-
pertise in internal combustion engines is required, as is in automobile body design, human controls, and
even electrical wiring. Knowledge from all of these domains (and many others) is necessary to design this
system called an automobile. INCOSE (2004) defined SE as “an interdisciplinary approach and means to
enable the realization of successful systems.” However, this definition was been expanded by INCOSE in
Version 3.2.2 of their handbook (INCOSE, 2011):
Systems Engineering is an interdisciplinary approach and means to enable the realization of
successful systems. It focuses on defining customer needs and required functionality early in the
development cycle, documenting requirements, and then proceeding with design synthesis and
system validation while considering the complete problem. Systems Engineering considers both the
business and the technical needs of all customers with the goal of providing a quality product that
meets the user needs.

It becomes clear from this definition that SE is an approach to creating a system that will satisfy
the desired functionality goals of the system. The approach includes defining the system, designing the
system, and validating the system—ensuring the right system was built. SE is a collection of tasks that are
necessary to provide a quality system to a customer.
Figure 17.1 represents a mind map of key SE concepts. The major branches are perspectives, manage-
ment, technical and focus. The branches flowing out of those key concepts further describe those con-
cepts. These key concepts will be further discussed throughout this chapter.

Figure 17.1. Mind Map of SE Key Concepts (Cloutier, Baldwin, and Bone, 2015)

266
 Systems Engineering

Stevens Institute of Technology has put forth the following definition for SE:
Systems engineering is the translation of a need/deficiency into a system architecture through
the iterative process of functional analysis, allocation, implementation, optimization, test, and
evaluation. It incorporates all technical parameters to assure compatibility between physical and
functional interfaces, hardware and software interfaces, in a manner that optimizes system defini-
tion and design; and the integration of performance, manufacturing, reliability, maintainability,
supportability, global flexibility, scaleability, upgradeability and other specialties into the overall
engineering effort.

In this chapter we will also look at the steps necessary to provide such a quality system, and what
processes are involved when someone performs SE. But first, let us look into the history of SE to better
understand how the discipline has arrived at where it is today.

17.1.2 Why Did Systems Engineering Originate?

While some will state “systems engineering is a new engineering discipline”, that is actually incorrect.
Although SE is relatively newer when compared to classical engineering, such as mechanical and civil, it
has existed as a discipline since before World War II. Later, NASA was in need of an approach to meet
President Kennedy’s challenge—take a man to the moon and back by the end of the decade.

Figure 17.2. U.S. Army Corporal Sounding Rocket

SE began to emerge in a number of companies in the late 1940s and early 1950s that were attempting
to solve complex problems. AT&T Bell Labs needed an approach to provide in transmission designs, as
well as a way to provide consistent communications with Western Electric; JPL was developing the U.S.
Army Corporal sounding rocket in 1945 as shown in Figure 17.2 and found they lacked any consistency
in the engineering processes, and that the rocket was very unreliable. Both efforts needed a process to
transition new ideas from research concepts into engineering designs.
Later, NASA was in need of an approach to meet President Kennedy’s challenge – take a man to the
moon and back by the end of the decade.
The common denominator in each of these needs was an interdisciplinary approach to integrate com-
plex ideas and concepts into a system that would allow a complex idea to become a reality.
Arthur Hall wrote an early textbook detailing the practice of SE at that time. Figure 17.3 is the cover
of Hall’s book published in 1962 . He noted in the Preface that “the growing recognition of the need for
SE over the past decade has been attended by the need for philosophical foundations.” He stated that his
267
Engineering Management Handbook

book was intended “to increase awareness and understanding of SE as a process, and to sharpen defini-
tions and approaches to the main recurring problems of the process-problem definition, goal setting,
systems synthesis, systems analysis and choice among alternative systems.”

Figure 17.3. Hall’s Book on Systems Engineering, Published in 1962

17.1.3 The Systems Engineering Lifecycle

Everything has a lifecycle. Animals are conceived, born, and mature into adults, enter old age, and then pass
away. The same can be said about a system. It is conceived by the customer, an engineer, or both; the idea is
further developed into a concept. Some preliminary design is conducted to ensure the system is feasible, and
if it is determined to continue, detail design and development ensues. The product is produced and used,
and at some time, the system outlives its usefulness and is retired. This is the systems lifecycle.
There are many different lifecycles defined by various experts for SE, and the lifecycle used on a proj-
ect is normally dictated by the industry or customer. Figure 17.4 shows some typical lifecycles.

Figure 17.4. Common Systems Engineering Lifecycles in Use Today

Typical High-Tech Commercial Systems Integrator

Study Period Implementation Period Operations Period
User Concept System Acq Source Operations
Requirements Specification Prep Select. Development Verification Deployment and Deactivation
Definition Phase Phase Phase
Definition Phase Phase Phase Phase Maintenance Phase
Phase Phase

Typical High-Tech Commercial Manufacturer

Study Period Implementation Period Operations Period
Product Product Product Engr Internal External Full-Scale Manufacturing,
Requirements Definition Development Model Test Test Production Sales, and Deactivation
Phase Phase Phase Phase Phase Phase Phase Support Phase Phase

ISO/IEC 15288
Utilization Stage
Concept Stage Development Production Retirement
Stage Stage Stage
Support Stage

US Department of Defense (DoD) 5000.2

A B C IOC FOC

Pre-systems Acquisition Systems Acquisition Sustainment

System Production
Development and and Operations and Support
Concept and Technology Development (including Disposal)
Demonstration Deployment

US Department of Energy (DoE)

Project Planning Period Project Execution Mission

Pre-Project Preconceptual Conceptual Preliminary Final Construction Acceptance Operations

Planning Design Design Design

Typical
Decision New Initiative Concept Development Production Operations Deactivation
Gates Approval Approval Approval Approval Approval Approval

Adapted from: INCOSE Systems Engineering Handbook, v.3.1

268
 Systems Engineering

Although each of the lifecycles accomplishes the same work, the order or naming conventions used may
differ. In Figure 17.4, one of the lifecycles is that documented by ISO/IEC 15288 Systems Engineering—
System Life Cycle Processes (ISO/IEC 15288, 2015). The remainder of this chapter will use that lifecycle to
discuss SE. There are a number of supporting processes that also occur, and are shown in Figure 17.5.

Figure 17.5. ISO/IEC 15288 SE Processes – Gray indicates changes in 2015 revision

SE is concerned with all aspects of the systems lifecycle, and must consider each part of the lifecycle
during the design and development of a new system. As can be seen by studying Figure 17.5, many of
these processes are very specialized, and can take some time to master. This is an important aspect of SE.
Although a systems engineer must be aware of, and knowledgeable about each process, on large and/or
complex projects, the execution of each process may be conducted by a systems engineer that has become
an expert in that particular process.
The purpose of this chapter is not to explore each process, but to introduce the reader to the more
significant processes and let the reader explore the remaining processes by reading ISO/IEC 15288. This
chapter will further explore the following phases that can be mapped to 15288:
• Stakeholder Requirements Definition
• Requirements Analysis
269
Engineering Management Handbook

• Architecture Design
• Implementation
• Integration
• Verification
• Transition
• Validation
• Operation and Maintenance
• Disposal

17.1.4 The Role of Systems Modeling and Systems Simulation

A topic that does not fit into the processes listed in ISO/IEC 15288: 2015, and many times is described
by the tool being used is system modeling and simulation. On the surface, modeling seems to be a
straightforward concept. A model is a facsimile of the item of interest. When one sends a fax of a memo
using a fax machine, the original is copied, and a facsimile of the original is transmitted. Alternatively, one
may build a model of a volcano out of clay for a science project. By no means is the model a volcano—it
is a representation of a volcano. Models need not be exact—they only need to emphasize that part of the
item of interest that is to be examined. While the model of a volcano may look like the original, it does
not have to display, nor could it, the extreme temperatures of the flowing lava and the life threatening
nature of the gases expelled.
In the SE domain, modeling and simulation are words that elicit different mental models, based
on the training and experience of any given systems engineer. To some, it will mean dynamic modeling
or simulation of the system to predict or understand system performance. To others, it may evoke the
thought of cost modeling to apportion cost and to ensure the system in built within a specified budget.
And to others it may mean using the use of the Object Management Group’s (OMG, 2008) Systems
Modeling Language (SysML, 2008). There is no agreement to the proper terminology, so the proposed
terminology used here is that preferred by the author. It is beyond the scope of this chapter to go into
more depth of this topic. If the reader is interested in more detail, the INCOSE Model Based SE
(MBSE) working group, and the OMG website would be good starting places.

17.2 Stakeholder Requirements Definition

This phase is sometimes referred to as requirements elicitation. Stakeholders are anyone that will be
affected in anyway by the system of interest, that is, the system being designed. The stakeholders may be
active stakeholders, or passive stakeholders. Active stakeholders are individuals, things, or other systems
that play an interactive role during the operation of the system of interest. One easily overlooked active
stakeholder might be the environment—rain, snow, and ice may play a very acute role with an automo-
bile, and therefore might be considered an active stakeholder. Passive stakeholders are individuals, things,
or other systems, protocols, procedures, etc., which can influence the success of the system. For instance, a
regulatory body such as the Department of Transportation is a passive stakeholder in the design of a new
automobile.
During stakeholder requirements definition, the goal is to capture the functionality and attributes
of the system of interest, in the words of the individual stakeholders. Functionality is what the system
of interest does—go fast, hold five passengers, etc. The attributes of the system of interest is that it is
safe, that it fits on the roads, etc. It is important to ask probing questions, and fully understand the
customer needs. A recommendation is to capture the stakeholder requirements using a noun-verb form.
For instance:

The driver will be able to listen to the radio while driving the car.

The noun is the “driver,” and the verb is “listen.”

270
 Systems Engineering

17.2.1 Use Cases and Scenarios

One method that is helpful in eliciting requirements from the stakeholders is to develop use cases or
scenarios. This is done by working with the stakeholder to capture graphically or textually a description
of how the system of interest will be used. In all probability, there will be a number of different scenarios
that must be captured. For instance, there may be scenarios for normal operations, degraded operations,
maintenance operations, and failed operations to name a few. Other scenarios may include daytime oper-
ations, night operations, foul weather operations, etc. The more of these conditions that are understood
early, the probability of a more complete set of requirements increases. Figure 17.6 is a sample operational
use case for a hybrid SUV.

Figure 17.6. Sample Hybrid SUV Operational Use Case

uc HSUVUseCases [Operational Use Cases]

HybridSUV

Start the v ehicle

«extend»

Driv e the v ehicle Accelerate

«include»
Driv er

«include»

Steer
«include»

Brake
Park «include»

Adapted from: Sparx Enterprise Architect tool, http://www.sparxsystems.com/

17.2.2 Performance Criteria

During the requirements elicitation, it is important to understand “soft” words used by the stakeholders.
Word like: better, lower than, improved, and improved reliability are difficult to design and verify. All
efforts should be made during this phase to reach some quantifiable agreement to what each term means.
Examples of this might include:
• 25% improved reliability over current performance
• 5% better gas mileage than existing models
• Whites are 10% whiter, as measured using an optical spectrometer

17.2.3 Inputs and Outputs

Another important aspect to understand during requirements elicitation is what interfaces exist between
the system of interest and those systems or entities that come in contact with the system of interest. While
it is a simple example to understand what the inputs for an automobile will be: fuel, cargo, passengers,
security, etc.—these all may have some influence on the design. Same is true for outputs—emissions and
horsepower for instance. Table 17.1 shows a simple input/output matrix with examples of the type of data
that might be useful for typical inputs and outputs.
271
Engineering Management Handbook

Table 17.1. Input/Output Matrix

INPUTS OUTPUTS

Intended Unintended Desired Undesired

Pulse shape, data
Error rates, false
Signal rate, signal to noise Electrical noise Data rate, accuracy
alarm rates
ration

Electromagnetic
Surge voltages Voltage, current,
Electrical Nominal voltage interference,
and timing frequency, stability
electrical shock

Shock and Acoustic noise

Mechanical Activation force Movement, resistance
vibration levels

Temperature
Normal Particle density, air
Environmental and humidity Heat, effluents
temperature range flow
extremes

17.2.4 Conclusions
The key during this phase is to listen to the customers, and gather as many requirements as you can. Try
to understand what the customer is asking for, and what they are not saying—capture everything possible
using dedicated note takers, audio, video—anything that will help recall the conversations. It is also im-
portant to understand that mistakes, including poorly communicated or wrong information, at this phase
can lead to expensive and time consuming fixes later. This is best demonstrated by the diagram shown in
Figure 17.7. It shows that the cost to extract defects goes up exponentially the later in the program they
are discovered.

Figure 17.7. Input/Output Matrix

272
 Systems Engineering

17.3 Requirements Analysis

During requirements analysis the systems engineer will sort, assess, evaluate, combine, and expand on the
stakeholder requirements for the purpose of better understanding the system of interest in the context of
the performance and system constraints expressed by the stakeholders. System requirements are normally
expressed in the form of “shall” statements, and express some capability the system is expected to perform.
A well-formed system requirement should contain a single measurable capability to avoid confusion or
conflict. Examples of well-formed requirements might be:
R1 The door shall allow people to pass between the living room and the kitchen
R1.1 The door shall comply with the 2006 International Residential Code® New Jersey Edition
R1.2 The door shall permit people to see between rooms
R1.3 The door shall be equipped with a lock

It is also likely that during the interviews and discussions with the stakeholders, conflicting require-
ments were discovered—one stakeholder wants it to be ecologically responsible, and the other wants it
to have very high horsepower. The systems engineer will work to resolve or balance these two apparently
conflicting requirements. It is important that the systems engineer create a requirements traceability ma-
trix to track the source of each requirement and how each requirement will be verified to ensure it is satis-
fied. This becomes important as the system evolves—sometimes requirements must be modified, or even
deleted. One must know the source of the requirement to gain approval/concurrence with the change or
deletion. Table 17.2 contains a requirements traceability matrix that is used to track requirements.

Table 17.2. Requirements Traceability Matrix

Requirement Source Acceptance Criteria Test Type/Test Method

C1 Stakeholder B Horsepower >= 250 Test

C2 Stakeholder A Emissions <= 2 ppb Test

Once the requirements are captured, documented, and understood, they must be translated into
system objectives and specifications to guide the engineering process moving forward. A common tool for
this is Quality Function Deployment or QFD for short. QFD is a design practice used to facilitate trans-
lation of stakeholder characteristics into system objectives and specifications at each stage of the system
design and development process. According to an Industry Week (1993) survey, organizations applying
QFD for the identification and analysis of product requirements realized:
• 30% to 50% reduction in engineering charges;
• 30% to 50% reduction in design cycle time;
• 20% to 60% reduction in start-up costs; and
• 30% to 50% reduction in time to market.

Later in the article, they cited Du Pont’s Beech Street Engineering Center Group, Wilmington, DE
reporting a 75% reduction in product design cycle time after making QFD an integral part of a newly
revamped design structure. Another success story was Ford Motor Company that adopted it in 1984,
and by 1988 it was being implemented on 50 different applications. It is beyond the scope of this chap-
ter, however, see Guinta and Praizler (1993) and King (1989), which are two excellent references on this
subject.
The totality of all the gathered requirements—whether they come from the stakeholders, are derived
as the system is understood, or come from a government agency or standard—are then compiled into
the system specification. This system specification should represent all the capability and limitations of the
system of interest, and will be the governing document for the rest of the design by which all work is
measured by asking—is this needed to satisfy the system of interest.
273
Engineering Management Handbook

17.4 Architectural Design

Every system has an architecture, whether it is implicitly understood, or explicitly designed. According to
INCOSE, the architectural design process is to synthesize a system solution that satisfies the requirements
(INCOSE Handbook). IEEE Std. 1471-2000 IEEE Recommended Practice for Architectural Description
of Software Intensive-Systems defines architecture as the fundamental organization of a system embodied
in its components, their relationships to each other, and to the environment, and the principles guiding
its design and evolution.
According to IBM Fellow, Grady Booch (2005), the elements of an architecture include:
• Architecture defines major components
• Architecture defines component relationships (structures) and interactions
• Architecture omits content information about components that does not pertain to their interactions
• Behavior of components is a part of architecture insofar as it can be discerned from the point of view
of another component
• Every system has an architecture (even a system composed of one component)
• Architecture defines the rationale behind the components and the structure
• Architecture definitions do not define what a component is
• Architecture is not a single structure—no single structure is the architecture

To summarize this, a system architecture defines the major parts of a system, and how those parts will
interact with each other to satisfy the overall system requirements as defined by the stakeholders. For large
systems, this work is normally performed by an experience system architect. Architects normally produce a
number of products to document the architecture. A number of frameworks exist that provide guidance on
what architecture products should be produced. Some of the better known architecture frameworks include:
• ZEAF—Zachman Enterprise Architecture Framework
• DoDAF—Department of Defense Architecture Framework (US)
• MoDAF—Military of Defense Architecture Framework (UK)
• FEAF—Federal Enterprise Architecture Framework
None of the frameworks provide an architecting methodology; however, the DoDAF does provide
some high level architecting guidance. Figure 17.8 represents that guidance, and is provided as one ap-
proach to a methodology.
During this phase, the system requirements are allocated to each of the major parts of the system of
interest, to be assigned to domain engineers to perform final design and fabrication.
Finally, in the world of reuse, agility and service based architecture, the architecture design process
must result in an architecture that can be changed, updated, extended, and be resilient to threats of any
kind such as threats from competing products, economic threat, or even hostile threat.

17.5 Implementation
This phase is where the system of interest and its constituent parts are designed and built. As mentioned
in the previous phase, once the architecture is specified and the system requirements are allocated in
the architecture design phase, domain engineers gather up the allocated requirements and are treated as
system requirements for the specific major part of the system being addressed. Thinking of this iteratively,
the specific major part of the system being addressed becomes the system of interest, and on to the lowest
level components.
While the domain engineers in this phase will certainly be systems engineers for larger systems, they
will also involve software engineers, electrical engineers, mechanical engineers, and etc. Also brought into
this phase will be specialty engineers in the fields such as reliability, maintainability, human factors, etc.
to help ensure the system of interest not only meets the stakeholders requirements, but also ensures that
the system can be produced in the most cost effective manner. These teams that are made up of multi-
disciplinary people to achieve this phase are called Integrated Product Teams (IPT). The IPT must work
together to create their piece of the system while using the requirements and architecture of the system set
forth prior to this phase.
274
 Systems Engineering

Figure 17.8. DoDAF Architecting Guidance

1
Determine the
intended use of
the architecture

Purpose
Target objectives
Key tradeoffs
Probable analysis methods

Use as Use as Use as Use as Use as

input to input to input to input to input to

2 4 5 6
3 Determine the
Determine the Determine the Build the Use architecture
architecture characteristics views and requisite
to be for intended
scope products to be products purpose
captured built
Then Then Then Then

Producing Producing Producing Producing Producing

Geographical/ Required All essential Completed ∙ Prudent investments

operational bounds characteristics products architecture ∙ Improved business
Timephase(s) (commensurate Relevant supporting (populated processes
Functional bounds detail across the products product set) ∙ Increased interoperability
Technology constraints different views)
Architecture and measures of
resources/schedule performance
Used to access

During the early stages of implementation, larger systems are decomposed into smaller subsystems.
Each subsystem will have a set of specifications and an IPT assigned to it. Therefore, the IPT not only has
to work together among their team but they must also work with other IPTs that their subsystem interfac-
es with so that the interfaces are created properly. This communication between IPTs is imperative to the
success of a project and will be discussed more in the integration phase.
During the implementation phase development of training material for the users and maintainers of
the system of interest should be created. This material can include instruction manuals, drawings, simula-
tions, or any other type of media that may be required to convey to the users and maintainers the infor-
mation they require to perform their functions.

17.5.1 Intermediate Specifications

Each subsystem will have its own set of specifications. These specifications include requirements specification,
design specification, and interface specifications for the specific subsystem. These specifications must adhere to
the higher-level system specifications and work within the system architecture that was defined. These subsys-
tem specifications must go through the same development and change management rigor as system specifica-
tions. The subsystem specifications can be viewed as a set of system specifications within a system.

17.5.2 Peer Reviews

Peer reviews should be conducted on all project artifacts (specifications, design drawings, and etc.). These
peer reviews can be informal or formal. The key to good peer reviews are: (1) allowing ample time to review
the material, (2) inviting all the right people review the material, (3) make sure the material for review is
mature enough for the review type, (4) supporting information/data is provided with the review material,
(5) reviewers supply constructive/technical feedback, and (6) feedback is captured. Peer reviews should not
be rushed and should be taken seriously. The feedback from the peer review should be given appropriate
attention and any concerns addressed. A peer review is one of the most important tasks on a project that an
individual can be involved in. The peer reviews can catch interface issues, requirement conflicts, technology
misconceptions, and many other important issues that can save the project both time and money.
275
Engineering Management Handbook

17.5.3 Quality Inspections

Quality inspections should be conducted on the project at all levels and as set forth by the quality control
plan of the project. The quality inspections are intended to guarantee that the project artifacts being used
throughout the project have been sent through the appropriate procedures and the correct sign off of the
artifacts have been made. Quality inspections also ensure that changes to artifacts are done according to
set procedures from the project and can help ensure that communication of changes have been made to
the correct person(s). These quality inspections are not technical inspections but are used to check that the
practices and procedures set forth by the project or company are being carried out. The ultimate goal of
quality inspections is to guarantee and maintain the integrity of the project artifacts.

17.6 Integration
The purpose of the integration phase is to bring all the pieces or elements of the system of interest to-
gether to assemble into a whole. This purpose is accomplished by taking each piece and building up the
system. The order in which systems pieces are integrated into the systems should be carefully planned
out and considerations such as schedule and interfaces should be made. The warning at this phase is to
not put all or too many elements together at one time. The integration plan should include a bottom-up
approach where the elements are added from a hierarchal point of view and the interfaces checked for
compatibility before adding additional elements. During this phase overlap with the Verification and
Validation Phases may take place.
The IPT should still be involved in the integration phase and understand the order in which elements
will be integrated. This coordination between IPTs is needed so that elements are available when needed
and to ensure compatibility of the elements. On many programs the coordination for integration will be
a well-choreographed dance, where items not only have to be completed on time to integrate with one
another but their integration must be completed to integrate with another element or subsystem of the
system. Sommerville (1998) said this about the integration phase:
“Integration is one of the most costly and time-consuming activities in the systems engineer-
ing process. For large and complex systems, up to 40% of the development effort may be
used in this activity, mostly in system testing.”

To achieve system integration there are two approaches: (1) big bang approach and (2) bottom-up
approach. Both will be discussed in the following section although as mentioned before the preferred
approach is the bottom-up approach.

17.6.1 Big Bang Approach

The big bang approach (Figure 17.9) takes all the subsystem of the system of interest and integrates them at
one time. The subsystems are individually tested prior to integration but are all brought together at one time
to be integrated. This method is high risk because any issue that is found can be hard to isolate and resolve.

Figure 17.9. Big Bang Approach to Integration

Integrate

Subsystem 1...n
System

276
 Systems Engineering

17.6.2 Bottom-Up Approach

The bottom-up approach (Figure 17.10) takes the lowest level elements and integrates them in verifi-
able increments. The process works its way from the lowest level elements of the system to the top-level
subsystems. One positive aspect about this approach is that lower-level elements can usually be integrated
early in the program. This approach, compared to the big bang, also reduces risk by introducing a limited
number of unknown variables at one time.

Figure 17.10. Bottom-Up Approach to Integration

System

INTEGRATED SUBSYSTEMS

Subsystem 1 Subsystem 2 Subsystem 3...n

Component
Component Component Component Component 5...(n-1) Component
1 2 3 4 n
1 2

17.7 Verification
The purpose of the verification phase is to confirm that the system of interest meets the system require-
ments or another way to state the purpose is that the system is built right. In this phase each element of
the system is verified that it meets the requirements that came out of the requirements analysis phase. The
verification method for each requirement should begin to form during the requirements analysis phase.
It is important to identify how each requirement will be verified early so that any verification equipment
or simulations that need to be built will be available in time for the verification phase. It is also important
that stakeholders (both internal and external) agree to the verification strategy of the requirements.
Verification plans should be generated and reviewed as early as possible. These plans detail the verifi-
cation procedure and the setup. The verification plans should be reviewed by stakeholders of the require-
ment being verified. Having the stakeholders of the requirement agree to the verification plan helps ensure
the requirement is being understood consistently between stakeholders and designers. It helps to ensure
that the stakeholders are satisfied with the level of verification a requirement will have.
There are different methods used to verify a system requirement. The four most recognized are in-
spection, demonstration, analysis, and test. The cost of the verification method is important to take into
account as each verification method may vary greatly in cost but achieve the same goal.

17.7.1 Inspection
The inspection method uses examination and observation to determine if a requirement is met. An
example of this is if a requirement states: “There shall be two USB ports on the front panel.” This can be
verified through a visual examination of the front panel that there are two USB ports. This requirement
does not ask for functionality of the ports just that they are available on the front panel so a visual inspec-
tion is sufficient.

277
Engineering Management Handbook

17.7.2 Demonstration
The demonstration method shows the operation of functional performance. This can be in a live or sim-
ulated environment. An example of this would be “The system shall average at least 50 mph.” The system
would be observed over a period of time that it averaged 50 mph. During the demonstration, one observ-
able must be that the system averages 50 mph over a specific period of time and distance.

17.7.3 Analysis
The analysis method uses simulations, algorithms, or other scientific methods to prove that the system or
system element meets a requirement. This method can be expensive and time consuming. Data may still
be required from the system of interest and the method of collecting that would need to be determined.
The algorithm or other scientific method may also have to be justified in that it is proving the require-
ment to a satisfactory level.

17.7.4 Test
The test method uses real or simulated stimuli to verify a requirement. Test should be quantitative so that
results (i.e., pass/fail) are easy to determine. An example of a test would be “The output voltage shall be
at least 5V.” Here, the system conditions, documented in the verfication plan, would be applied and the
output voltage would be measured to ensure that the voltage was at least 5V.

17.8 Transition
The purpose of the transition phase is to take the verified system and place it into the operational environ-
ment. In this phase, the system is handed from the development team to the final operator. This phase can
be short but it is an important phase to plan for. The planning should consider all deliverables, logistics,
and support of delivering the system to the user. The idea behind this phase is make sure the product
can be successfully implemented into its final environment. This includes making sure that the users are
trained so that they can operate the system and that maintenance is able to be performed by the user. As
stated in the implementation phase the training material should have been developed during that phase.
The users and maintainers would require the training material prior to the transition phase so that they
have time to prepare for the arrival of the system. Some training could even be part of the transition phase
depending on the intensity and time constraints.

17.9 Validation
The purpose of the validation phase is to guarantee the system meets the stakeholder requirements or in
other terms was the right system built. In this phase, the system is exercised through all its operational modes
and/or scenarios. As in the verification phase the validation phase must be planned for well in advance. The
logistics, training, special equipment, etc., that are needed for validation should be identified as early as pos-
sible. Validation plans should also be developed early and agreed upon by the stakeholders so that everyone
is aware of the approach and level of validation that will be taken. The reason for early validation plans is to
ensure the final validation sign off of a system by stakeholders once the validation phase is complete.

17.10 Operation and Maintenance

The purpose of operation and maintenance phase is to place the system into its intended service and
to sustain the system through its life. During this phase the operation and maintenance of the system
should be monitored to determine if any corrective actions need to taken so that the system continues
to function as designed. This phase also includes any enhancements to the product that may be required
to sustain its life. Along with the corrective actions and enhancements support must be given to perform
these actions and guarantee their successful outcome.
The operation and maintenance of the system should begin during the requirement analysis phase.
Operation is usually not forgotten during the requirements analysis phase in fact it usually is the focus but
278
 Systems Engineering

maintenance is many times overlooked. The designer must remember to make sure the ability to effective-
ly maintain the system is designed into the system. This can be ensuring that certain panels on the prod-
uct are accessible and can be removed. Items that may need to be changed often such has batteries should
also be accessible. If a product requires software updates then how those updates are made to the product
(USB port, internet connection, RS-232, etc.) must be taken into consideration during the requirements
analysis phase. The thought process for maintenance also needs to take into consideration the type of
tools that the maintainer will have available. If the product requires a special tool then that tool should be
designed and offered with the product.
An example of operation and maintenance phase that anyone using a Microsoft Windows® operat-
ing system would be familiar with is the Windows® updates. These updates help enhance the product,
correct issues found after release of the product, and helps maintain the life of the product. Many times
these updates are required by the end customer or the product life would be ended. One example of this
required update is any security features with the Windows® product. One can imagine how dissatisfied the
customers of Windows would be if these imperative security updates were needed but did not take place.
Therefore, it shows that the operation and maintenance phase cannot be taken lightly by the developer of
the system. The developer needs to stay engaged with the product and guarantee that its intended life is
achieved.

17.11 Disposal
The purpose of the disposal phase is to terminate the system and the deal with any waste disposal issues;
such as hazardous waste. This phase is to ensure that the system is disassembled and disposed of properly.
Any hazardous substances in the product should be identified and disposed of according to local laws
and regulations. The disposal phase should be considered in the requirements analysis phase. The type
of considerations that should be made are as follows: (1) How will the system be disposed of (landfill,
recycle, etc.)? (2) If there is hazardous waste who will dispose of it and how? (3) What is the environmen-
tal impact regarding the disposal of this system? And (4) how much will it cost to dispose of the system?
These are just a few considerations but are ones that are many times not addressed during the require-
ments phase. The cost of disposal also plays into the overall Life Cycle Cost and therefore the success of
the product.
A current example of a disposal issue is the new Compact Florescent Light (CFL) bulbs that many
people are using to replace all their incandescent light bulbs. With this increase in use of CFL bulbs,
which contain small levels of mercury, a concern was raised that disposal of all those CFL bulbs in land-
fills will containment the ground water. To address this concern manufactures and stores offer free recy-
cling of the CFL bulbs. These stores and manufactures understand that environmentally friendly disposal
of the CFL bulbs is important to the consumers and they also know it will keep agencies like the EPA
from mandating special disposal requirements that could impact the selling of their CFLs. Would anyone
want to buy such a common product if they could not easily dispose of it?

17.12 Conclusions
Hopefully by now, it is clear that SE is about managing the development of a system. ISO/IEC 15288
defines a number of processes that should be followed during a system lifecycle, and SE is about exer-
cising and executing those processes. That is not to say that systems engineers perform each of those
tasks, but they are responsible to ensure the processes are performed, and that the necessary system level
documentation is created as part of the input to the next process. Because the field of SE is so broad,
specialization has occurred within the field. For instance, there are systems engineers who have become
experts in eliciting, writing, and managing requirements. Others have become systems architects, and
are highly proficient in understanding requirements and taking an abstract view of the system to envi-
sion structure of the major parts of the system. Still others have specialized in integrating and testing
the system as the components parts are brought together and the overall system takes shape. However,
even with these specializations, it is important for a systems engineer to understand their role in the
overall SE process; understanding how their role in the process affects the remaining processes. While
279
Engineering Management Handbook

the intent of this chapter was not to make the reader a systems engineer, one should now have enough
information to learn more about the SE process.

17.13 References
System Architecture
Grady Booch, The Complexity of Programming Models, IBM Rational Users Conference, 2005.
Cloutier, Robert, Fickle, Clay, Watson, John, and Winkler, Andrew, “Modeling a System of Systems
Using UML,” Conference on Systems Engineering Research (CSER), Hoboken, NJ: Stevens Institute
of Technology, 2003.
Rechtin, Eberhardt, Systems Architecting, Creating & Building Complex Systems, Upper Saddle River, NJ:
Prentice-Hall PTR, 1991.
Sommerville, Ian, Accessed from http://www.comp.lancs.ac.uk/computing/resources/IanS/SE5/syseng/
sise/integration.ppt#4, 1998.

Patterns in Systems Engineering

Cloutier, Robert, and Verma, Dinesh, “Applying the Concept of Patterns to Systems Architecture,” Sys-
tems Engineering, vol. 10, no. 2, 2007, pp. 138-154.

Quality Function Deployment

Guinta, Lawrence, and Praizler, Nancy, The QFD Book, The Team Approach to Solving Problems and Satis-
fying Customers Through Quality Function Deployment, New York: American Management Association,
1993.
King, Bob, Better Designs in Half the Time, 3rd Edition, Methuen, MA: Goal/QPC, 1989.

Requirements Generation and Management

Industry Week, Nov. 1, vol. 242, no. 21, 1993.
Wasson, Charles, System Analysis, Design, and Development, Wiley-InterScience, Hoboken, NJ: John Wil-
ey & Sons, 2006, chapters 21, 22, pp. 28-33.

Systems Engineering
Cloutier, R., Baldwin, C., and Bone, M. Systems Engineering Simplified. Boca Raton, FL: CRC Press,
Taylor & Francis Group, 2015.
Hall, A.D., A Methodology for Systems Engineering, Van Nostrand, 1962, p. 139.
Systems Engineering Handbook, Version 3.1, Technical Board, International Council of Systems Engineer-
ing (INCOSE), 2004, Document Number: INCOSE-TP-2003-016-02.
Systems Engineering Handbook, Version 3.2.2, Technical Board, International Council of Systems Engin-
eering (INCOSE), 2011, Document Number: INCOSE-TP-2003-016-02.
Wasson, Charles, System Analysis, Design, and Development, Hoboken, NJ: Wiley-InterScience, John Wil-
ey & Sons, 2006.
ISO/IEC 15288 Systems Engineering – System Life Cycle Processes, First Edition, 2002-11-1.

System Modeling using SysML

Object Management Group (OMG) website, http://www.sysml.org, last accessed 09/01/2008.
SysML Specification, http://www.sysml.org/docs/specs/OMGSysML-v1.0-07-09-01.pdf, last accessed
9/1/2008.

280
 Systems Thinking

18
Systems Thinking

Charles Keating
National Centers for System of Systems Engineering, Old Dominion University

Behnido Calida
Virginia Tech Transportation Institute

Ra’ed Jaradat
Mississippi State University

Polinpapilinho Katina
National Centers for System of Systems Engineering, Old Dominion University

281
Engineering Management Handbook

18.1 Introduction
The landscape for the engineering manager of the 21st century has changed drastically in the decades since
the inception of the discipline of Engineering Management (EM). The American Society for Engineering
Management was founded in 1979 and defines engineering management as “the art and science of plan-
ning, organizing, allocating resources, and directing and controlling activities which have a technological
component.” In the ensuing three decades since the establishment of a formal society to foster the disci-
pline, the discipline of engineering management and the environment that engineering managers must
operate in has evolved significantly.
Although today’s engineering managers must still accomplish the same set of activities mentioned
above, they are faced with a very different set of circumstances than those encountered by their prede-
cessors three decades ago. The current engineering management environment requires a constant strug-
gle with: (1) proliferation of information intensive systems and technologies, (2) multiple stakeholders
with potentially divergent viewpoints and politically driven agendas, (2) scarce and dynamically shifting
resources available for mission support, (3) constantly shifting requirements and context for execution,
(4) technology advancements that outpace the capabilities, and potential compatibility, of infrastructures
necessary to support their development, (5) urgency for immediate and responsive reconfiguration to deal
with shifts in operating assumptions, (6) surrender of long-term perspectives to deal with emerging cri-
ses—rendering traditional forms of planning virtually innocuous, (7) increasing complexities and uncer-
tainties that are a rule rather than exception, and (8) emergent circumstances and factors that make stable
planning and operations tenuous at best. These characteristics are not likely to subside in the near future
and are more likely to escalate in severity. The success of future generations of engineering managers will
be directly tied to their ability to effectively deal with this new world.
In short, the world of the engineering manager is a “complex systems world”—an increasingly am-
biguous, complex, emergent world of interdependent systems fraught with instability and uncertainty
(Keating and Katina, 2011, 2012, 2015). There is a need to arm future engineering managers with the
mindset, capabilities, and skills that will increase the probability of success in managing future technolo-
gy-based enterprises.
Systems thinking can provide a valuable capability for engineering managers to more effectively deal
with the complex problem domains described above. Although systems thinking is not the “silver bullet”
or “magic solution,” it can add to the arsenal of the engineering manager as he or she struggles to effec-
tively cope with the new realities of the technical enterprise.
The purpose of this chapter is to acquaint EM practitioners with the essential knowledge necessary to
use systems thinking to more effectively deal with increasingly complex systems and their problems. In
general, systems thinking has been captured by Haines (1998, p. vi) as “A new way to view and mentally
frame what we see in the world; a worldview and way of thinking whereby we see the entity or unit first
as a whole, with its fit and relationship to its environment as primary concerns; the parts secondary.” Our
treatment of systems thinking will expand on this perspective to accomplish three primary objectives:
1. Establish the role and unique contribution systems thinking can provide to enhance performance of
EM practitioners.
2. Provide a set of foundation systems principles to guide engineering managers in more effective think-
ing, decision, action, and interpretations for better understanding and dealing with complex problem
domains.
3. Examine some common methodologies and tools that can help engineering managers in the applica-
tion of systems thinking to increase professional effectiveness.

To achieve our objectives, we have organized the chapter to present a rigorous development of
systems thinking for engineering managers. First, our introduction provides a systems-based perspective
for the EM domain, the systems challenges, and specific role that systems thinking can play to enhance
EM capability. Second, we provide an overview of systems thinking to establish the essential background
that engineering managers should be aware for application of systems thinking. Our focus here is to set
the challenges and specific responsive role that systems thinking can play in addressing those challeng-
282
 Systems Thinking

es. We develop a perspective as well as the nature of systems thinking. Finally, the remaining sections of
the chapter will present the underlying philosophical (informing worldview, based in fundamental values
and beliefs that guides decision, action, and interpretation), methodological basis (general frameworks
that guide deployment), and application (methods, tools, and techniques to enhance practice) related to
systems thinking. We close the chapter with a recognition of the limitations, role, and implications that
systems thinking holds for engineering managers.

18.1.1 Changing Domain for Engineering Managers

The problem domain currently faced by engineering managers has become more difficult to effectively
navigate. While the debate may ensue as to the source of the increased difficulty, the state of the current
condition is much less questioned. We offer several characteristics of the current environment being faced
by engineering managers:
1. Hyperturbulent conditions—The environment for the effort is highly dynamic, uncertain, and
rapidly changing. This flux places traditional forms of thinking and problem solution framing in
question. Stable platforms for managing are relegated to the past. A new era of technical management
is upon us—requiring the trade of precision and metered approaches for agility and resiliency.
2. Ill-defined problem conditions—The circumstances and conditions surrounding the problem are
potentially in dispute, not readily accessible, or lack sufficient consensus for initial problem formulation
and bounding. The result is a questionable ability of traditional approaches to be successful. There may
be multiple (possibly divergent) perspectives/worldviews, rapidly shifting and emergent conditions that
render stable planning/action platforms innocuous, and difficulty in framing the problem domain such
that the “path forward” can be engaged with sufficient alignment of perspectives to remain viable.
3. Contextual dominance—The technical “hard” aspects of a problem are overshadowed by the con-
textual “soft” aspects. Contextual (soft) aspects are those circumstances, factors, conditions, trends, or
patterns that influence the framing of the problem, solution development form, solution deployment,
and interpretation of deployment results. This context exists beyond the technical/technology aspects
of the problem domain. The range of contextual elements spans organizational/managerial, human/
social, and policy/political dimensions of problems and their interrelationship. As such, for highly
volatile problem domains, context can play a more significant role than the technical aspects necessary
for a ‘total’ system solution.
4. Uncertain approach—The path of progression on how “best” to proceed with the effort is indeter-
minate. Standard processes which have been successfully applied in the past are no longer assured of
success. For the ill-defined problems inherent to this domain, successful approaches of the past may
likely fail to meet the same level of effectiveness. Agreement on the nature of the problem (framing),
appropriate approach, and expectations for “successful” resolution are potential sources of divergence
in the complex problem domain.
5. Ambiguous expectations and objectives—The ability to establish measures of success, system ob-
jectives, or requirements is questionable. This may be a result of inadequate understanding, hidden
motives, or lack of technical competence to proceed with the effort. This is not likely to be remedied
by “doing a better job.” The problem domain may be so confounding that clarity is not possible and
attempts at “nailing down the problem” may be artificial at best. Instead, the problem landscape may
simply be too complex and emergent to falsely assume that sufficient knowledge can be generated at
the present point in time to adequately address the solution space.
6. Excessive complexity—For our present purposes we present complexity as a situation that is highly
dynamic, uncertain, emergent, and containing a high number of richly interconnected elements/
factors. The boundaries of the system of interest may be such that completeness of understanding
is beyond capabilities of traditional approaches to capture. To proceed using traditional approaches
would require significant reduction, assumptions, and potential oversimplification of the problem
domain—a recipe for failure to meet expectations for resolution of complex problems. This does not
demean traditional approaches, but rather points to their limitations in application to incompatible
complex problem domains.
283
Engineering Management Handbook

7. Pluralistic perspectives—The range of variability of individual perspectives, objectives, and perceived

interests may be so divergent that sufficient alignment necessary to move forward may be unattain-
able. Many traditional approaches assume a “unitary” perspective where there is assumed agreement
on the problem domain that alignment is also assumed. However, complex problem domains may
have deep rooted (philosophical) divergence among stakeholders. This divergence may involve such
issues as allocation of scarce resources, power distribution, control, personal preferences/interests,
and other areas that may exist at a tacit and perhaps “undiscussable” level. Assuming alignment of
individuals participating in complex problem domains may be naïve at best.
8. Extended stakeholders—Stakeholders are generally taken as customers, clients, suppliers, employ-
ees, team members, etc. However, in complex problem domains there are two issues with “the usual”
stakeholders. First, traditional lists of stakeholders are likely to be incomplete. Stakeholders must
be considered to be those individuals or entities that have an interest or a “perceived” interest in the
problem resolution. This forces the casting of the stakeholder net much wider. Second, the range of
stakeholders may likely emerge as the problem domain is explored.
9. Emergence—The structure, patterns, behaviors in the problem domain will only come to be know
in the future—as time passes and our knowledge of the domain increases. This is not an indication
of inappropriate methods of analysis or lack of expertise. On the contrary, with complex problem
domains our knowledge will always be incomplete and fallible. This renders traditional cause-effect
and predictive approaches innocuous.
10. Ambiguous boundaries—Boundaries in this domain are problematic in three ways. First, the inclu-
sion/exclusion boundary criteria are arbitrary and necessarily qualitative in nature. This implies they
are also ambiguous by nature. Second, the nature of boundaries, and the organizing boundary para-
digms (particular ways of thinking), can take many forms (e.g., geography, time, conceptual, func-
tional, physical)—these forms may be explicit, but are as likely to exist at a tacit level. None of these
organizing paradigms are correct or incorrect, but they are certainly problematic, particularly if they
are divergent. Third, complex problem domain boundaries are not static—they may, and probably
should, change over time with increased understanding of the domain.
11. Unstable planning foundations—With environment fluctuations and uncertainty of resources, re-
quirements and problem situations are subject to sudden, and potentially radical, shifts. For instance,
there may be continual shifts in scarce resources, policy, directives, initiatives, and scenarios that make
addressing the situation difficult. This may make traditional forms of planning and execution inade-
quate for these problem domains. Rather than development of planned “optimal” solutions, the like-
lihood leans more toward “satisficing solutions,” capable of rapid reconfiguration based on unforeseen
shifts and emerging circumstances.
12. Information saturation—The proliferation of data and information has risen exponentially. This has
left engineering managers in a quandary. Development of effective approaches to scan, filter, reduce,
and process information into actionable forms are not yet sufficient. Instead, engineering managers
must wade through a morass of information seeking to identify the “bits” that are essential to drive
decision and action.
13. Identity coherence—Identity is the set of fundamental values, patterns, and attributes that provides
a consistent reference point and baseline logic for making grounded decisions, taking consistent
actions, and providing self-reinforcing interpretation of abstract events. Modern technical enterprises
are confronted with an accelerating pace, blurring ethical/value systems, and complexity. Incoherent
or ambiguous identity deepens the inability to achieve consistency in the face of the “new realities”
facing engineering managers of technical organizations.
14. Generational shifts—There is a generational shift in the workforce underway. This shift, predicat-
ed by the inevitable coming dominance of the millennial generation, introduces additional strains
in an already complex problem domain. This problem domain will necessarily be confronted across
generational divides. Generational differences are an important consideration in addressing complex
problem domains.
15. Non-ergodicity—The problem domain for engineering managers is also characterized by conditions
of having no clearly defined states or discernible transitions between system states (Souza-Poza et al.,
284
 Systems Thinking

2008). The operating landscape for today’s engineering managers includes elements of non-ergodicity,
where systems are subject to inherent difficulties in understanding and provoking continuous transi-
tion to identified goals is tenuous.
16. Non-monotonicity—The reality for engineering managers is such that increases in knowledge are not
reciprocated by increases in understanding. Actions and decisions are always tentative (Sousa-Poza et
al., 2008). This suggests that engineering managers have to realize that knowledge is necessarily provi-
sional, incomplete, and fallible.

The attributes above suggest that the problem domain faced by engineering managers is a signifi-
cant departure from that faced in the past. Unfortunately, the struggle continues as our current arsenal is
insufficient to adequately arm engineering managers to most effectively perform in this emerging domain.
Although there are emerging technologies and methods to assist engineering managers, they are lagging
the shifts in the problem domain. However, irrespective of technologies and tools/methods, engineering
managers armed with sound philosophy and principles that ground their thinking will increase effec-
tiveness in these environments. Systems thinking represents such a philosophical and principled way of
dealing with new complexities being faced by engineering managers.
New tools, methods, and technologies will continue to be developed to assist engineering managers.
Although they may be useful, none will have the prolonged continuity provided by thinking that is philo-
sophically grounded and principle driven. This is the challenge faced by engineering managers: To develop
a sound philosophy, principles, and values that inform consistent decision, action, and interpretation in the face
of increasing complexity. Systems thinking offers a significant path forward to meet this challenge.

18.1.2 Systems Thinking Challenges for Engineering Managers

The present systems challenges for engineering managers lie in the changing nature and circumstances of
the types of problems that must be addressed. Past successes with approaches to this new problem domain
will not assure similar success in turbulent environments of the future. In the future, engineering man-
agers will be challenged to develop resilient system (de Weck, Roos, and Magee, 2011) solutions to what
Ackoff (1981, 1999) has termed “messes” (interrelated systems of problems), or Rittel and Webber (1973)
have previously identified as “wicked problems.” We point out three primary systems challenges for engi-
neering managers who must confront this domain:
• Systemic framing of complex problem domains
• Establishing a “holistic” perspective and approach to complex problems
• Dealing with complexity through full spectrum systems thinking.

In the remainder of this section we will briefly develop each of these challenges and their implications.
Systemic framing involves taking into account the holistic nature of a complex systems problem. This
holistic perspective involves not only the technological dimensions, but also the human/social, organi-
zational/managerial, and political/policy dimensions. Systems thinking assists engineering managers in
this holistic understanding of the problem domain and is an essential skill set for increased effectiveness.
Complex system problem framing offers a “front-end” toward increased effectiveness in dealing with
increasingly complex systems. There are four important aspects of framing that we have singled out with
respect to systems thinking as an enabling capability for engineering managers: (1) skills in systems think-
ing provide a way of thinking and organizing complex systems problems—informed by a philosophy and
guiding principles that are grounded in systems theory, (2) framing is likely to be the initial phase of any
effort to deal with complex system problems—performing this activity from a “systemic” perspective will
serve to enhance the capabilities for future engineering managers, and (3) systemic framing involves a way
of thinking—with reliance on the foundational systems philosophy and principles that inform a more
sophisticated perspective of the problem domain.
The concept of holism lies at the heart of systems thinking. Holism suggests that understanding of
a complex system/situation requires that understanding must be at the level of the whole system. Simply
285
Engineering Management Handbook

breaking the system into constituent “parts” does not provide an adequate understanding of how the
system functions as a whole. There are behavioral, structural, and performance characteristics of a systems
that are simply not capable of being ascertained at a level lower than that of the system. In effect, there is a
point where a system is “irreducible” and understanding cannot be attained below the level of the whole.
Capability for dealing with the age of complexity faced by present and future engineering managers
can be enhanced by full spectrum systems thinking. We introduce the modifier of “full spectrum” to ex-
pand an overly narrow viewpoint of systems thinking. A scan of the literature for systems thinking quickly
identifies many works (Senge, 1990; Kim, 1995) that to closely associate systems thinking to the field
of system dynamics. There is no escaping the popularity of system dynamics as a field that enables—as a
tool—engagement of systems thinking. However, the notion of “full spectrum” suggests that the power of
systems thinking is not contained within a technique. Instead, we suggest that systems thinking’s power is
more effectively realized through the study of the philosophic (underlying paradigm/worldview), axiom-
atic (supporting principles), axiological (corresponding values), methodological (broad execution guiding
frameworks), methods (supporting processes, tools, and techniques), and applications (using knowledge).

18.1.3 Implications of Systems Thinking (ST) for Engineering Management

(EM)
Systems thinking provides a significant contribution to enable engineering managers to more holistically
deal with systems challenges. Senge (1990, p. 185) amplifies this point by suggesting, “…systems thinking
as a philosophical alternative to the pervasive “reductionism” in Western culture—the pursuit of simple
answers to complex issues.” Recent work in applied systems theory amplifies the point that traditional
thinking about system problems will be ineffective in the future. Mitroff (1998) suggested that because
real problems are unstructured and arbitrarily bounded, their resolution requires systemic inquiry. He
concludes that, “All serious errors of management can be traced to one fundamental flaw: solving the
wrong problem precisely, or muddled thinking” (Mitroff, 1998, p. 9).
Mitroff (1998) suggested five areas that lead to poor system problem resolution and result in a Type
III error. Following Mitroff (1998), the areas for incorrectly solving system problems include:
• Selecting the Wrong Stakeholders—Stakeholders are those that have a perceived interest in the system
problem. Failing to take into account stakeholders can render the system solution inadequate before it
is deployed.
• Too Narrow a Set of Options—By too quickly elimination possible system solution alternatives, the de-
cision space is bounded too narrowly early in the process. The result is precluding potentially effective
solutions from investigation.
• Boundaries or Scope too Narrow—The establishment of a boundary on the system that is too narrow
may give a false impression of the system of interest —resulting in pursuit of solutions to the wrong
“system” problem.
• Incorrect Phrasing of the Problem—Language and how a problem is depicted can produce a limited
framing of the problem, and hence limit the possible approaches to investigate the problem.
Failing to Engage in Systemic Thinking—Complex system problems must be holistically considered in
terms of the relationships, patterns, and boundaries to avoid artificial analysis and solutions.

We feel that Mitroff’s (1998) issues provide an effective starting point for issues in complex system
problem framing. To this initial listing we would add three additional issues:
• Misalignment of Conceptual Perspective—Those constituents involved in the complex system problem
framing must have sufficient overlap in their perspective of problem definition, plausible approaches,
and frame for interpretation of system solution. This includes background, experiences, and “world-
view.” This also supports consistency in decision, actions, and interpretations necessary to engage the
problem domain.
• Expertise in Problem System and Approach—Closeness to the problem system may preclude diversity of
perspectives that may be essential to a wider view of the problem system. In addition, the approach to
resolution of the problem might require expertise or experience that is beyond the grasps of the unit
286
 Systems Thinking

investigating the problem. Successfully addressing systems problems requires that engineering man-
agers invoke both system (source of problems emanating from a specific system) and systems (field of
systems knowledge) expertise to address the problem—both levels of expertise are required.
• Contextual Capacity for Reframing—It is possible that a problem system, once reframed will not
resemble the “original” problem. If the resources, managerial support, and problem solving culture are
not consistent with reframing, it is doubtful that reframing will meet with success.

18.2 Overview of Systems Thinking

Systems thinking can provide a valuable capability for engineering managers to more effectively deal with
complex problems. In this section we develop the foundations for systems thinking.

18.2.1 Nature of Systems Thinking

Systems thinking is not something new, and it is certainly not the “silver bullet” or universal solution
that is constantly being sought for dealing with the complex problem domains described above. On the
contrary, system thinking has been around in forms dating to the time of Aristotle, suggesting that in the
whole we find something not found in the parts. This was the very foundation for the primary tenet of
systems thinking, holism. Granted, there have been advances in how we think about systems. However, for
clarity, we must acknowledge the long lineage upon which systems thinking has been built. This lineage of
systems thinking is instructive in helping to explain and understand why there will never be a “universal”
solution to the issues that complexity brings to human endeavors. Table 18.1 lists a representative perspec-
tives that demonstrates a variety of viewpoints for systems thinking. This is not to suggest the superiority
of one perspective over another. Instead, this provides the breadth of thinking about systems thinking.
There is no universally accepted definition, or perspective, of systems thinking. In fact, Lane and Jack-
son (1995) were early to point out the variety of perspectives in the systems movement and the strength
that this diversity of the field offers. We can suggest that the field continues to evolve and add to diversity
of perspectives. However, we can identify several common themes that permeate the multitude of per-
spectives. Among these themes that form the common threads in perspectives of systems thinking are:
(1) way of thinking—a distinctly different way of viewing relationships within the whole, (2) holism versus
reductionism—focus on understanding the whole (holism) that exhibits behavior stemming from part
relationships instead of focus on understanding cumulative behavior in terms of the parts (reductionism),
(3) interrelationships—consideration of the importance of the relationship between parts, (4) patterns—
understanding the particular structure of relationships, and (5) context/environment—an appreciation
that a system exist within an environment and has a particular associated context. These common threads
provide an important common grounding for systems thinking.
The systems thinking literature has spanned a vast array of domains, including organizational, biolog-
ical, managerial, economic, and social (Ackoff, 1981; Bertalanffy, 1968; Checkland, 1981, 1989; Chen
and Stroup, 1993; Cleland and King, 1972; Hoefler and Mar, 1992; Graczyk, 1993; Katz and Kahn,
1978; Kim, 1995; Klir, 1985; O’Connor and McDermont, 1997; Richmond, 2000; Senge, 1990; Senge
et al., 1994; Waring, 1996; Boardman and Sauser, 2008). In each instance, systems thinking has been
instrumental in coming to new understanding and creating the conditions for alternative decision, action,
and interpretation.
In one sense, systems thinking is only the precursor to formulating a response to a complex system
problem. However, if the (systems) thinking is not in correspondence to the problem domain, it is doubt-
ful that decision, action, and interpretation will provide the desired relief. This is similar to learning cycles
that constantly reframe and readjust to differentials in expected results (e.g., Argyris and Schön, 1978,
1996). Figure 18.1 suggests this interrelationship.

287
Engineering Management Handbook

Table 18.1. Multiple Perspectives of Systems Thinking

Author Perspective

Flood and Carson (1993, “A framework of thought that helps us to deal with complex things in a holistic way.”
p. 4)
Checkland (1999, p. 4, p. 318) “Makes conscious use of the particular concept of wholeness captured in the word
‘system’, to order our thoughts.”

Gharajedaghi (1999, p. 15)
O’Connor and McDermott
(1997, p. 1)
Haines (1998, p. vi)
Senge (1990, p. 89)
Capra (1996, p. 29)
von Bertalanffy (1972, p. 410)
http://www.opbf.org/open-
plant-breeding/glossary/so-sz
Richmond (1993, p. 139)
ESD Symposium Committee
(ESD 2002, p. 8)
Davidz (2006, p. 44)
Ackoff (2010, p.6)
“An epistemology which, when applied to human activity is based upon the four basic
ideas: emergence, hierarchy, communication, and control as characteristics of systems.
When applied to natural or designed systems the crucial characteristic is the emergent
properties of the whole.”
“Puts the system in the context of the larger environment of which it is a part and
studies the role it plays in the larger whole.”
“Seeing beyond what appear to be isolated in independent incidents to deeper
patterns.”
“A new way to view and mentally frame what we see in the world; a worldview and
way of thinking whereby we see the entity or unit first as a whole, with its fit and
relationship to its environment as primary concerns; the parts secondary.”
“A discipline for seeing wholes. It is a framework for seeing interrelationships rather
than things, for seeing patterns of change rather than static “snapshots.”
“Encompasses a large and fairly amorphous body of methods, tools, and principles,
all oriented to looking at the interrelatedness of forces, and seeing them as part of a
common process” (Senge et al, 1994, p. 89).
“A new way of thinking … in terms of connectedness, relationships, context.”
“Since the fundamental character of the living thing is its organization, the customary
investigation of the single parts and processes cannot provide a complete explanation
of the vital phenomena. This investigation gives us no information about the
coordination or parts and processes.”
“A system cannot be understood by an analysis of its parts. Systems thinking concerns
the organisation of those parts, as a single system, and the emergent properties that
emanate from that organisation.”
“The art and science of making reliable inferences about behavior by developing an
increasingly deep understanding of underlying structure.”
“Includes holism, an ability to think about the system as a whole; focus, an ability to
address the important system level issues; emergence (see below), recognition that
there are latent properties in systems; and trade-offs, judgment and balance, which
enable one to juggle all the various considerations and make a proper choice.”
“Analysis, synthesis and understanding of interconnections, interactions, and
interdependencies that are technical, social, temporal and multi-level.”
“Looks at relationships (rather than unrelated objects), connectedness, process (rather
than structure), the whole (rather than just its parts), the patterns (rather than the
contents) of a system, and context.”

18.2.2 Hard and Soft Systems Thinking

Drawing a distinction between hard and soft systems is beneficial to better understand systems thinking.
There is recognition that the hard-soft systems distinction, although fruitful for academic discussion, does
not fit nicely into silos in the world of practice (Pollack, 2006). In reality, hard and soft systems thinking
represent different points along the spectrum of systems thinking. It is not that one is right or wrong, but
rather that engineering managers understanding the nature of the problem, the context within which the
problem exists, and the appropriate forms of addressing the problem, be they hard or soft systems based.
Table 18.2 provides an overview of the critical distinctions between hard and soft systems thinking.
The construction of this table has been influenced by the work of Jackson (2003) and Waring (1996).
288
 Systems Thinking

Table 18.2. Distinctions between Hard and Soft Systems Thinking

Attribute Hard System Thinking Soft System Thinking

Understanding Reductionism—Focused on understanding Holism—A system is only understood at the

Paradigm through breaking apart (analysis). (irreducible) whole system level. The behavior
Performance of a whole can be understood cannot be at the level of the parts.
through the parts.
Objective Optimization—There is one solution Learning—The primary function of system
which is best (optimal) for system exploration is to learn about the system and be
performance. This is the solution or capable of mounting appropriate response(s)
configuration that is sought. based on that learning.
Methodology Systematic—Approach is defined by Systemic—Approach is a high level framework
defined process that can be replicated that provides a general guide—non-prescriptive.
independent of context—prescriptive.
Goal/Objectives Clearly defined and agreed upon—The Ambiguous and multiple perspectives—
moving forward is assumed to be aligned with Clarity is not assured and multiple perspectives
a singular perspective and objective. cast suspicion on the degree of alignment for
goals—which may be ill-defined.
Perspectives Unitary—Assumes that there is alignment Pluralist—There exist multiple, potentially
of perspectives for the problem domain. divergent, perspectives on the problem domain.
Context Low—Contextual influences are assumed to High—Contextual influences are seen as
be “minimized” by successive bounding of the integral to the problem and not easily separable
problem. for investigation.
Environment Stable—Disturbances in the environment Turbulent—Disturbances are potentially
are minimal and rate/depth of changes not extensive and influential in ability to develop
considered overbearing on system solution. system solution.
Systems-of-Interest Simple—Low variables, interactions capable Complex—High number of variables, rich
of being understood, somewhat static/ interactions, dynamic and uncertain (emergent)
deterministic. pattern/ behaviors.
Modeling Mathematical/quantitative—Exact Non-mathematical/qualitative—Forms
Preference relationships and predictive (mathematically) of representation non quantitative in nature.
behavior dominant. Behavior not precisely predictable.
Boundaries Clearly delineated—Boundaries are Unclear and shifting—Boundaries are
definitive and understood. ambiguous and evolving.
Worldview Aligned—Divergence in worldviews not Potentially divergent—Divergence
made explicit or considered central to considered probable, with focus on clarity of
understanding. divergence.
Defining Mechanistic—Clear understanding of Contextual—Lack of clarity in nature of
Metaphor predictable interrelationships. interrelationships.
Behavior Predictable—System behavior is deducible Emergent—System behavior cannot be known
from understanding historical patters/trends. in advance. Patters emerge through operation of
the system.

While not exhaustive, the distinctions above provide insight into the critical distinctions between
“hard” and “soft” system thinking. The primary implication for engineering managers is to appreciate
the nature of the problem/problem domain and what this means for thinking that leads to appropriate
decision, action, and interpretation in response to systems problems. In actuality, complex systems can
have attributes of soft, hard, and mixed characterization—which may shift over the life cycle of a system
or situation. Misclassification, or failure to reclassify based on new or shifting knowledge, can result in
mistreatment of a system/problem.

289
Engineering Management Handbook

18.2.3 Roles for Systems Thinking in Engineering Management

Systems thinking can be valuable to engineering managers in several ways. There are at least five primary
roles that systems thinking can play in the discipline of EM (Figure 18.1). We suggest these roles to avoid
a prescriptive viewpoint of systems thinking and not relegate a very powerful topic to a simplistic set of
notional tools or techniques. Each of five different and distinct contributions of systems thinking to engi-
neering management are expounded below.

Figure 18.1. Using the Foundations of Systems

Set of Methods Disciplined

and Techniques Structure &
Order for Inquiry

Systems
Thinking
A Language
to Guide Approach
Thinking & for Dealing
Action with
A Philosophy
or worldview Increasing
Complexity

Disciplined Structure and Order for Inquiry—The application of systems thinking can be helpful in provid-
ing approaches, grounded in underlying systems principles/concepts, to conduct more effective inquiry.
The very nature of systems thinking suggest a more structured and orderly progression for understanding
and holistic framing of complex interrelationships. This is important for engineering managers who must
develop effective understanding of complex problems.

Approach for Dealing with Complexity—Dealing with increasing complexity is perhaps the greatest future
challenge facing engineering managers. Systems thinking offers multiple approaches, based in underly-
ing systems foundations, to more effectively address complex problems. Complexity is a fact of life for
engineering managers. The approaches to deal with complexity, rooted in a differentiated systems thinking
frame of mind, can provide engineering managers increased effectiveness in increasingly complex problem
domains.

A Philosophy or Worldview—Philosophy provides the basis for making sense of what we perceive in the
world. It is the root of decision, action, and interpretation of what transpires in the engineering man-
ager’s world. Systems thinking can provide a paradigm that broadens the engineering manager’s world
view. This can increase the possible decision space, generate an expanded set of actions, and broaden the
interpretative framework for understanding. In effect, systems thinking can provide engineering managers
with increased capacity to “make sense” of their circumstances and enhance the capability to mount more
effective responses.

A Language to Guide Thinking and Action—We think through language. Therefore, new language provides
the avenue for new thinking to more effectively deal with the problem domain faced by engineering man-
agers. The language of systems thinking can be instrumental in coming to new understanding of familiar
issues. Thus, new courses of action to address complex problems can be established.
290
 Systems Thinking

Methods and Techniques—Systems thinking provides the basis for a host of implementing methods and
techniques that can enable higher levels of inquiry for engineering managers. Ultimately, language alone is
not sufficient to provide more informed approaches to deal with increasing complexity. However, meth-
ods and tools can provide enabling capacity for “doing” systems thinking.

Engineering managers must realize that systems thinking operates on many levels, including the five
levels identified above. It can provide enhanced effectiveness on any or all of these levels. It is a misnomer
to think of systems thinking as simply a set of tools to be used by engineering managers. To truly engage
the full spectrum of systems thinking capability, an engineering manager must seek the contributions
across these levels.

18.3 Philosophy and Central Concepts for Systems Thinking

The foundations for systems thinking can be found in the laws, principles, and concepts of the systems
field. This chapter cannot provide coverage of all these foundations. A detailed examination of con-
tributing laws, principles, and concepts for systems thinking can be found in several exceptional works
(Adams et al., 2014; Clemson, 1984; Hammond, 2002; Katina, 2016; Skyttner, 1996; von Bertalanffy,
1972). The systems conceptual foundations have stood the test of time through generations of managing
complexity. However, in this chapter we have chosen a set of foundation principles that we view as critical
to application of systems thinking in EM. These foundations can be influential for engineering managers
as they seek to more effectively frame complex system problems, engage in more holistically appreciation
of the nature of truly complex problems, and embracing higher levels of systemic inquiry.

18.3.1 Philosophical Basis for Systems Thinking

For engineering managers, the notion of philosophy can be somewhat off-putting. After all, engineering
disciplines are intended to solve real-world problems and have little tolerance for thinking about age old
questions that have little hope of resolution. At first glance, philosophical questions must appear some-
what distant and disconnected from the duties and responsibilities that clamor for the engineering manag-
er’s attention. However, we must explore several philosophically based issues that are important to the
understanding and deployment of systems thinking. For this development we broadly suggest that phi-
losophy is the basis for the underlying worldview that provides consistency in the frame of reference for
decision, action, and interpretation. All thinking is ultimately rooted in underlying philosophy. Therefore,
if an engineering manager is to gain the intended benefit of systems thinking, or any other topical area for
that matter, questioning of the basic underlying philosophy driving perspectives is important.
For engineering managers, philosophy is more approachable from the perspective of Checkland
(1998), who suggested the notion of worldview, or Weltanschauung. Worldview is based in the philo-
sophical underpinnings used to inform the perspective of an engineering manager and drives purposeful
decision, action, and interpretation from an internally consistent reference point. Thus, the philosophical
disposition of an engineering manager is essential to inform everything that follows. There is not a “right”
or “wrong” philosophical disposition. However, the issue for engineering managers occurs when there is a
philosophical mismatch. This mismatch has been referred to as a Type IV error (Keating, 2008). A Type
IV error exists as a philosophical divergence such that agreement is unlikely on problem frame, approach,
or interpretation of results. For conciseness to the topic of systems thinking, and following the work of
Burrell and Morgan (1979) and extensions of Flood and Carson (1996), Figure 18.2 provides a brief sum-
mary of endpoints of the philosophical spectrum for epistemology (concerned with how knowledge of a
system is gained and how that knowledge is communicated externally) and ontology (the nature of reality
from which system knowledge is derived).
From this depiction of philosophical disposition, several key points for systems thinking in EM are
suggested:
1. Worldview will be a limiting or enabling factor in deployment of systems thinking. Therefore, consid-
eration of worldview is important to increase potential for success in systems thinking based initia-
tives.
291
Engineering Management Handbook

2. Incompatibility of worldviews can render the best intentioned effort impotent. Without taking this
into consideration, engineering managers are risking the potential for doing more harm than good in
addressing complex problems.
3. Worldviews underlie all decisions, actions, and interpretations engaged in an enterprise. They may
be tacit, not discussable, or assumed, but they are always there and represent a potential source of
integration/disintegration for an engineering manager.

Figure 18.2. Philosophic Level Spectrum

Epistemological Spectrum

Positivism Antipositivism

Knowledge is absolute, Knowledge is soft

objective, and can be subjective, and a
transmitted as tangible functional of the
elements individual

Ontological Spectrum

Realism Nominalism

Reality is external to Reality is an attribution

the individual and of the individual and
objective subjective

Divergence at the philosophic level, Type IV error, can result in conflict with respect to approaching a
complex system problem. For example, from a Positivist/Realist worldview, there would be little tolerance
of engaging systems thinking as an approach not based in the production of tangible products in an ob-
jective manner. On the contrary, from an Antipositivist/Nominalist worldview, a systems thinking effort
without inclusion of subjective knowledge, as a function of individuals, would be inconsistent. The point
is not whether or not the ends of the spectrums are “correct” or “incorrect.” Instead, it is important to
understand where, at the philosophic level, we are placing our worldview in relation to the use of systems
thinking. A disparity in worldview placement invites divergence at the philosophic level and potential
conflict regardless of the “appropriateness” of systems thinking intended by an astute engineering manag-
er. Engineering managers would be well served by questioning the level of compatibility of theirs, as well
as their participants, worldview with systems thinking prior to engagement.

18.3.2 Foundation Principles for Systems Thinking

Systems thinking is built upon a “systems” foundation. Perhaps the most succinct way of providing this
foundation is through several of the most prolific principles, laws, and concepts representative of the
underlying roots for systems thinking. In Table 18.3, we have articulated several of the substantial systems
principles we have found to provide a special insight into the mindset of systems thinking. Although
certainly not an exhaustive set, they offer a special insight into the basis for systems thinking. We have
organized the table to provide the principle/concept, short description, and implications for engineering
managers engaging in systems thinking activities.

292

Table 18.3. Guiding Systems Principles for Systems Thinking
Implications for Engineering
Systems Principle or Concept Description of System Principle Managers Engaging Systems
Thinking
System Darkness (Skyttner, 1996) There can never be complete
knowledge of a system; a complex
system structure and behavior is
emergent and complete knowledge is
not possible and fallible.
Emergence (Keating, 2009) The structural and behavioral patterns
of a complex system will come about
through operation of the system and
cannot be known, or predicted, in
advance of system operation.
Consequent Production (Keating A system can only produce what it
et al., 2001) produces, nothing more and nothing
less. It is perfectly executing to produce
the patterns, performance, behavior,
and structure that it is producing.
Metasystem (Beer, 1979, 1985; Provides the structure of relationships
Keating, 2008) that integrates a system. Structures
the appropriate balance to relieve
tensions between: (1) the autonomy
of subsystems and the integration of
the higher level system, (2) purposeful
design and self-organization, and
(3) focus on maintaining stability or
pursuing change.
Reframing (Fairhurst & Sarr, Reframing (generation of different
1996; Keating et al., 2003) perspectives of a problem/system) is
an iterative and interpretative process
that continues to evolve with additional
information and understanding of
the system operation within the
environment and context.
Systems Thinking
It is fallacious to think there can
ever be complete understanding
of a complex system. Knowledge
unfolds through inquiry, as patterns,
properties, and performance
behaviors become manifest over time.
The notion that understanding will
be static and capable of absolute/
definitive articulation, at any point in
time, is illusionary.
For complex systems/situations, there
are events, structures, and behaviors
that cannot be known, or predicted in
advance. These will only come about
over time with operation of the
system and evolution of the situation.
Care must be taken not to assume
complex situations will remain static
and past solutions will necessarily
yield the same or similar results.
When confronted with performance
or behavior that is undesirable, we
must first look to the system that is
generating the behavior/performance
variance. Understanding and redesign
of the underlying structure of a
“problem system” is necessary to
change the behavior.
Ultimately, systems thinking is about
trying to improve a situation through
adjustment in structure, behavior,
or performance. The metasystem
concept suggests that a focus of
systems thinking be targeted to
understanding the balance within the
system. Each system will have its own
balance in the tensions suggested
of a metasystem, depending on the
particular context within which the
system exists.
Failure to reframe a problem system
assumes perfect initial determination
of the system—an illusion at best.
Systems thinking should incorporate
multiple frames of reference for
complex system problems. This will
ensure a more robust and holistic
perspective for the situation.
293
Engineering Management Handbook
Representation (Keating, 2005)
System Learning (Argyris &
Schön, 1978, 1996)
System Identity (Beer, 1979,
1981)
Value Free Production
(Keating et al., 2001)
Equifinality (Clemson, 1984;
Skyttner, 1996)
294
The representation of a complex
system is not the system; it is only
one of many possible articulations of
the system. The representation both
constrains and enables understanding,
action, and decision spaces concerning
the system problem.
System learning results from the
detection and correction of error.
Correction may occur staying within
the current system structure (single-
loop), or may shift structure based on
question the fundamental assumptions,
objectives, and norms of the system
(double-loop). Both forms of system
learning are necessary.
Every complex system is unique, having
a set of attributes, structure, and
relationships that produce the system
identity.
A system accords no value judgments
to outputs or outcomes that it
produces. Although system outputs/
outcomes may be externally
interpreted as good or bad, a system
produces what it produces from
execution. Therefore, there are no bad
systems, just systems that disappoint
the interpretation of the products they
generate.
There are multiple paths, from different
initial conditions, that can result in the
same output/outcomes for a complex
system.
Care must be taken not to confuse
the abstraction from reality (system
representation) with the actual
system. The representation will always
be incomplete, fallible, and lacking
significant detail of the system. The
representation will be more or less
useful depending on the purposes of
the use.
Understanding the ways in which
a system manages error (detects,
analyzes, and corrects) reveals
underlying patterns of feedback.
System adjustments based on this
feedback is necessary to continue to
produce performance (expected level
outputs and outcomes) in the midst
of external turbulence and internal
flux. Consideration should be made
of the appropriate learning modality
(single or double loop) in response to
variance.
System identity provides a basis
for consistent decision, action, and
interpretation. It must be actively
maintained and represents a minimum
information set that can define the
essence of a system of interest. A
strong system identity creates clarity
and permits the system to act as a
unity in the midst of turbulence.
The complex interactions and
relationships in a system, coupled
with emergence sure to be
experienced, suggest our inability
to completely know a system. If we
have unanticipated performance/
behavior, we should first question
our understanding of the producing
system. By focus on the underlying
system that is producing aberrant
behavior/performance inquiry can
proceed without value judgments,
irrespective of the performance
disappointment. A system produces
what it produces, nothing more and
nothing less.
This implies there is no one “best”
solution to a complex system
problem, only different solutions that
may or may not produce different
results.

Holism (Jackson, 2003)
System Purpose (Beer, 1979)
Relaxation Time
(Clemson, 1984)
Basins of Stability (Clemson,
1984)
We cannot understand a complex
system through reduction to the
component or entity level, approaches
based on reduction to perform analysis
at increasingly finer levels of detail,
are questionable for complex systems
whose behavior exist beyond that of
the constituent parts.
The purpose of a system is “what
it does” (POSIWID). In considering
the purpose of a system, the output
(tangible patterns, products, and
services) and outcomes (impacts) of
the system must be considered. This is
beyond what is intended, designed, or
desired to be produced or achieved by
a system.
A system in dynamic equilibrium
requires a time period (relaxation
time) to return to a state of dynamic
equilibrium following a perturbation
(change) from internal or external
forces. Multiple simultaneous changes
(perturbations) in a complex system,
if additional perturbations occur at a
that occur at a frequency that does not
permit settling into a state of dynamic
equilibrium, will put the system into
oscillation and quite possibly on
a trajectory from which dynamic
equilibrium is no longer achievable.
A system will seek a level of stability
(lowest energy state) unless acted on
by external forces. The system will
move to a new basin of stability (past a
threshold) only when sufficient energy
(resources) are applied to provide
“momentum” necessary to shift to the
new basin of stability.
Systems Thinking
Limitations based on holism are
amplified, since: (1) the system
cannot be disassembled, analyzed,
and ‘put back together’ with any
level of confidence in system level
understanding, and (2) all system
level properties cannot be known,
deduced, or predicted in advance of
their manifestation during system
operation. Reduction requires
abstraction that always invokes
abstraction error.
Purpose must be ascertained through
the examination of what the system
is producing (behavior, performance,
outputs/outcomes), not what it was
intended to produce. Care must
be taken not to confuse intention
with results. Regardless of the well-
meaning intentions for a system
design, purpose must be based on
“actual” outcomes, not those that
were “intended.” It is a fundamental
error to analyze a system based on
design intentions or desires.
Intervention into a system that
invokes multiple changes suggests
that: (1) the system may be placed
into oscillation without the chance
to return to a state of dynamic
equilibrium, and (2) the “impact”
of a single change might not be
understood in the face of multiple
simultaneous changes. Care must be
taken to question the nature, depth,
and interrelationship among changes
initiatives invoked in a complex
system.
In attempting to make enduring
change in a system, there must be an
understanding that the change will be
temporary if sufficient energy (e.g.,
resources, processes, constraint) is
not provided to carry the system
to a new level. The energy must
be in correspondence with the
new stability sought, with sufficient
indicators to recognize achievement
of the new basin (performance/
behavior measurement).
295
Engineering Management Handbook
Viability (Beer, 1979; Keating,
2009)
Sub-optimization
(Skyttner, 1996)
Compatibility (Cherns, 1976,
1987; Taylor and Felten, 1996)
Minimum Critical
Specification (Cherns, 1976;
Taylor and Felten, 1996)
System Control (Beer, 1979)
296
Viability is the ability of a system to
maintain existence. There are three
primary axes for which a system must
have a suitable fit to the environment
to maintain viability: change (ranging
from stability to adaptation), design
(ranging from total self-organization to
purposeful), and control (ranging from
integration to autonomy).
For complex systems, the system is
incapable of performing optimally if all
the subsystems are performing at an
optimal level. For system performance
(integration), subsystems must
“surrender” a level of autonomy that
lessens their ability to perform at an
optimal level.
The objectives sought in a system
redesign must be achieved through
an approach compatible with those
objectives. Inconsistency between
redesign approach and objectives will
not yield the desired effectiveness. This
also extends to compatibility between
the system and the supporting
infrastructure.
Specify only the essential constraints
to achieve the performance level
required by a system. Overspecification
unnecessarily limits the flexibility in the
operation of the system to respond
to varying conditions. However,
minimum specification is required to
permit integration of the system of
systems to produce consistent levels of
metasystem performance.
System control is best established
as close as possible to the point at
which decisive decision and action can
be taken in response to variances to
system performance. This encourages
maximum autonomy (freedom and
independence of decision, action, and
interpretation) for system constituents
in the best position to make timely
decisions that can reduce variances at
the point that they occur.
A system must be questioned with
respect to how it is “appropriately”
fit to the environment within which it
must exist (remain viable). Does the
capability for change correspond to
rate of change of the environment?
Is the design sufficiently loose/
tight to allow responsiveness to
environmental flux? Is the system
minimally constrained to permit
system level performance, while
permitting constituents the greatest
latitude in decision and action?
In the design of integrated systems,
the balance between autonomy
(freedom and independence of
action, decision, and interpretation)
of subsystems must be balanced with
integration (linkage that permits
system level performance). Total
autonomy of subsystems will result
in less than optimal system level
performance.
The selection of approach should
be assessed against the particular
objectives sought from a systems
thinking effort. Misalignment of
objectives to approach is likely to
result in failure to meet expectations.
The supporting infrastructure
(reward, operations, decision,
training, etc.) should be designed to
facilitate the processes necessary
to enable generation of the desired
system behaviors and performance.
Incompatibility can result in less than
desirable results.
In the design of a system, minimal
constraints should be deployed.
Focus must remain on only
implementing the constraints that
are minimally essential to ensure the
performance levels of the system are
met. Overspecification beyond this
minimum wastes resources, limits
overall system performance, and
comes with human costs.
Control for a system is achieved
by maximizing the autonomy of
elements within the system. Systems
thinking must appreciate target
designs that provide for the highest
levels of autonomy within the system.
Control is achieved by establishment
of performance expectations that
maximize independence of elements
within the system (maximum
autonomy). Constraint should only
be invoked as necessary to ensure
continuing system performance.

System Context
(Keating et. al, 2003)
Dynamic Stability (Skyttner,
1996)
Boundary Establishment
System Outcome Achievement
The set of relevant circumstances,
factors, conditions, and patterns that
both constrain and enable the system
solution development, deployment,
operation, and transformation.
Achievement of dynamic stability
is a function of the system’s ability
to respond to fluctuations and
environmental turbulence in ways that
ensure continued levels of required
performance.
Every complex system has boundaries,
established with respect to the
prevailing organizing logic external to
the system. These boundaries must be
explicit such that it can be determined,
at a point in time, what is included and
what is excluded from the system. They
are ambiguous, fluid, and negotiable.
Complex systems have both outputs
(patterns, products, information, or
services which are tangible, directly
measurable, and close in time/proximity
to system deployment) and outcomes
(impacts of the system solution
deployment that are not necessarily
measurable or close in time/proximity
to system deployment). Systems that
only focus on and achieve outputs will
meet requirements. However, to solve
a complex system problem and meet
expectations, achievement of outcomes
as well as outputs is necessary.
Systems Thinking
Complex system problems and
solutions are not independent of
contextual issues such as power,
responsibility, accountability, and
authority. Failure to take these
dimensions into consideration in the
framing of problem systems is naïve
and will result in an incomplete, and
possibly inadequate, framing of the
problem system.
All complex systems are subject to
perturbances generated external
to the system. It is a function of
systems thinking to design system
relationships such that a system is
capable of maintaining desired levels
of performance under conditions
of external stress. Systems Thinking
must ensure that system designs
include sufficient feedback and
feedforward mechanisms consistent
with the level of noise/turbulence
expected to be generated from the
environment.
Complex systems must have
boundaries established initially,
understanding that they will change
throughout the analysis, design,
and transformation as system
knowledge increases and conditions
change. Boundaries may form
around geographic, time, spatial, or
conceptual delineations. Boundary
changes must be processed for
impact on the system. Boundary
shifts are expected and should
be embraced as symbolic of our
advancing understanding of the
problem domain and recognized
emergence in the system.
Establishment of measures for
system performance should not
focus exclusively on output measures.
Consideration must also be directed
to understanding the expectations for
outcomes for the system solutions
and how they can be measured.
Achievement of output expectations
does not assure that outcomes
(expectations related to addressing
the particular problem/need) will be
met. A well balanced approach to
systems must consider both outputs
as well as outcomes.
297
Engineering Management Handbook
Complex Systems
Transformation (Keating,
Peterson, and Rabadi, 2003)
Iteration (Gibson, 2007)
Unity of System Purpose (Beer,
1979, 1985; Jackson, 1991)
Self-Organization (Clemson,
1984)
Satisficing Solutions (Simon,
1969)
298
Transformation of complex systems
requires simultaneous modification
of mechanisms (system entities),
dynamics (patterns of the system
generated through structural
relationships between entities),
context (circumstances and conditions
constraining and enabling system
performance), and the problem
(purpose for bringing the system into
being).
Designing, deploying, and transforming
complex systems are interpretative
processes that continue to evolve
with additional information and
understanding of the system and
context. Failure to iterate a problem
system solution assumes perfect initial
determination of the system—an
unworthy assumption for complex
systems.
Maximizing metasystem performance
requires that the different subsystems
structure their performance, objectives,
and approach to be consistent with
maximizing metasystem performance,
not subsystem performance. The
metasystem cannot achieve optimal
performance without constraint on the
constituent subsystems.
The majority of the structural and
behavioral patterns for a complex
system only emerge after operation
of the system in its environment
(context). Unintended consequences
can be mitigated through design for
robust feedback, feedforward, and
redundancy of critical system functions.
Solutions to complex system problems
should be focused not on achieving
“optimal” results (pursuit of a solution
that exist above all others, regardless
of other considerations, e.g. resources).
Instead, pursuit of “satisficing” results
(recognition that particular designs
and outcomes may be “good enough”
to fulfil the needs or address the
problem) is more appropriate for
complex system problems.
Transformation must be viewed
as a systemic process that must
focus on holistically changing the
state of a system of interest. Efforts
that do not address all four critical
elements (mechanics, dynamics,
context, and system) problem
may produce change, but not
system transformation. Additionally,
transformation must be accomplished
within the organizational/managerial/
policy framework and is not achieved
independent of social (human)
considerations.
Iteration is essential to ensure
that increasing problem system
knowledge, changing environments,
and shifts in conditions, requirements,
and interpretations can be taken
into account. Iteration is important
to avoid solving the wrong problems
or producing inadequate system
solutions.
Assumption of unity of metasystem
purpose is a mistake—unity of
metasystem purpose must be
designed, maintained, and evolved
over time. Unity in a system is a
precursor to ensure that there is
consistency in decisions, actions,
and interpretations taken in behalf
of the system. Lack of unity is likely
to result in fragmentation, unilateral
behavior, and pursuit of objectives by
constituents that are not necessarily
consistent with the overall system.
Self-organization should be
maximized for subsystems of a
complex system of systems. This is
achieved by maximizing autonomy
(freedom of action and decision)
within the minimal system level
constraints that are necessary for
system integration. Unnecessary
limiting of subsystem autonomy can
create waste of system resources and
inefficiencies.
System solutions should be sought
that provide desirable levels of
performance under the given set
of circumstances and conditions—
these are minimally viable solutions,
or satisficing solutions. Solutions
that extend beyond minimal viability
consume resources beyond those
essential to produce acceptable levels
of performance.
 Systems Thinking

Complementarity (Clemson,
1984)
Omnivory principle (Katina,
2016; Watt and Craig, 1988)
There are multiple perspectives of
any given system. Each perspective is
both correct and incorrect, dependent
upon the particular vantage point from
which the system is viewed. Multiple
perspectives are neither entirely
independent nor entirely inclusive.
Stability in a complex system is
achieved by having a greater number
of different pathways for their flow
to the main system components (i.e.,
modification of internal structures to
enable intake of different resources. In
other words, “don’t put all your eggs in
one basket.”)
Multiple views and perspectives are
essential, particularly in the formative
stages for a system of systems effort,
to ensure a robust approach and
design. Failure to include multiple
perspectives can be limiting to the
eventual system of system solution
that is generated.
It is erroneous to develop a system
that can only use a limited set of
resources in the environment. An
engineering manager should always
endeavor to design a system that has
structures that could use different
resources from the environment.

These systems concepts, although they do not exhaust the systems thinking field, provide a founda-
tion into the particular type of thinking that embodies systems based approaches. Consideration of these
concepts provides engineering managers a foundation for more effective thinking, decision, action, and
interpretation related to complex system problems.

18.4.3 Using the Foundations for Systems Thinking

The foundations discussed thus far provide the basis to conduct more rigorous inquiry in the nature,
operation, and performance of complex systems. In effect, they inform the worldview that can assist
engineering managers in dealing with complex system problems and realizing the level of thinking that
can provide understanding of “messes” inherent in turbulent environments and form a basis for escaping
(thinking through) these messes. For future engineering managers, systemic inquiry is essential and we
suggest that this will be one of the most important capability skill sets for dealing with complex system
problems in the 21st century.
Every complex system endeavor is ultimately about solving a problem or fulfilling a need. It is easy
for engineering managers to quickly fix attention on the most accessible aspects of the problem domain
and place the deeper underlying problem/need in the background. However, as experienced engineering
managers know all too well, the most elegant system solution will be ineffective if it does not address the
problem below the superficial symptomatic level, including deep pathological (deviating from normal or
healthy) conditions (Keating and Katina, 2012; Katina, 2015, 2016). Therefore, the capability to appro-
priately engage in systems thinking will be a critical future skill for engineering managers. Additionally,
as the problem domain for engineering managers becomes more complex and contextually bound, the
necessity for systems thinking will only increase in importance.
A systemic view of problems provides additional insights into the issues associated with problem
framing for complex system problems. In taking a systemic view of problems, we consider four important
assumptions. The first assumption holds that problems are a product of a “complex problem system” that
produces the often “symptomatic” conditions labeled as problematic. Therefore, it is inconsequential to
talk of complex problems, or the manifest conditions defined as problematic, as separate and distinct from
the contributing system(s) that generates the conditions. Therefore, the framing of a problem is actually
the framing of the complex system that is generating the conditions recognized as problematic. We first
must discover the problem system. This assumption is consistent with system-based problem solving
approaches that recognize the complex system nature of problems (Beer, 1979; Flood 1999; Flood and
Jackson, 1991). It is more appropriate to talk of a “problem system,” which produces the undesirable con-
ditions, rather than the conditions themselves. In effect, problems represent faulty systems in disguise.
A second assumption for the systemic view suggests that the “framing” of a problem as well as the
problem system is an arbitrary activity subject to multiple interpretations and perspectives. Mitroff (1998)
suggested that if a situation were so troublesome and important to address, why would we only frame it
299
Engineering Management Handbook

from one perspective. There are multiple perspectives, problem system configurations, and representations
that may emerge to depict the problem system. The need for inclusion of multiple perspectives (Jackson,
1991) has long been recognized, as an important element is systems-based methodologies. From systems
theory (Skyttner, 1996), the term “complementarity” has been used to suggest that each depiction of a
system is correct from a particular vantage point, but may also be incorrect from another vantage point.
The arbitrary nature of problem framing is also influenced by language, worldview, perceptions on
framing, and making interpretations of problematic situations (Fairhurst and Sarr, 1996; Weick 1996). This
supports the notion that a problem system is dynamic and subject to reformulation over time and across in-
dividual perspectives. Based on new knowledge, shifts in perceptions, changing conditions, or dialogue, the
potential exist for problem system reframing. Therefore, it is inappropriate to consider that a problem (sys-
tem) can be truly static and closed to influences that may change initial formulations. There is no absolutely
“correct” depiction of a problem system. This echo’s the importance of dialog, interpretation, and shared
understanding in the systems literature (Senge, 1990; Argyris and Schön, 1996; Isaacs, 1999). The notion of
a fuzzy and shifting problem is certainly in stark contrast to the traditional systems engineering deterministic
approaches rooted in “absolute” and “unmoving” definition of the problem once analysis commences.
The third assumption of the systemic view is that actions taken to modify a problem system will pro-
duce intended as well as unintended consequences. Because problem system formulation is not precise,
the consequences of making modifications to the problem system (structure, relationships, and patterns)
will produce effects that cannot be predicted in advance. In systems, this embodies the concept of emer-
gence— the structural and behavioral patterns in a complex system will be exhibited over time as the
system operates. Therefore, the design for effective problem resolution must include the provision for con-
tinuing modification of the system “representation” based on initial or latent unintended consequences.
A fourth assumption suggests that all representations of a complex system exist as abstract reduc-
tions of the actual system. Therefore, they are always incomplete and may require modification based on
new knowledge and information about the system of interest. The problem system is changing and the
representation of that system must also be changing. Again, this assumption is quite unsettling to more
traditional perspectives built on assumptions of stability in definition of systems and the relatively static
nature of their representations.
Given the four systems view assumptions we can move forward to systems thinking as an essential
capability to enable engineering managers to more effectively deal with increasing complexity.

18.4 Systems Thinking: Dealing with Complexity

Systems thinking can provide a valuable capability for engineering managers to more effectively deal with
complex problems. Dealing with increasingly complex problem domains is quite possibly the greatest
challenge facing engineering managers in the 21st century. While not a panacea or absolute solution,
systems thinking can provide engineering managers with an arsenal of grounded approaches to better deal
with complex system problem domains.

18.4.1 Nature and Challenge of Complexity for Engineering Managers

Complexity is a topic for which volumes have been written (Williams, 1997). However, for our purpos-
es, we can view complexity as a condition of the domain that the engineering manager must deal. This
complexity is characterized by a large number of dynamic and richly interactive entities for which the
structure/behavior is emergent, suggesting a high degree of uncertainty. Complexity can be attributed to
either: (1) a function of the entity, independent of the observer(s), or (2) a function of the observer(s),
who makes the judgment of complexity for the entity in focus. Klir (1985) suggests that complexity can
be understood as either the information necessary to describe the vital aspects of the system, or the infor-
mation necessary to resolve uncertainty about the system.
It is instructive to introduce four levels of complexity and their implications for systems thinking in
engineering management. Following the work of Klir (1985) and Clemson (1984), the following four
levels of complexity are presented. However, it is important to understand that this is not intended as an
attempt to force a particular system into one of the four categories. Instead, the complexity of a system
300
 Systems Thinking

should be viewed as a spectrum ranging along a continuum of the four levels. The four levels are instruc-
tive in providing an engineering manager with a more informed perspective concerning the nature of
complexity in a system or problem with which they might be confronted.

Level 1: Organized Simplicity—This represents a low level of complexity. In effect, deterministic ap-
proaches are successful. The mathematics of optimization is appropriate for establishing solutions to well
bounded problems. An example would be a scheduling problem for minimizing overtime costs.

Level 2: Organized Complexity—This level of complexity is characteristic of probabilistic problem do-

mains. There is not absolute certainty in relationships among variables. However, the use of probability
and statistics can provide appropriately ranged solution spaces. An example is completion of a project
within an allocated time period.

Level 3: Dynamic Complexity—Dynamic complexity exists where there is not sufficient bounding of the
problem domain, the language of mathematics/statistics is not capable of simplifying the problem space,
and extreme uncertainty (unquantifiable). An example of this form of complexity is the building of a high
performance engineering team.

Level 4: Relativistic Organized Complexity—This complexity level appreciates that individuals may
have varying perspectives of similar circumstances/events. The particular worldviews and their derivative
interpretations are a function of the individual “observer.” They are neither right nor wrong, but exist as
“different” based on potentially conflicting assumptions and logic upon which they are predicated. An
example is the assessment of managerial performance in crises.
The importance of these levels of complexity is twofold. First, as the levels increase, there is concur-
rent increase in complexity of the problem domain. This requires that the complexity and sophistication
of thinking also increase to match that of the problem domain. Second, that Systems Thinking becomes
increasingly important as the level of complexity increases. The domain of the modern engineering man-
ager is certainly characterized by higher levels of complexity. This suggests the increasing importance of
developing and applying more effective systems thinking to deal with this complexity.
Systems thinking begins at the individual level. However, we might ask, what are the particular attri-
butes that would serve to distinguish “systems thinking” from “non-systems thinking”? In the following
section we provide a set of attributes that can help classify the particular level of systems thinking that a
manager might be capable of engaging.

18.5 Systems Thinking Capacity for Engineering Managers

Based on the attributes of systems thinking that have been identified, we suggest that engineering managers
and the units they manage might have varying degrees of capacity to engage in systems thinking. In de-
termination of the capacity for systems thinking that exist in a situation, we must consider the individual
as well as system level (arrangement of individuals with collective capacity for systems thinking). At the indi-
vidual engineering manager level, Jaradat’s (2015) research produced a 39-question instrument to establish
the capacity for an individual to engage in systems thinking. Table 18.4 provides a summary of the different
dimensions Jaradat’s (2015) instrument used to classify individual capacity for Systems Thinking.

301
Engineering Management Handbook

Table 18.4. Systems Thinking Characteristics (Jaradat, 2015)

Systems Spectrum of Individual Engineering Manager Systems Thinking Capacity

Thinking More Systemic
Characteristic
Level
Complexity COMPLEXITY (C) – Expect uncertainty, work on
multidimensional problems, prefer a working solu-
tion, and explore the surrounding environment
Autonomy INTEGRATION (G) – Preserve global integration,
tend more to dependent decision and global perfor-
mance level
Interaction INTERCONNECTIVITY (I) – Inclined to global
interactions, follow general plan, work within a
team, and interested less in identifiable cause-effect
relationships
Change RESISTANCE TO REQUIREMENTS (V) – Prefer
taking multiple perspectives into consideration,
underspecify requirements, focus more on exter-
nal forces, like long-range plans and thinking, keep
decision options open, and work best in changing
environment
Uncertainty EMERGENCE (E) – React to situations as they occur,
and Ambiguity focus on the whole, comfortable with uncertainty,
believe work environment is difficult to control,
enjoy subjectivity, and non-technical problems
Hierarchical HOLISM (H) – there exist multiple, potentially diver-
View gent, perspectives on the problem domain.
Flexibility FLEXIBILITY (F) – accommodate change, like flexible RIGIDITY (D) – prefer not to change, like
plans, open to new ideas, unmotivated by routine determined plan, motivated by routine
Less Systemic
SIMPLICITY (S) – Avoid uncertainty, work on
linear problems, prefer best solution, prefer
small scale problems
AUTONOMY (A) – Preserve local autono-
my, tend more to independent decision and
local performance level
ISOLATION (N) – Inclined to local inter-
action, follow detailed plan, prefer to work
individually, enjoy working in small systems,
and interested more in cause-effect solutions
EMBRACEMENT OF REQUIREMENTS (Y) –
Prefer taking few perspectives into consider-
ation, over specify requirements, focus more
on the internal forces, like short-range plans
and thinking, tend to lock in decisions, and
work best in stable environment
STABILITY (T) – Prepare detailed plans
beforehand, focus on the details, uncomfort-
able with uncertainty, believe work environ-
ment is under control, enjoy objectivity, and
technical problems
REDUCTIONISM (R) – assumes that there
is alignment of perspectives for the problem
domain.

The thrust of Jaradat’s (2015) instrument is to provide a “baseline” snapshot that profiles the level
of systems thinking for an individual. Determining individual capacity for systems thinking has several
important implications for engineering managers. First, the individual capacity to engage in systems
thinking is critical to the proper deployment of any of the systems based methods, tool, or techniques
developed in the following section of this chapter. Ultimately, understanding and appreciating the level of
individual capacity for systems thinking can help determine what can realistically be pursued (e.g., initia-
tives) by an engineering manager related to addressing complex system problems. Take for instance a case
were an engineering manager wishes to pursue an initiative requires a “high” level of systems thinking to
increase the feasibility of success. Further, that the “high” level is not held by individuals who will assume
responsibility for execution of the initiative. It follows that the probability for success in the execution
of the initiative is suspect. The engineering manager must make the determination as to whether or not
sufficient systems thinking exist in the unit that will assume responsibilities for the initiative. Otherwise,
the risk of failure in the initiative will be heightened.
The purposeful consideration and assessment of systems thinking can assist engineering managers by:
(1) determining the compatibility of individuals level of systems thinking with the degree of complexity
that exist in the initiative, (2) appropriately arranging a variety of individuals with different proclivities for
systems thinking, such that there is a systemic diversity in thinking available to the initiative—as all sys-
temic thinkers or all non-systemic thinkers can limit progression, and (3) advancing the state of systems
thinking must be commensurate with the environment and systems under the purview of the engineering
manager. Thus, a fundamental responsibility of the engineering manager is to be knowledgeable of both
the complexity in the situations for which they are responsible as well as the capacity of their units and
individuals to engage in a level of systems thinking that can “match” that required of the situation.
302
 Systems Thinking

18.6 Systems Thinking as a Responsive Strategy for Dealing with

Complexity
Systems thinking can be an effective aid to engineering managers in dealing with complexity. Howev-
er, it is also significant to note that systems thinking can offer engineering managers a strategy for more
effectively dealing with the complex problem domains they must face. There are several strategic consid-
erations that engineering managers should ponder with respect to gaining utility from systems thinking.
Among these strategic considerations are:
1. Seeking to match the level of systems thinking of assigned units to that required for the complexity of work
being engaged—Both individuals and the overall system of interest have a level of systems thinking.
For individuals, Jaradat’s (2015) classification to determine the individual capacity for systems think-
ing offers a good starting point for assessment. Ultimately, the success of endeavors engaged by engi-
neering managers will be influenced by the degree to which the appropriate level of systems thinking
is commensurate with the activities undertaken. A mismatch between activities and the requisite
level of systems thinking required is at best likely to produce results that fall short of expectations. At
worst, the failure due to mismatch might not only waste scarce resources but might actually make the
situation worse.
2. Ensuring compatibility of supporting infrastructure with engagement in systems thinking—Initiatives
undertaken by engineering managers are not executed in a vacuum. Instead, the more likely scenario
is engagement in initiatives that will both influence, and be influenced by, supporting infrastructure
(e.g., processes, support systems, functions, procedures, etc.) that are influential in execution of the
initiative and as well as its corresponding systems. Engagement in systems thinking requires apprecia-
tion of the constraints as well as enabling capacity that the supporting infrastructure provides. There
must be compatibility of the infrastructure with the level of systems thinking required to deal with
the complexity in the situation. Lacking compatibility cast doubt on the realization of the potential
for a systems thinking based initiative.
3. Inclusion of systems thinking development as part of initiatives—Systems thinking cannot be viewed
as a static level for either individuals or units engaging complex system problem domains. On the
contrary, engineering managers must seek to actively advance the state of systems thinking at both the
individual as well as the unit level as part of initiatives. It is not sufficient to simply examine the level
of systems thinking and assess compatibility for the initiative(s) being undertaken. This would miss
the strategic opportunity to develop, as well as apply, systems thinking capacity.
4. Focus on building increased capacity for systems thinking for increasingly difficult endeavors—Engineer-
ing managers will increase their unit’s capacity to engage ever increasing levels of complex problem
domains by increasing the capacity to engage in systems thinking. While individual initiatives present
an opportunity (born of necessity) to enhance systems thinking, there is an opportunity, and respon-
sibility for engineering managers to enhance the systems thinking capacity of their workforce. This
will serve to bolster the future capacity to deal with complex problem domains.
5. Emphasis on thinking and non-prescriptive action—Engineering managers must appreciate that ev-
ery complex problem is unique and exists in a unique context. Systems thinking can be helpful in
exploring this uniqueness, and perhaps, finding a path forward that might not have been recognized
through other forms of thinking. However, systems thinking will miss the mark if it is: (1) deployed
prescriptively rather than fit to the particular circumstances of the situation, and (2) not continually
focused on completing the continual cycle of thinking—action—thinking.

Systems thinking is not a cure-all that can address all problems faced by engineering managers who
must deal with increasing complex systems and problems. However, it invites engineering managers to
engage this complex problem domain from a different level of thinking. In the end, systems thinking may
open an entirely different range of alternative decisions, actions, and interpretations in pursuit of increas-
ing effectiveness for EM.
While the methods and tools for systems thinking are numerous, they can be classified in a way to
permit engineering managers greater access. In the following section we have identified existing methods
303
Engineering Management Handbook

and tools to facilitate systems thinking for engineering managers. This listing is presented as “all inclusive”
of systems thinking methods and tools. However, it is representative of that which is available to EM
practitioners. We can be certain that it will expand in the future.

18.7 Methods and Tools for Systems Thinking

The true power of systems thinking is in providing a systemic perspective that informs an effective re-
sponse to a complex problem in a particular context. In effect, an engineering manager must “do some-
thing” in response to the undesirable situation. In “doing something,” systems thinking offers a robust
perspective to increase the probability of positively impacting the situation. As a fitting complement
to the philosophical and principles basis previously established earlier, it is time to shift directions and
discuss how engineering managers can translate previously discussed “systems thinking” knowledge into
action via methods and tools.
Several available methods and tools are very powerful for the types of situations and actions engaged
by engineering managers. Figure 18.3 show examples of familiar activities of engineering managers where
systems thinking methods can play a significant role. These activities include:
1. Boundary/Value Judgments—Establishing the separation between what is included and what is exclud-
ed for the system in focus. This includes the criteria for inclusion/exclusion.
2. Problem Structuring/Framing—Providing for ordering of the problem domain such that a path for-
ward can be established, perspectives understood, and the representative “system(s)” constructed.
3. Sense-making—Development of the interpretations that can serve to satisfy the different worldviews
essential to the further development of the problem domain and appropriate responses.
4. Theory–generation and Testing—Construction of the plausible explanations for the complex system
behavior/performance that can serve as a platform for testing.
5. Comprehensive Understanding—The deep systemic understanding of the situation such that consistent
decision, action, and interpretations can be made to facilitate improvements in the problem do-
main.
While the simple representation does not purport to be an exhaustive nor sequential list of activi-
ties undertaken by an engineering manager, it recognizes the breadth and depth of the range of actions
performed by an engineering manager. In practice, action ranges across a spectrum that is actually con-
tinuous and nonlinear. Systems thinking can figure prominently into this range of activities that typically
starts out with observation or conceptualization, culminating as an actual intervention where resulting
outcomes condition the necessity for learning. In the following sections, a more detailed description will
be presented on the special role systems thinking methods and tools have for day-to-day engineering man-
agement situations. Several developments in the research community are better understood in terms of
available taxonomies of different systems based approaches (methodologies). We will briefly describe im-
portant ideas that draw from extensive work covered by Jackson (2000, 2003), Midgely (2000), Mingers
(2006) and most recently by Cabrera et al. (2008). These works include well-articulated arguments and
foundational discussions to understand how the rationales for these different taxonomies were developed.
Finally, to close the section, we present a brief overview of available selected systems thinking methods
and tools that engineering managers can easily use in their specific problem context or domain.

304
 Systems Thinking

Figure 18.3. Observation Through Intervention Activities Loop

Comprehensive
understanding
Theory-generation
& testing
Sense-making

Problem-structuring
Problem …to intervention
or Framing

Boundary/value
judgements

From observing/conceptualizing…

18.7.1 Role of Tools for Systems Thinking

While the philosophical and principle base presented are crucial, in the end an engineering manager is
charged with action. He or she must, from a solid foundation, apply that thinking to the problem domain
at hand. Thinking without action will not fully utilize systems thinking. In recognition of this dilemma,
long ago Checkland (1981) suggested making a distinction between those efforts mainly concerned with
the theoretical development of systems thinking versus those efforts primarily concerned with the applica-
tion of systems thinking to real-world problems. The systems thinking application side are what Jackson
(2000, 2003) refers to as “applied systems thinking,” which deals with particular methods and tools. This
will be the main focus in this section.
We have previously identified the nature of the problem domain characteristic of that faced by the
modern day engineering manager. Interestingly, in response to this diverse problem domain, there is a
proactive research community that responded with methods and tools to enhance capabilities and to
deploy them in increasingly complex problem domains. Aside from the fact that one can easily identify a
voluminous number of methods/tools, one can note the conflicting definitions of methodologies, meth-
ods and tools or techniques. Following the work of Midgley (2000), Checkland (2001), and Mingers
(2006), we suggest the following relationship of methodologies, methods, and tools:
1. Methodology—Refers to the set of theoretical formulizations that substantiate the use of methods. It
provides a high level framework, philosophically based, which offers a general guide to practitioners.
2. Methods—Refers to a set of tools or techniques used in iterative-sequential fashion to achieve specific
purposes.
3. Tool—A specific implement to achieve a defined activity or purpose.

For systems thinking the distinction and interrelationship between methodology, methods, and tools
is important. Figure 18.4 depicts this relationship and three important points for past, present, and future
development and use of the appropriate methodologies, methods, and tools. First, as systems thinking has
evolved over time, there still ensues an ongoing cumulative effect of evolving earlier efforts. For example,
multimethodologies are built upon previously developed limited focus methodologies. Second, the land-
scape for methodologies, methods, and tools continues to evolve. Finally, although implicit, the basis for
systems-based approaches is to be found in the underlying systems paradigm upon which they have been
built, deployed, and evolved.

305
Engineering Management Handbook

Figure 18.4. Making Sense of “Methodologies,” “Methods” and “Tools”

New developments
Methodologies
Methods (Complex adaptive conceptual systems,complexity and chaos
Tools theory)

Methodologies Multimethodologies

Level Recursions
Methods
Tools (exclusively systems-based
based such as creative holism, critical
realism and creative design of methods)

Methodologies Soft systems

Methods
Tools
(Qualitative, participative such as the soft systems
methodology, interactive planning, total systems intervention)
Methodologies
Methods
Tools
Hard systems
(mostly Quantitative such as statistical modeling, operations
research, simulation)

Figure 15.4. Making Sense of “Methodologies,” “Methods” and “Tools”

Therefore, as the list of systems thinking methodologies, methods, and tools continues to evolve,
engineering managersTherefore,
should takeassome list ofofsystems
the level thinking
solace. While newmethodologies,
developments will methods,
continue, andtheto
tools
under-
continuesfoundations
lying systems thinking to evolve, engineering managers
remain relatively should
consistent take
and some alevel
provide of solace
solace.
reference pointWhile new
for assess-
developments will continue, the underlying systems thinking foundations remain
ment, application, and interpretation of future developments.
relatively consistent and provide a reference point for assessment, application, and
Ideally as engineering
interpretationmanagers, “doing something” involves purposeful action, ultimately based on
of future developments.
thinking and subsequent decision. To
Ideally as engineeringsupport this “doing,”
managers, necessary
“doing levels involves
something” of performance
purposefulrequires ap-
action,
ultimately based on thinking and subsequent decision. To support
propriate methods and tools. The support of appropriate systems thinking methods and tools is a rich and this “doing
“doing,”
long history ofnecessary
continuinglevels of performance
theoretical progress andrequires appropriate
burgeoning methods
collective and tools.
application The support
experience. What
of appropriate systems thinking methods and tools is a rich and long history of
continues to draw practitioners, including engineering managers, is the allure that systems thinking in
continuing theoretical progress and burgeoning collective application experience. What
offering an alternative
continues waytoofdraw
thinking and enhanced
practitioners,
practitioners capability
including to engagemanagers,
engineering increasingly iss complex
the allure situations.
that
Systems thinking helps thinking
systems reframe how we view
in offering ana alternative
problem and wayhowof athinking
successful andengagement
enhanced might appear.
capability to
While reframing engage
how we increasingly
think about complex situations.
the problem doesSystems
not assure thinking helps
successful reframe
eframe how
resolution, we view
different sets aof
problem
methods and tools and howmore
will support a successful engagement
robust approaches mightwith
to dealing appear.
complexWhile refram domains.
reframing
problem how we
think about the problem does not assure successful resolution, different sets of methods
In the following section we present a taxonomy of tools for systems thinking. This taxonomy is
and tools will support more robust approaches to dealing with complex problem
intended to provide
domains.engineering managers with a strong base of understanding the range of tools available
to aid in their activities. Thefollowing
In the literaturesection
on systems based methodologies
we present a taxonomy of tools is diverse (Flood and
for systems Jackson,
thinking. This
taxonomy is intended to provide engineering managers
1991; Jackson, 1991). Certainly, we can acknowledge the strong influence of systems in EM stemming with a strong base of
from the early understanding the range(1968).
work of Von Bertalanffy of toolsThe available
followingto examples
aid in their activities.
of systems The
he literatureareonpro-
methodologies
systems
ems based methodologies is diverse (Flood and Jackson Jackson, 1991; Jackson Jackson, 1991).
vided as particularly demonstrative of effectively using a system approach for design, analysis, operation,
Certainly, we can acknowledge the strong influence of systems in EM stemming from
and transformation of complex
the early work systems
of VonorBertalanffy
resolution of(1968).
complex Theproblems.
following examples of systems
A summary of the selectedare
methodologies methodologies are provideddemonstrative
provided as particularly in Table 18.5.ofEach of theseusing
effectively system based
a system
methodologiesapproach
for designh for
anddesign, analysis,
resolution operation,
of complex systemand transformation
problems has beenofprovencomplex systems
effective. Theyor
resolution
each offer a specific set ofoftools
complex problems. to facilitate system problem solving that addresses design,
and perspectives
analysis, operation, and maintenance of complex systems and problems. They are all capable of generating
success. Similarly, they are all capable of generating failure.
Page 28 of 50

306
 Systems Thinking

Table 18.5. System-based Methodologies

System Method(ology) Major Theme Primary Author(s)

Organizational Diagnosis of structural system functions, relationships, and Beer (1979)
Cybernetics communications channels necessary for any system to maintain Beer (1981)
existence. Beer (1985)
Espejo and Reyes
(2011)
Sociotechnical Systems Work system analysis and redesign based on joint optimization of the Trist and Bamforth
social and technical subsystems for performing work. (1951);
Pasmore (1988);
Taylor and Felten
(1993)
Systems Engineering Structured formulation, analysis and interpretation of the technical, Blanchard and Fabrycky
human, and organizational aspects of complex systems to address (1998);
needs or resolve problems subject to cost, schedule, and operational Sage (1992)
performance constraints.
System Dynamics Computer modeling and simulation approach to understand the Forrester (1975); Maani
relationships and underlying behavior of complex systems. and Cavana (2000)
Operations Research An analytical approach to problem solving and management based on Hillier and Lieberman
determination of the mathematical optimal, or most efficient, means (2003)
of achieving an objective.
Soft Systems A process of inquiry focused on formulation of ill-structured Checkland (1999, 2000)
Methodology problems appreciative of multiple perspectives.
Interactive Planning Continuous organizational planning to design desirable futures and Ackoff (1981)
develop strategies to achieve that future through participation,
management structures, planning, and process.
Total Systems A system problem-solving approach based on creative thinking, Flood and Jackson
Intervention appropriate method selection, and implementation of method based (1991)
change proposals to resolve complex issues.
Strategic Assumption Focuses on the resolution of ill-structured problems by identifying Mason and Mitroff
Surfacing & Testing multiple stakeholders, their assumptions, and engaging in dialectical (1981)
debate over proposed strategies to develop a higher-level course of
action.
Critical System A process of critical reflection based on a set of boundary questions Ulrich (1983)
Heuristics that examine the legitimacy of designs by contrasting what “is”
proposed versus what “ought” to be.
Organizational Makes explicit individual and organizational models that enable Argyris and Schön
Learning organizations to make explicit and test tacit structures and patterns (1996);
which generate system behavior Senge (1990)
Project Management Structuring and design of work to produce products and services Kerzner (2009);
subject to cost, schedule, and performance constraints. Meredith and Mantel
(2000)
System of Systems An approach to design, analysis, operation, and transformation of Keating et al. (2003);
Engineering metasystems, composed of multiple embedded semiautonomous Sousa-Poza, Kovacic,
subsystems. and Keating (2009);
Jamshidi (2009)
Complex System An approach based on the design, execution, and evolution of nine Keating (2015)
Governance metasystem functions that provide for the control, communication,
coordination, and integration of a complex system.
Gibson’s Systems Provides six iterative phases to study complex systems problems, Gibson, Scherer, and
Analysis Methodology including System Goals, Ranking Criteria, Alternative Development, Gibson (2007)
Alternative Ranking, Iteration, and Action.

307
Engineering Management Handbook

At the highest level of understanding for systems thinking, there exist methodologies. Perhaps one of
the most comprehensive categorizations of methodologies that reflect this comes from the work of Jackson
(1991).
We begin with “Creative Holism,” which is actually a term coined by Jackson to culminate in fact his
studies about system of systems methodologies and different system approaches in the past decade (Jack-
son, 1990, 2000). Concerning creative holism, Jackson (2003) emphasizes an approach to maximize the
advantages of combining different holistic approaches/methodologies creatively. He suggests the informed
use of methodologies/methods/tools to help thrive with “the complexity, turbulence, and diversity” of
current real world problems (p. 275). He presents his taxonomy for methods/tools by using four sociolog-
ical paradigms and several organizational metaphors that imagines an organization as machines, organ-
isms, brains, cultures, and political systems among others. With insights by using metaphorical lenses in
conjunction with paradigmatic lenses consisting of four sociological paradigms (functional, interpretative,
emancipatory and postmodern), he argues that each of the different holistic system approaches can be
broadly matched under the ones he suggested in Table 18.5.

Table 18.6. Jackson’s “Creative Holism” Taxonomy

Type A, B, C, D Taxonomy
Examples
Systems approaches…
Hard Systems thinking
System dynamics
For improving, goal seeking and viability (Type A)
Organizational Cybernetics
Complexity Theory
Strategic Assumption Surfacing Testing (SAST)
For exploring purposes (Type B)
Interactive Planning
Soft Systems Methodology
Critical Systems Heuristics
For ensuring fairness (Type C)
Team Syntegrity

For promoting diversity (Type D) Postmodern Systems Thinking

Towards Creative Holism— Total Systems Intervention

A Multimethodology Approach Critical Systems Practice

The primary implication for engineering managers is to carefully consider the primary objective being
pursued as an indicator of the appropriate methodology to be engaged.

18.7.2 Taxonomy of Tools for Systems Thinking

For systems based approaches, there is no definitive or universally accepted classification of methods or
methodologies. However, it is somewhat naïve to equate, as some authors do, systems thinking to System
Dynamics. System Dynamics is a computer-based modeling approach that analytically examines the rela-
tionships between systems entities. Ultimately, it offers understanding of, potentially counterintuitive, be-
havior and allows examination of the consequences for shifts in system structure. The task of articulating a
taxonomy of tools/approaches to aid in systems thinking is somewhat daunting. However, we have settled
on an adaption of Cabrera et al. (2008) as a useful framework to organize the tools/methods supportive of
Systems Thinking. It is important that:
1. Our objective is not to describe in detail each tool as this would reach beyond the grasp of this exam-
ination. On the contrary, our objective is to briefly acquaint readers with the nature and applicability
of tools/methods and to provide reference for further exploration if desired.
2. Any list of tools/techniques available for systems thinking is dynamically changing and in this sense
incomplete. Although, we have organized our discussion to capture a large contingent of tools/meth-
ods readily available to engineering managers inclined to further pursue use of the tools.
3. By nature, any taxonomy is somewhat arbitrary and no doubt other classifications or categorizations
308
 Systems Thinking

are possible. Each is correct from a particular vantage point. This taxonomy offers a start to make the
tools/methods to support systems thinking more approachable for engineering managers.

For our purposes we have selected a framework of Cabrera et al. (2008), referring to it as the
DSRP framework, to organize around: (1) Distinctions—making distinctions between elements, (2)
Systems—forming a system based on impacts of elements with one another, (3) Relationships—linkage
or coupling between entities, and (4) Perspectives—recognition of viewpoints that exist in understanding.
Because engineering managers can easily grasp the aspects Distinctions, Systems, Relationships, and Per-
spectives in their daily activities, we felt this framework would make the systems thinking tools/methods
more approachable for practitioners.

18.7.3 Selected Tools for Systems Thinking

In this section, our objective is to provide engineering managers with a reference guide that brings some
structure and order to the vast array of tools and techniques capable of supporting systems thinking.
We have intentionally focused on a selection of methods and tools for systems thinking that remains
useful and promising to be applied for today’s complex problems and issues. Where earlier systems think-
ing tools appear to be crude and rudimentary, we have elected not to include them. However, several tools
have stood the test of time and still remain in their basic implementation because of their simplicity and
intuitiveness. These have been included. Table 18.6 identifies the methods/tools around purpose, utility,
and source reference. Again, the intent is to acquaint engineering managers with an array of tools/meth-
ods that may be useful to implement in support of systems thinking practice.

18.8 Systems Thinking Implications for Engineering Management

Systems thinking can provide a valuable capability for engineering managers to more effectively deal with
complex problem domains. We have presented systems thinking from the perspective of providing a way
to more effectively frame complexities faced by engineering managers. The basis for this frame has been
built upon the underlying worldview that suggests understanding must be at the level of the whole (ho-
lism) and the behaviors that exist beyond those of the constituent entities that comprise the system. We
have suggested the utility of systems thinking for engineering managers as: (1) providing a robust set of
language and concepts that can permit a different level of thinking necessary to better deal with increasing
levels of complexity; (2) providing multiple methodologies, methods, and tools that can support more
sophisticated treatment of complex problem domains; and (3) a more rigorous conceptually based ap-
proach for appreciating the contribution of disciplined and structured inquiry to generate more informed
decision, action, and interpretation where more traditional thinking/approaches fall short.
However, systems thinking is not a panacea that will assure universal success. On the contrary, it is
necessary to identify some guidance as well as implications for engineering managers wishing to engage
systems thinking. In the sections below we identify some guidance for using systems thinking and delin-
eate several of the assumptions that engineering managers may need to question prior to application of
systems thinking based approaches.

18.8.1 Using Systems Thinking in Engineering Management

We have established that systems thinking is not a prescriptive methodology, method, or tool. Instead it
has been presented as a collection of concepts, principles, methodologies, methods, and tools. This collec-
tion requires engineering managers to assume a different, higher level, role as a user of systems thinking.
This different role is much more of a designer of a systems thinking effort, rather than simply a user of
systems thinking. As such, we suggest the following six guidelines for engineering managers seeking to
gain the advantages from application of systems thinking.
1. Uniqueness of the Problem/Need—Every problem/need faced by an engineering manager is unique.
Although there may be similarities to previous encounters, the assumption of uniqueness is critical to
ensure that there is not an arbitrary predisposition for a particular approach that may have been suc-
309
Engineering Management Handbook

cessful in different contexts and problem domains. Systems thinking can be beneficial in understand-
ing the problem as a system, from which the undesirable behavior, structure, or performance exist as
the product of the system. Thus, the first focus is on the “problem system,” not the output/outcome
of that system (performance/behavior).
2. Uniqueness of the Problem Context—Every problem system is embedded in a unique context. This
context is the unique set of circumstances, factors, conditions, or patterns that will enable/constrain
the problem system and potential solutions. Context will also influence the range of “acceptable”
approaches, decision, actions, interpretations, solution design, and solution deployment. A major role
of systems thinking is to better appreciate and account for problem system context.
3. Uniqueness of the Methodology for Deployment—To use systems thinking for complex systems prob-
lems requires construction of a specific methodology. This methodology must be compatible and
appropriate for the unique problem and context. There is no methodology that is universal and can
be applied with the confidence that the results will be repeatable. On the contrary, every complex
problem requires a methodology that is appreciative of the uniqueness of the circumstances.
4. Compatibility—Engineering managers deploying systems thinking based approaches to complex
system problems must minimally take into account the degree of compatibility between the problem,
context, and methodology. In addition, systems thinking is based on a particular “worldview.” It is
inherent that the dominant worldviews are compatible with systems thinking if an effort is to have a
probability of success. Without this compatibility, more harm than good might be generated from a
systems based effort.
5. Systemic Framing—The power of systems thinking is in the capability to develop more holistic
perspectives of the situation. This relies on thinking in terms of systems, drawing on the underlying
systemic frame through language, concepts, and perspectives to develop more robust understanding
of the situation. By developing multiple plausible frames, engineering managers can establish more
informed understanding and knowledge of the situation. This in turn opens the potential decision
space that might have been obscured from singular perspectives. Framing, from a systemic perspec-
tive, is an ongoing activity. This is essential as the complexity of a problem increases.
6. Anticipating Emergence—Emergence is simply a fact of life for complex system problem domains—it
will happen. We must also realize that the very nature of emergence suggests that we cannot know
when, where, in what form, or how emergence is going to occur. What we do know, and how systems
thinking can be helpful, is that our system solutions must be resilient across a spectrum of potential
emergent perturbations. For systems thinking based design, this suggests a focus on systems that can
identify, analyze, classify, respond, and evaluate effectively to address emergent conditions.

This set of guidelines will not assure success for engineering managers deploying systems thinking.
However, they can be helpful in avoiding potential pitfalls in applications of systems thinking.

18.8.2 Limitations for Systems Thinking

As we have mentioned previously, systems thinking is not a panacea that will solve all issues for engineer-
ing managers. There are several limitations that should be considered for deployment of systems thinking
based initiatives. For conciseness, we have identified four primary areas that engineering managers should
consider as they use systems thinking to assist in dealing with complex system problem domains. These
limitations include: (1) requisite compatibility with the systems perspective, (2) fundamental systems
knowledge, (3) accessibility to systems-based methods, and (4) intrusion of power and politics. These
major themes and their implications for deployment of systems thinking based approaches to deal with
complex problems are discussed below.
1. Requisite Compatibility with the Systems Perspective—It is relatively easy for an individual or group
to announce to the world that they have a systems perspective. However, it is quite another issue to
demonstrate that perspective through language, thinking, decision, action, and interpretation. The
approach to systems thinking about complex issues has been described as a worldview (Checkland,
1999; Wilson, 1990) or systems paradigm (Flood and Carson, 1993). The systems paradigm includes
310
 Systems Thinking

such perspectives as holistic understanding, relationships, and boundaries (Hall, 1989), consistent
with the foundations we have established in this document. Working within any systems-based
methodology or framework requires that individuals have a perspective compatible with the systems
paradigm. The implication for engineering management practice is that compatibility of the systems
thinking perspective should be explored prior to engaging in a systems thinking based excursion. In-
compatibility of the systems perspective with the dominant logic/worldviews increases the probability
for failure.
2. Fundamental systems knowledge—There must be a base level of system knowledge to effectively engage
in a systems-based initiative. At a minimum, basic systems knowledge must be appreciative of the
language (boundaries, output, input, relationships, environment, etc.), concepts, and methods as they
are used in support of the systems-based initiative. Simply having a “systems” perspective is insuf-
ficient to effectively engage in systems thinking based initiatives. Instead, participants must have a
grounding in the essential systems knowledge that transcends any methodology, method, or tool used
in support of systems thinking based efforts. The implication for engineering managers is to ensure
that the individuals and the collective group examine the level of system knowledge maturity prior
to engaging in a systems-based effort. Maturity development activities can be accomplished prior to
analysis, concurrent with analysis, or post analysis to increase the effectiveness of the inquiry.
3. Systems methods accessibility—There is a wide array of systems methodologies and methods available
to support resolution of complex issues (Jackson, 1991). Many of those methodologies, methods, and
tools have been referenced in this document. However, most engineering managers have had little
exposure to these. Therefore, engagement in a systems thinking-based effort will require understand-
ing of the methodology, methods, or tools as well as grounding in the underlying systems paradigm.
A criticism of systems based approaches is the potential reliance on “experts” to facilitate movement
through the effort. The implication for systems thinking based efforts is to balance exposure to
systems methods with the individual/collective understanding of the applicability, limitations, and
appropriateness of particular systems methods.
4. Intrusion of Power and Politics—System based approaches, particularly hard systems approaches, have
not been designed to deal with the politics/power dimensions inherent in efforts to improve com-
plex systems. There is recognition in some approaches (e.g., Checkland’s Soft Systems Methodology,
Argyris and Schön’s Organizational Learning Systems) that acknowledges the influence of power
and politics. However, engineering managers must be cautioned that, when dealing with problem
domains that involve divisive context with unfavorable politics/power dynamics, systems based ap-
proaches may fall short of expectations.

Systems thinking, as any approach in engineering management, has limitations. However, engineer-
ing managers may find that the benefits of system thinking application far outweigh these limitations,
Systems thinking can be extremely powerful, applied to the right problem domain under the right cir-
cumstances and with the appropriate expectations.

18.9 Conclusion
Systems thinking can provide a valuable capability for engineering managers to more effectively deal with
complex problems. In this chapter we have provided a foundation for systems thinking. It is crucial for
engineering managers wishing to get the most out of systems thinking in practice to recognize that effec-
tive applications of systems thinking operates on five interrelated levels. Mastery and realization of the
potential of systems thinking requires understanding, capabilities, and application across the spectrum of
these levels (Figure 18.5).
For engineering managers systems thinking can seem somewhat daunting at best and unapproach-
able at worst. However, in this exploration we have attempted to provide engineering managers with an
appreciation of systems thinking and how it might be approached to provide utility for practice. Our
approach has shied away from providing a prescriptive method or tool that, for some, might be imme-
diately satisfying, but in the long view unremarkable. Instead, we have provided an exploration of the
311
Engineering Management Handbook

subject of systems thinking in a way to gives a broad coverage of the topic and invites engineering manag-
ers to appreciate the full spectrum of systems thinking, ranging from philosophical roots through available
implementing tools.

Figure 18.5. Levels of Integrated Systems Thinking Application

Foundations for Effective Systems Thinking

Applications in Engineering Management
SYSTEMS TOOLS – a specific implement to achieve
a defined activity or purpose.

SYSTEMS METHOD – refers to a set of tools or

techniques used in iterative -sequential fashion to
achieve specific purposes.

SYSTEMS METHODOLOGY– High level frameworks

Integrated that provide broad based guidance for engaging
Systems systems based applications.

Thinking SYSTEMS PRINCIPLES/CONCEPTS – Establishes the

guiding generalizations that are taken as truths to
form the basis for consistent reasoning and
application.

SYSTEMS PHILOSOPHY – Provides the worldview

as a foundation for decision, action, and
interpretation consistent with the systems
paradigm. The heart of systems thinking.

We conclude by identifying several implications for engineering managers seeking to use systems
thinking in practice:
1. Principles First—Engineering managers seeking to get the most utility from systems thinking should
lead with the foundational principles. There will always be new tools and techniques that emerge
to support systems thinking, as well as those that disappear. However, systems thinking, rooted in
systems philosophy and principles, will provide a sustainable foundation that will withstand the tests
of time.
2. Uniqueness, not Prescriptive Application—As the term suggests, systems thinking is largely about think-
ing in order to support alternative decision, actions, and interpretations. There is not a systems think-
ing prescriptive formula, approach, or universal method that can assure repeatable results for dealing
with complex system problems. Engineering managers must appreciate that every complex problem is
unique and exists in a unique context. Systems thinking can be helpful in exploring this uniqueness,
and perhaps, finding a path forward that might not have been recognized at other levels of thinking.
3. Framing to See Differently—Systems thinking invites engineering managers to explore complex situ-
ations in a way that allows for framing and reframing from a different perspective. Asking the most
fundamental systems questions about boundaries, relationships, and behavior serve to gain the ad-
vantages that different perspectives cannot bring to complex problems. Systems-based methodologies,
methods, and tools are simply devices to assist in seeing a complex problem domain differently.
4. Representations—Ultimately, systems based endeavors generate representations (models) of a situation.
Engineering managers must exercise caution in the construction and use of representations of sys-
tems. All representations are abstractions and can never fully capture the entirety of a complex system
(system darkness principle). Therefore, in the practice of systems thinking, engineering managers
should question limitations of a singular representation. The question becomes, why is this represen-
tation the most appropriate representation and what might alternative representations offer?
5. Problem Systems—Systems thinking invites engineering managers to engage a fundamental shift in
thinking about complex problems. The systems thinking assumption that a deficient behavior or per-
formance is produced by a system forces engagement at a different (systems) level of thinking. If we
312
 Systems Thinking

assume that behavior/performance is the product of an underlying system, modification of behavior/

performance must be achieved by adjustment in the underlying system, not adjusting the problem.
This is a fundamental shift in thinking, focusing on the system that produces the problem, not on
the problem.

Systems thinking is not a cure-all that can address all problems faced by engineering managers. How-
ever, it invites engineering managers to engage complex problems from a different level of thinking. In the
end, systems thinking may open a range of alternative decisions, actions, and interpretations.

18.10 References
Ackoff, R. L., Creating the Corporate Future, New York: Wiley, 1981.
Ackoff, R. L., Ackoff’s Best: His Classic writings on Management, New York: Wiley & Sons, 1999.
Ackoff, R., The Democratic Corporation, New York: Oxford University Press, 1994.
Ackoff, R., Re-creating the Corporation, New York: Oxford University Press, 2000.
Adams, K. M., Hester, P. T., Bradley, J. M., Meyers, T. J., and Keating, C. B., Systems theory as the foun-
dation for understanding systems. Systems Engineering, vol. 17, no. 1, 2014, pp. 112–123.
Argyris, C., and Schön, D. A., Organizational Learning: A Theory of Action Perspective, Reading, MA:
Addison-Wesley, 1978.
Argyris, C. and Schön, D., Strategy, Change and Defensive Routines, Cambridge, MA: Ballinger, 1985.
Argyris, C. and Schön, D., Organizational Learning II, New York: Addison-Wesley, 1996.
Bagni, G., “Sets, Symbols and Pictures: A Reflection on Euler Diagrams in Leonard Euler’s Tercentary,”
Mediterranean Journal for Research in Mathematics Education, vol. 5, no. 2, 2007, pp. 77-82.
Beer, S., Heart of Enterprise, Chichester: Wiley, 1979.
Beer, S., Brain of the Firm, Chichester: Wiley, 1981.
Beer, S., Diagnosing the System for Organizations, Oxford: Oxford University Press, 1985.
Bell, P. C., and O’Keefe, R. M., “Visual Interactive Simulation -- History, recent developments, and ma-
jor issues.” SIMULATION, vol. 49, no. 3, 1987, pp. 109-116.
Bertalanffy, L. V. General System Theory: Foundations, Development, Applications. New York: George Bra-
ziller, 1968.
Blanchard, B. and Fabrycky, W., Systems Engineering and Analysis. New York: Wiley, 1998.
Boardman, J. and Sauser, B., Systems Thinking: Coping with 21st Century Problems. Boca Raton, FL: CRC
Press, 2008.
Cabrera, D., Colosi, L., and Lobdell, C., “Systems thinking.” Evaluation and Program Planning, vol. 31,
no. 3, 2008, pp. 299-310.
Capra, F., The Web of Life, New York: Doubleday, 1996.
Checkland, P., Systems Thinking, Systems Practice, Chichester: Wiley, 1981.
Checkland, P., “Soft systems methodology,” in Rosenhead, J. (Ed.), Rational Analysis for a Problematic
World, Chichester: Wiley, 1989, pp. 71-100.
Checkland, P., “Soft systems methodology: A 30-year retrospective.” SystemsThinking, Systems Practice
(2nd ed.). Chichester: Wiley, 1999, A1–A66.
Checkland, P., “Soft Systems Methodology: A Thirty Year Retrospective,” Systems Research and Behavioral
Science, 17, 2000, pp. 11-58.
Chen, D. and Stroup, W., “General system theory: toward a conceptual framework for science and tech-
nology education for all.” Journal of Science Education and Technology, vol. 2, 1993, pp. 447-59.
Cherns, A. “The principles of sociotechnical design,” Human Relations, vol. 29, no. 8, pp. 783-92, 1976.
Cleland, D. and King, W., Management: A System Approach, New York: McGraw-Hill, 1972.
Clemson, B., Cybernetics: A New Management Tool. Abacus, Tunbridge Wells, 1984.
Daellenbach, H. G. and McNickle, D. C., Management Science: Decision Making through Systems Think-
ing, New York: Palgrave, 2005.
De Weck, O. L., Roos, D., and Magee, C. L., Engineering systems: Meeting human needs in a complex
technological world, Cambridge: MA: MIT Press, 2011.
313
Engineering Management Handbook

Eden, C. and Ackermann, F., SODA—The principles. Rational Analysis for a Problematic World Revisited:
Problem Structuring Methods for Complexity, Uncertainty and Conflict. J. Rosenhead and J. Mingers
(eds). Chichester: Wiley, 2001, pp. 21-42.
Edwards, A. W. F., Cogwheels of the Mind: The Story of Venn Diagrams, Baltimore, MD: The Johns Hop-
kins University Press, 2004.
Espejo, R., and Reyes, A., Organizational Systems: Managing Complexity with the Viable System Model,
Heidelberg, Germany: Springer Berlin / Heidelberg, 2011.
Fairhurst, G. and Star, R., The Art of Framing, San Francisco: Jossey-Bass, 1996.
Flood, R., Rethinking the Fifth Discipline, New York: Routledge, 1999.
Flood, R. and Carson, E., Dealing with Complexity: An Introduction to the Theory and Application of Sys-
tems Science, New York: Plenum, 1993.
Flood, R. and Jackson, M., Creative Problem Solving: Total Systems Intervention, London: Wiley, 1991.
Forrester, J., Industrial Dynamics, Cambridge, MA: MIT Press, 1961.
Forrester, J., Collected Papers of Jay W. Forrester, Portland, OR: Productivity Press, 1975.
Friend, J. and Hickling, A., Planning Under Pressure: The Strategic Choice Approach, Oxford, Pergamon,
1987.
Gharajedaghi, J., Systems Thinking: Managing Chaos and Complexity, Boston, MA: Butterworth-Heinemann,
1999.
Gibbons, M., Limoges, C., Nowotny, H., Schwartzman, S., Scott, P., and Trow, M., The New Production
of Knowledge, London: Sage, 1994.
Gibson, J., Scherer, W., and Gibson, J., How to do Systems Analysis, Hoboken: Wiley, 2007.
Graczyk, S. L., “Get with the system: general systems theory for business officials,” School Business Affairs,
59, 1993, pp. 16-20.
Haines, S. G., The Managers Pocket Guide to Systems Thinking, Amherst, MA: HRD Press, 1998.
Hammond, D., Exploring the genealogy of systems thinking. Systems Research and Behavioral Science, vol.
19, no. 5, 2002, pp. 429-439.
Hillier, F. and Lieberman, G., Introduction to Operations Research, 8th ed., New York: McGraw-Hill, 2003.
Hitchkins, D. K., Advanced Systems Thinking, Engineering and Management, Norwood, MA: Artech House, 2003.
Hoefler, B. G., and Mar, B. W., “Systems engineering methodology for engineering planning applica-
tions,” The Journal of Professional Issues in Engineering Education and Practice, 118, 1992, pp. 113-28.
Isaacs, W., Dialogue and the art of thinking, New York: Doubleday, 1999.
Jackson, M., “Beyond a system of systems methodologies,” Journal of the Operational Research Society, vol.
41, no. 8, 1990, pp. 657-668.
Jackson, M., Systems methodology for the management sciences, New York: Plenum Press, 1991.
Jackson, M., Systems Approaches to Management, New York: Kluwer/Plenum, 2000.
Jackson, M., Systems thinking: Creative Holism for Managers, Chichester: Wiley, 2003.
Jaradat, R. M., “Complex system governance requires systems thinking – how to find systems thinkers,”
International Journal of System of Systems Engineering, vol. 6, no. 1/2, 2015, pp. 53-70.
Katina, P. F., “Emerging systems theory–based pathologies for governance of complex systems.” Inter-
national Journal of System of Systems Engineering, vol. 6, no. 1/2, 2015, pp. 144-159.
Katina, P. F., “Systems Theory as a Foundation for Discovery of Pathologies for Complex System Problem
Formulation.” In A. J. Masys (Ed.), Applications of Systems Thinking and Soft Operations Research in
Managing Complexity (pp. 227-267). Geneva, Switzerland: Springer International Publishing, 2016.
Katz, D. and Kahn, R. L., The Social Psychology of Organizations, New York Wiley, 1978.
Keating, C., “Emergence in System of Systems.” In Jamshidi, M. ed. System of Systems Engineering –
Innovations for the 21st Century, Wiley, 2009, pp. 169-190.
Keating, C. B., and Katina, P. F., Systems of systems engineering: prospects and challenges for the emer-
ging field. International Journal of System of Systems Engineering, vol. 2, no. 2/3, 2011, pp. 234-256.
Keating, C. B., and Katina, P. F., Prevalence of pathologies in systems of systems. International Journal of
System of Systems Engineering, vol. 3, no. 3/4, 2012, pp. 243-267.
Keating, C. B., and Katina, P. F., Editorial: Foundational perspectives for the emerging complex system gov-
ernance field. International Journal of System of Systems Engineering, vol. 6, no. 1/2, 2015, pp. 1-14.
314
 Systems Thinking

Keating, C., Peterson, W., and Rabadi, G. “Framing of Complex System of Systems Engineering Prob-
lems,” Proceedings of the American Society for Engineering Management. St. Louis, MO, 15-18 October
2003, 2003, pp. 8-15.
Keating, C., Jacobs, D., Sousa-Poza, A., and Pyne, J., “Advancing Sociotechnical Systems Theory,” Pro-
ceedings of the American Society for Engineering Management, 2001, October 11-13, 2001, Huntsville,
AL, 2001, pp. 336-341.
Keating, C., “Research Foundations for System of Systems Engineering,” Proceedings of the IEEE Inter-
national Conference on Systems, Man, and Cybernetics, Waikoloa, Hawaii, October 10-12, 2005,
pp. 2720-2725.
Keating, C., Rogers, R., Unal, R., Dryer, D., Sousa-Poza, A., Safford, R., Peterson, W. and Rabadi, G.,
“System of Systems Engineering,” Engineering Management Journal: Special Issue on Systems Engineer-
ing, vol. 15, no. 3, 2003, pp. 36-45.
Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling and Controlling (10th ed.),
Hoboken, NJ: John Wiley and Sons, 2009.
Kim, D. H., Systems Thinking Tools, Cambridge: Pegasus Communications, 1995.
Klir, G. J., Architecture of Systems Problem Solving, New York:Plenum Press, 1985.
Lane, D. C. and Jackson, M. C., “Only Connect! An annotated bibliography reflecting the breadth and
diversity of Systems Thinking,” Systems Research, vol. 12, no. 3, 1995, pp. 217-228.
Maani, K. and Cavana, R., Systems Thinking and Modelling: Understanding Change and Complexity, Auck-
land: Prentice Hall, 2000.
Mason, R. and I. Mitroff., Challenging Strategic Planning Assumptions. New York, Wiley, 1981.
Maturana, H. R. and Varela, F. J., The Tree of Knowledge: The Biological Roots of Human Understanding.
Boston: Shambhala, 1992.
Meredith, J. and Mantel, S., Project Management – A Managerial Approach, New York: John Wiley &
Sons, 2000.
Midgley, G. Systemic Intervention: Philosophy, Methodology, and Practice. New York: Kluwer/Plenum,
2000.
Midgley, G., Response to paper “Systems thinking” by D. Cabrera et al., “The unification of systems
thinking: Is there gold at the end of the rainbow?” Evaluation and Program Planning, vol. 31, no. 3,
2008, pp. 317-321.
Miller, J. G. Living Systems. New York: McGraw-Hill, 1978.
Mingers, J. and Brocklesby, J., “Multimethodology: Towards a Framework for Mixing Methodologies,”
Omega, vol. 25, no. 5, 1997, pp. 489-509.
Mingers, J., Realising Systems Thinking: Knowledge and Action in Management Science. Canterbury, UK:
Springer, 2006.
Mitroff, I., Smart Thinking for Crazy Times: The Art of Solving the Right Problems. San Francisco, CA:
Berrett-Koehler, 1998.
O’Connor, J., and McDermott, I., The Art of Systems Thinking: Essential Skills for Creativity and Problem
Solving (illustrated edition.), Hammersmith, London: Thorsons, 1997.
Pasmore, W. A., Designing Effective Organizations: The Sociotechnical Systems Perspective. New York: Wiley, 1988.
Pollack, J. “Pyramids or Silos: Alternative Representations of the Systems Thinking Paradigms.” Systemic
Practice and Action Research, vol. 19, no. 4, 2006, pp. 383-398.
Richmond, B., “Systems thinking: critical thinking skills for the 1990s and beyond.” System Dynamics
Review, vol. 9, no. 2, 1993, pp. 113-133.
Richmond, B. The Thinking in Systems Thinking: Seven Essential Skills. Waltham: Pegasus, 2000.
Rittel, H. and Webber, M., “Dilemmas in a General Theory of Planning.” Policy Science, vol. 4, 1973,
pp. 155-169.
Sage, A. Systems Engineering. New York: Wiley, 1992.
Senge, P. M., The Fifth Discipline: The Art and Practices of the Learning Organization. London: Random
House, 1990.
Senge, P. M., Roberts, C., Ross, R. B., Smith, B. J. and Kleinter, A., The Fifth Discipline Fieldbook: Strat-
egies and Tools for Building a Learning Organization. New York: Doubleday, 1994.
315
Engineering Management Handbook

Simon, H., The Sciences of the Artificial. Cambridge, MA: MIT Press, 1969.
Skyttner, L., General Systems Theory: An Introduction. Philadelphia, PA: Trans-Atlantic, 1996.
Sousa-Poza, A., Kovacic, S. and Keating, C., “System of systems engineering: an emerging multidisci-
pline,” Int. J. System of Systems Engineering, vol. 1, no. 1/2, 2008, pp. 1–17.
Taylor, J. C., and Felten, D. F., Performance by Design: Sociotechnical Systems in North America. Englewood
Cliffs, NJ: Prentice-Hall, 1993.
Tracy, L. Leading the Living Organization: Growth Strategies for Management. London: Quorom Books,
1994.
Trist, E. L., and Bamforth, K. W., Some Social and Psychological Consequences of the Longwall Method
of Coal-Getting: An Examination of the Psychological Situation and Defences of a Work Group in
Relation to the Social Structure and Technological Content of the Work System. Human Relations,
vol. 4, no. 1, 1951, pp. 3-38.
Ulrich, W., Critical Heuristics of Social Planning: A New Approach to Practical Philosophy. Berne: Haupt,
1983.
Ulrich, W., Critical Heuristics of Social Systems Design. Critical Systems Thinking: Directed Readings. R.
Flood and M. Jackson. Chichester: Wiley, 1991, pp. 103-115.
von Bertalanffy, L., “The history and status of general systems theory.” Academy of Management Journal,
vol. 15, no. 4, 1972, pp. 407-426.
Waring, A., Practical Systems Thinking. London: Thompson, 1996.
Weick, K., Sensemaking in Organizations. Thousand Oaks, CA: Sage, 1996.
Williams, G., Chaos Theory Tamed. Washington, DC: Joseph Henry Press, 1997.

316
 Risk Management

19
Risk Management

C. Ariel Pinto
Old Dominion University

Luna M. Magpili
Washington State University

317
Engineering Management Handbook

19.1 Introduction

19.1.1 What Are Risks, Hazards and Accidents?

Take calculated risks. That is quite different from being rash.

- George S. Patton
US Army General (1885 - 1945)

Engineering managers are the leaders toward successful research, development, and engineering activi-
ties. And monuments of these successes abounds—discoveries of drugs that saves millions of lives, taming
and harnessing nuclear power for energy, design and execution of space exploration programs, and count-
less other feats. But within these same realms exist monuments of apparent failures—disastrous chemical
spills, deadly space shuttle launch, catastrophic flood levee failures, and so on. Would have Gen. Patton
considered these failures the result of calculated risks? Or are these failures remnants of human rashness?
At the heart of this section is the science and art of managing risks in engineering systems. Critical to
managing risk is in knowing what it is. Some have described risk as…

“…the potential for realization of unwanted, adverse consequences”

– Society for Risk Analysis

“… (perceived) feeling of insecurity and fear due to undesirable consequences”

– Organization for Economic Co-operation and Development

“…probability of the occurrence of (the risky) event multiplied by the consequence of the event, given
that it has occurred”

– US Army Corps of Engineers

“…are events that if they occur can jeopardize the successful completion of the projects”

– INCOSE

As the preceding descriptions of risk show, an engineering manager must recognize that risk can be
expressed as a number (i.e. quantitative) and also may reside in the minds or feelings of humans (i.e.,
qualitative). Whatever description of risk is adopted by the engineering manager, one thing that is gener-
ally agreed upon is that risk, in itself, is undesirable.
Two distinct terms related to risk are accidents and hazards. Accidents commonly refer to events that
are not intended to happen. As an example, a fender bender between motor vehicles is an accident be-
cause it is generally unintended. In contrast, a fender bender during a demolition derby is not an accident
because it occurs with intent. Hazards usually refer to objects, actions, processes, or condi¬tions that
may contribute toward the occurrence of an accident. A motorist texting while driving is an example of
a hazard. This specific condition of the motorist may contribute toward the occurrence of an accident, a
fender bender. However, note that the existence of the hazard itself does not automatically cause an acci-
dent. Still, the presence of hazards increases the likelihood of an accident occurring. Risk relates these two
concepts together, as characterizing risk is often done in terms of likelihood and consequence.

318
 Risk Management

19.1.2 Why is Managing Risk Important for Engineering Managers?

Being true to the engineering manager’s goal, the rigors of the discipline are full of hows and whys
of having a successful engineering activity. By managing risk, the what ifs are added to this list.
For example, one measure of success in constructing a system of flood levees is the protection it provides
to the population and their properties. Engineers will use the appropriate levee heights to protect against a
particular design flood level, say a 100-year flood. The engineer may design, build, and operate the levees.
However, the same engineer, in doing some basic risk management, may reconsider some previous design,
after considering: What if the current land use plan around the levee changes? What if the current hydro-
logical models are proven wrong? Or, what if drastic climate change occurs?
It may turn out that these what ifs will not change the decisions made about the levees. However,
as Gen. Patton said, there is a quite a difference between taking calculated risk and being rash. And for
engineering managers, the difference between well and poorly managed risks could very well be in terms
of lives lost, property damage, and economic cost.

19.1.3 What is Risk Management?

The management of risk permeates many activities, especially those that involve systems of great value.
It can be an informal process without any set guidelines, or an institutionalized and codified activity. Re-
gardless of the specifics of activities or degree of formalization, applications of risk management have one
common objective: To minimize loss associated with a system in case things go wrong.
Effective risk management is often undertaken concurrent with design and development processes. As
systems are transformed from mere concepts to full-scale entity, risks arise and need to be managed in a
timely manner. As a result, safeguards against risk are often designed and built into the system. As the old
adage goes, an ounce of prevention is worth a pound of cure.
In the realm of formalized risk management, there are several guiding principles:
Analysis of risk is preceded by a system analysis—Recognizing goals and objectives of a system and ele-
ments that make up the system helps determine events to be considered as undesirable, and hence a risk
(Pinto, Magpili, and Jaradat, 2015). Understanding the sequence of events that may eventually lead to the
risk is the result of knowing how various elements of the system are interrelated. This recognition of se-
quence of events is important in managing the risk in terms of its chance of occurrence and consequences.
Managing risks requires some degree of control on how elements of a system will behave or relate to each
other and which may be considered as environment and is subject to limited to no control.
Analysis of risk is scenario-driven—Analysis of risk is only possible if we can conceptualize such risk.
Examples are floods for a levy, fires for homes, and defective parachutes for a sky-diver. This implies that
risk analysis is limited by our capacity to identify what can go wrong, which are termed risk scenarios or
simply scenarios. Consequently, before we can conceive the scenarios, we must first have an idea of the ide-
al events. Certainly, the ideal events are that there be minimal floods, no house catches fire, and parachute
opens properly. The identification of varied and meaningful scenarios requires extensive knowledge of the
system at hand: how it works, how it was built, how it will be used, and other information. For complex
systems, models are often used to facilitate the identification of scenarios—and yet there will always be
emerging scenarios which will slip identification. Moreover, identification of scenarios is often done by
teams of people with diverse knowledge about the system and its environment, effectively resulting to a
wider realm of knowledge. Due to the enormous number of possible scenarios, ranking and filtering of
scenarios are often performed to protect the most valuable of assets.
Importance of catastrophic events—A person often remembers catastrophic events more than
the usual, everyday events. And this is for a good reason: catastrophic events are usually associated with
great loss. These are the same type of scenarios that are of special interest in risk management. For a civil
engineer with a 10-foot levy, a drought or a 5-foot flood is not much of a concern. But the scenario of a
12-foot flood is critical. This scenario will result in flooding at the other side of the levy, or even the top-
pling of the entire levy even though this particular event may happen only once in a century. In general,
designers assure that systems do well on a wide scale of events. However, there are types of events, often
very rare and in only one end of the scale that can prove to be destructive.
319
Engineering Management Handbook

Catastrophic events can be capable of premature and unplanned retirement of a system. In the case of
a levy that was planned to be in operation for 50 years, a catastrophic flood on the first year can prema-
turely cut its affectivity, and the resources put into building the levy would not be recouped. In essence, if
much of the decisions that went into building the system were based only on long-term projections (e.g.,
averages), then the early retirement of a system voids much of these decisions.

19.1.4 What Are the Basic Activities in Risk Management?

Risk management is made up of several activities, one leading to the other. Oftentimes, we need to go
through the activities several times to produce a more detailed management of risk from the previous
time. This section provides a general framework for risk management to enable engineering managers to
conceptually structure the volumes of topics available on risk management, as well as to serve as guidelines
for managing risks in various types of engineering systems. The framework presented herein is an amalga-
mation of several frameworks for risk management scattered among bodies of knowledge, but resembles
closely those presented by Haimes (2004) and Conrow (2005), Pinto and Garvey (2012), Pinto, Magpili
and Jaradat (2015), PMBOK, and others. These activities are as follows:

(1) Scenario identification starts out by identifying the system of concern, which elements are within our
control and which are not. We then draw a description of the ideal picture when everything about the
system works and operates as planned (what should go right). Correspondingly, we conceptualize the risk
scenarios- what can happen that will prevent the system to work and operate as planned (what can go
wrong). It is important that we consider the system from various points of views (one who owns it, one
who uses it, one who is affected by it, etc.).
We then identify the causes of each possible risk scenario. This is done by looking into events and
conditions that transpire prior to the occurrence of a scenario and their potential role to the occurrence of
the scenario. Establishing what causes accidents, risk scenarios/ risk events, or any type of events in gener-
al can be termed as establishing the causal chain of events. The use of the notion of a chain is a metaphor
for how events form distinct links that together form a continuous span.
The scenario identification activity is meant to answer three primary risk questions:
• What should go right?
• What can go wrong (i.e. risk scenario/ events)?
• What causes the risk scenario/ events?

(2) Consequence estimation and likelihood estimation are based on the risk scenarios that were previously
identified. Also extending the concept of the causal chain of events, we estimate the consequences of each
scenario by looking into other events that may transpire in the aftermath of the identified risk scenario.
Ideally we seek to assess as much of the impact of the many possible outcomes and cascading effects that
can happen.
Likelihood estimation is also based on the scenarios previously identified. Ideally, the frequencies of
the occurrence of each scenario and their causes are estimated, possibly based on the known causal chain
of events. This can be done by looking into the mechanism of the scenarios and the factors that contrib-
ute to their occurrence. Here we can go back to the concepts of hazards and accidents as potential causal
chains. A driver texting (hazard/ causal event) increases the likelihood of a fender bender (risk event). This
activity is meant to answer two primary risk questions:
• What are the consequences of the risk events?
• What is the likelihood of occurrence?

(3) Ranking. At this point, we have a good description of the risks in terms of the risk scenarios, their causes,
consequences and frequency of occurrence. We may decide to take a second look into the list of these scenar-
ios and make distinctions between the more important and less important ones based on their consequence
and frequency, as well as possibilities for their detection, control, and management. The purpose of such
ranking of scenarios is to concentrate our resources on the more important ones that are achievable. It is
320
 Risk Management

worth noting that many of these risks are not independent of each other. That addressing one risk may have
a positive (or negative) impact on another risk. This activity is meant to answer the risk question:
• What can be done to detect, control, and manage the risk events?

(4) Generation and tradeoff of alternatives identifies ways and costs to mitigate each of the risk scenarios.
Responses to address risk can be in the form of affecting the causes of a scenario (e.g. safeguard), minimiz-
ing consequences of a scenario, transferring the risks, or a combination of these. In essence, this activity
answers the risk question:
• What are the alternatives to manage the risk events?

(5) Potential problem analysis evaluates the effects of the mitigation alternatives to other elements of the
system. Alternatives are analyzed according to their effects to the functionalities of the system, the man-
ner by which they alter interaction between elements of the system, and their potential to affect future
decisions. This is also the point where the acceptable level of risk is determined, comparing the costs and
benefits of each alternative by answering the risk question:
• What are the effects beyond this particular time?

(6) Implementation, monitoring, and documentation is putting into place recommended actions based on
the perceived acceptable level of risk. There is no clear terminal activity in risk management as it is an
iterative process. As stated in the previous section, it is difficult to totally eliminate risk as new sets of
scenarios come up every time there are changes in the system, the environment, or in the presence of new
information. This activity answers the risk question:
• How well are the risks being managed?

This framework, illustrated in Figure 19.1, was formulated with engineering managers in mind and
with consideration toward perceivable trends in risk management tools and techniques. The following
sections discuss these steps in details.

Figure 19.1. Schematic of the Activities in the Risk Management Framework

Scenario Consequence Ranking Generation and Potential Problem Implementation,

Identification Estimation Tradeoff of Analysis Documentation,
Likelihood Mitigation and Monitoring
Estimation Alternatives

Risk scenarios Ranked list Alternatives List of Risk

List of risk with consequence of risk for some risk other risks documentation
scenarios and likelihood scenarios scenarios
estimates

19.2 Scenario Identification

This section describes the first question that needs to be answered toward managing risk—what can go
wrong?—also known as risk scenario identification. This question arises from the fact that for risks to be
managed, risks scenarios need to be identified and described to an appropriate level of detail. The answers
to this question are greatly hinged on describing the goals and performance measures for a particular engi-
neering activity. In essence, the answers to the question: what should go right? There can be three phases to
identifying risk scenarios, namely:
1. Identify desired scenarios
2. Identify undesirable or risk scenarios
3. Characterize risk scenarios via causalities and correlation
321
Engineering Management Handbook

19.2.1 Identify Desired Scenarios

The identification of desired scenarios is a common and fundamental activity in any engineering and
managerial effort and not just in risk management. This activity is mostly couched under the names
requirement identification, functional design, goal formulation, performance measure identification, and other
related activities. As such, information on desired scenarios lies in documents like requirement contracts,
product or process specifications, mission and goal statements, and others. Consider these examples:
• Total cost of developing a new engine should not exceed $3M
• Maximum sustained torque should be at least 700 foot-pound
• A prototype of the engine should be available for field testing in 18 months

These desirable scenarios are obviously oversimplified but are representative of various types of objec-
tives for an automotive engine engineering activity representing cost, performance, and schedule goals.

19.2.2 Identify Risk Scenarios

The identification of the undesirable or risk scenarios are initially drawn from the previously identified
desirable scenarios. Strictly described, the undesirable scenarios are everything else aside from the desir-
able scenarios—analogous to the notion of complementary sets in set theory. Consider the three desirable
scenarios listed in the previous section. The broadest risk scenarios are the following complementary
scenarios:
• Total cost of developing a new engine exceeds $3M
• Maximum sustained torque is less than 700
• A prototype of the engine is not available for field testing in 18 months

19.2.3 Characterize Risk Scenarios Via Causalities and Correlation

What causes the risk scenario/ risk events? – The characterization of risk scenarios are meant to explore
events that cause or contribute toward the occurrence of these risk scenarios. The process of character-
ization draws from various fields of science and engineering such as reliability and maintainability and
survivability analyses and requires a thorough and possibly specialized knowledge of particular engineer-
ing systems. Consider the first of three risk scenarios from the previous section: Total cost of developing
a new engine exceeds $3M. With more specialized information of engine development in the automotive
industry, some immediately identifiable causes of this scenario are:
• Devaluation of US$ compared with the Euro (for subcontracted services to European firms)
• Set back in the R&D for new aluminum alloy for the engine block
• New contract with the labor union and significantly higher labor cost rate

The list of possible causes for cost overrun will be much longer in reality, but for the purpose of ex-
ample, let us assume for now that the list of three causes is an exhaustive list. Several tools and techniques
can be used in establishing causalities of risk scenarios: Preliminary Hazard Analysis (PHA), Job Safety
Analysis (JSA), Failure Mode and Effects Analysis (FMEA), and Fault Tree Analysis (FTA). It should be
noted that the tools below also extend beyond scenario identification and cover the other activities of risk
management namely, consequence and likelihood estimation, ranking, and generation of recommenda-
tions.

Preliminary Hazard Analysis (PHA)

A PHA is a semi quantitative approach used to develop an initial listing of potential hazards, hazardous
situations, and hazardous events. The emphasis in a PHA is the breadth of identifying all possible and
conceivable hazards. It is thus a broad appraisal of risk events and is typically done early in a product or
system development phase or during a project’s very early stages of conceptualization. Variants of PHA are
Preliminary Risk Assessment (PRA), Rapid Risk Ranking, or Hazard Identification (HAZID).

322
 Risk Management

An example of a PHA worksheet is shown in Table 19.1. The following are the descriptions of col-
umns that correspond to the PHA worksheet shown in Table 19.1.

What can go wrong?

Column 1: Hazards that may lead to an accident
What are the causes and consequences?
Column 2: Accidents that can occur from the hazards
Column 3: The potential causes that can bring about each accident
What are the likelihood or chances of occurrence?
Column 4: The likelihood that a particular cause triggers the accident
Column 5: The severity of the consequences if the accident occurs
Column 6: The risk score based on the likelihood information entered in Column 4 and the severity
information entered in Column 5
What can be done to detect, control, and manage the risks?
Column 7: Recommended preventive and control measures to address the hazards, the causes, and
their consequences

Table 19.1. PHA Worksheet

System: elevator Description: Analyst date:

door
# (1) Hazards (2) Accidents (3) Potential (4) Likelihood (5) Severity (S) (6) Risk score (7) Possible
causes (L) Rating scale Rating scale controls,
preventive
actions, mitigation
<What are <What could <How might <What are <How signif- L × S <Rank- <What can be
the possible be the harm of the accident the likelihood icant is the ing> done>
hazards> the hazard> occur> or chances of harm>
occurrence>

Job Safety Analysis (JSA)

A PHA is a semi quantitative approach used to develop an initial listing of potential hazards, hazardous
situations, and hazardous events. The emphasis in a PHA is the breadth of identifying all possible and
conceivable hazards. It is thus a broad appraisal of risk events and is typically done early in a product or
system development phase or during a project’s very early stages of conceptualization. Variants of PHA are
Preliminary Risk Assessment (PRA), Rapid Risk Ranking, or Hazard Identification (HAZID).
A JSA is a qualitative technique used to identify and control workplace hazards to prevent accidents.
In a JSA, each basic step of the job is examined to identify and address potential hazards. The aim is to
recommend the safest way to do a job. It focuses on the relationship between the worker, the task, the
tools, and the work environment. Variants of JSA are job hazard analysis (JHA) and task hazard analysis
(THA).
The following are the descriptions of columns that correspond to an example of a JSA worksheet
shown in Table 19.2. The JSA worksheet is intended to be completed one column at a time. It follows
only two of the key risk questions:

What can go wrong?

Column 1: Job steps or tasks
Column 2: Hazards or unwanted events related to each task
What are the causes and consequences?
What are the likelihood or chances of occurrence?
Omitted in JSA

323
Engineering Management Handbook

What can be done to detect, control, and manage the risks?

Column 3: Prevention and control measures for each hazard
Column 4: Person responsible for the prevention or control measure

Table 19.2. JSA Worksheet

Department: Job analyzed: Performed by: Date:

Supervisor:
Location: Started:
Analysis by: Completed:
Reviewed by:
Approved by:
Required personal protective and emergency equipment:

(1) Sequence of basic job
steps
<List the tasks that required
to perform the activity in the
sequence they are carried
out>
(2) Potential accident or
hazards
<Per task, list the hazards
that could cause injury when
the task is performed>
(3) Control or prevention
measures
<Per hazard, list the control
measures required to
eliminate or reduce the risk
of injury arising from the
hazard>
(4) Person responsible
<Per control measure, identify
the person responsible to
implement the control or
prevention measures>

Failure Mode and Effects Analysis (FMEA)

FMEA is a top-down quantitative technique applied to identify failures in a design, a process, a system, or
an existing product, equipment, or service. FMEA is used to analyze elements or components of a system,
their interactions, and their effects on the operation of the system as a whole. The term failure modes per-
tains to ways in which functional elements may fail. The term effects analysis describes the consequences
of those failures and any existing prevention or control measures in place to address them. Thus, FMEA
similar to HAZOP also examines how existing system capabilities detect failures and manage such failures.
Correspondingly, risks are ranked based on the likelihood and consequences of failure, as well as the
current system’s ability to detect and manage failure if they do occur. Similar to PHA and unlike HAZOP
and JSA, FMEA further assesses the likelihoods of occurrence of these failures.
The FMEA worksheet generally follows the key questions of the risk management process. Very no-
tably, the precursory question: What should go right? is posed first. The following are the descriptions of
columns that correspond to an example of a FMEA worksheet shown in Table 19.3.

What should go right?

Column 1: Functional objectives of the subsystem or component
What can go wrong?
Column 2: Failure modes that prevents the achievement of objectives
What are the causes and consequences?
Columns 3: Consequences of failure (labeled effects in the FMEA worksheet)
Columns 4: Severity (S) of the consequences
Columns 5: Potential causes of failure
What are the likelihood or chances of occurrence?
Column 6: Likelihood (L) of each causes or failure (labeled occurrences in the FMEA worksheet)
What can be done to detect, control, and manage the risks?
Column 7: Existing detection, prevention, and control measures
Column 8: Rating for existing detection (D), prevention, and control measures
Column 9: The risk score determined by the likelihood, severity, and effectiveness of existing
detection, prevention, and control measures to address failure, evaluated as L × S × D
Column 10: Recommendations for additional prevention and control measures to address the
failures, their causes, and consequences
324
 Risk Management

Table 19.3. FEMA Worksheet

FMEA Item No.: 1.8 Item Description:

Date:
(1) (2) (3) (4) (5) (6) (7a) (7b) (8) (9) (10)
Function Potential Potential Severity Potential Occurrence Current Current Detection RPN Recommended
or process failure effect(s) of (S) cause(s) of rating (L) design design rating (D) action(s)
modes failure failure controls controls
(prevent) (detect)
<What can <What <What <How <How can <What is the <What are <What are <How L×S×D <What can be
go right, are the is the significant the failure likelihood of in place so in place so effective done>
what is ways that consequence is the occur> occurrence> that failure is that failure is are the
supposed prevent of the impact> prevented> controlled> measures>
to the failure>
happen> process or
function to
achieve its
objective>

Fault Tree Analysis (FTA)

Fault Tree Analysis (FTA) is a tool commonly used for reliability and safety analysis that was originally
developed by Bell Telephone Laboratories in the 1960s for the U.S. Air Force for use with the Minute-
man system, and was later adopted by the Boeing Company and has since been used by other countless
organizations.
The usefulness of FTA in establishing causalities of risk scenarios is due to several characteristics,
namely:
• Its nature of working in the failure space facilitate identification of risk scenarios
• Looks at combinations of failures, suitable to wide range of complexity of many engineering activity
• Symbolic use of events blocks and gates, enabling user-friendly and compact visualization of an other-
wise complex information (see Table 19.4)
• Readily available as a software application, enabling quick adoption

Shown in Table 19.4 are the common symbols used in FTA. This includes symbols for events and for
Boolean operators or gates.

Table 19.4. Basic FTA Symbols

FTA symbols Common name Description

Basic event A basic initiating fault or failure event
External event An event that is normally expected to or not to occur
Undeveloped event A basic event that needs to further details or resolution
Conditioning event A specific condition or restriction that applies to a gate
Transfer Indicates continuation or transfer to a sub-tree

AND gate Output event occurs if ALL input events occur

Output event occurs if at least one of the input events
OR gate
occurs

Consider as an example, the possible causes for the scenario described as Total cost of developing a new
engine exceeds $3M from the previous section. The identified causes can be illustrated using FTA as shown
in Figure 19.2.

325
Engineering Management Handbook

Figure 19.2. Simplified FTA Showing How Causalities of Risk Scenarios Can Be Represented by Events and
Gate Symbols

Total cost of
developing a new
engine exceeds
$3M

OR

Devaluation of Set back in the

US $ compared R&D for new AND
with the Euro aluminum alloy for
the engine block

New contract with Significantly higher

the labor union labor cost rate

19.3 Consequence and Likelihood Estimation

This section describes the second activity in the seven-activity risk management framework. The previous
section discussed how risk scenarios can be identified and described at a suitable level of details. However,
this list of risk scenarios has to be scrutinized in preparation for proper management. The ever-present
limitation in available resources necessitates that engineering managers distinguish the more important
from the trivial risk scenarios for proper resource allocation. The general approach to distinguishing the
relative importance of risk scenarios is by describing their chance of occurrence and consequence if they
occur. This approach is loosely derived from the notion of expected value as well as risk itself, e.g., as
described by the US Army Corps of Engineers in Section 1.0.

19.3.1 Consequence Estimation

Consequence estimation, the first component of this section, draws from various activities such as cost
estimation and analysis, cost engineering, and actuarial analysis—essentially estimating the cost of events
that will happen if a particular risk scenario occurs. Similar to all cost-related analyses, consequence estima-
tion is highly dependent on how clearly defined and understood is a particular risk scenario. For clearly
defined and understood risk scenarios, estimating the consequence may be based on historical cost data
using statistical analysis very similar to actuarial analysis performed in the insurance and finance industry.
However, the more challenging cases for engineering managers are the one-of-a-kind, untested, and
complex systems where the risk scenarios are neither well defined nor understood. These cases are better
approached from a stochastic perspective, which essentially brings the engineering manager to the second
component of this section, likelihood estimation.

19.3.2 Likelihood Estimation

There are several ways risk managers can estimate likelihood or chance. From a statistician and mathema-
tician’s perspectives, this may be the frequency of outcome of repetitive experiments or may be a formal
mathematical function usually represented as a curve. From a Bayesian’s perspective, this may be the de-
gree of confidence or certainty. There are cases when one of these perspectives is more appropriate over the
other, such as the presence or absence of historical data regarding a particular risk scenario and its causes,
or the knowledge or lack thereof.
The example of Figure 19.3 shows how probabilities can be linked to damage estimation. The prob-
abilities of fire, detection working, alarm working, and sprinkler working can be derived from incidence
326
 Risk Management

data for the frequency of occurrences of fire and manufacturer information on the fire detection, alarm,
and sprinkler system.

Figure 19.3. Estimating Probabilities of Damages

Statistical-Mathematical Risk Assessment

To describe the likelihood of a risk scenario, traditional data analysis can be used by adapting statistical
and mathematical approaches. These approaches are especially useful in cases when the likelihood of oc-
currence can be expressed in terms of statistics such as mean, variance, skewness, range, etc., or probabili-
ty distributions such as the Normal distribution or non-parametric distributions. Oftentimes, traditional
data analysis for managing risk essentially becomes a task of how to specify probability distributions. For
fairly defined and understood phenomenon, the probability distributions may be assumed via this very
knowledge, such as the use of a Uniform distribution for possible results of rolling of a dice or sequential
coin tosses. For less understood phenomenon but with empirical data, parametric and non-parametric
statistical methods can be used. In-depth discussion of traditional data analysis is in the chapter on proba-
bility and statistics of the ASEM Handbook.
In this chapter, more emphasis will be on the discussion of non-traditional risk assessment appro-
priate for cases where there is less information or knowledge of risk scenarios. Particularly, Bayesian or
evidence-based assessment and assessment of extreme and rare events will be discussed.

Bayesian or Evidence-Based Assessment

Briefly described in the previous section is the role of statistical data analysis in establishing the chance of
occurrence of risk scenarios using knowledge of the phenomenon and empirical data. However, there are
cases in engineering activities where knowledge of risk scenarios may be poor or that there is hardly any
data, such as in the case of a new and emerging technology or newly studied phenomenon. Instead, there
may be well-established evidences, whether by causality or correlation to describe these risk scenarios. The
Bayesian approach, also known as evidence-based risk assessment can be useful for such cases.
Evidence-based analysis is primarily based on two axioms, Bayes’ theorem and total probability theo-
rem, respectively described in Equations 19.1 and 19.2.

P (A) P (B |A )
P ( A|B ) = (19.1)
P (B )
327
Engineering Management Handbook

P(B) = P(B|A1)P(A1) + ... + P(B|An)P(An), (19.2)

In this analysis, carefully selected information that helps draw conclusions or evidences are of primary
interest.

19.4 Risk Ranking

The previous section described how the consequences and the likelihood of risk scenarios can be esti-
mated. The estimation of these consequences and likelihood of risk scenarios help engineering managers
discern the relative risk of these scenarios for the purpose of eventually allocating limited resources toward
their mitigation. However, risk scenarios have other properties that can be expressed in numbers, much
less encompassed by its consequence and likelihood.

19.4.1 Risk Ranking Using Consequence and Likelihood

There can be several ways to rank risks using consequence and likelihood. One approach is to calculate the
product of the consequence and likelihood for each of the scenarios and treat this product as a unit-less
measure of risk. That is:

Risk of a scenario = (Likelihood of occurrence * Consequence if it occurs)

The ranking among several scenarios can then be based on this calculated risk measure where high-
er number denotes higher risk. However, it is important to note that there has been counter argument
against this method because of the equivalence that may result from scenario of low likelihood and great
consequence with that of one with great likelihood and low consequence.
A related approach is the use of a risk matrix or risk cube where each scenario is placed on a two-di-
mensional matrix where the axes represent likelihood and consequence, as shown in Table 19.5. In this
example, the estimated consequences are expressed as Severity, which ranges from Negligible to Cata-
strophic, while the likelihood is expressed as Probability, which ranges from Improbable to Frequent. This
example also shows how the ranking can be made, from the lowest, moderate to high risk.

Table 19.5. Example of Risk Matrix to Rank Risk Scenarios Based on Consequence and Likelihood

SEVERITY
Catastrophic Critical Marginal Negligible
Frequent
PROBABILITY

Probable High
Occasional Low Low Medium Medium
Remote
Improbable

19.4.2 Risk Ranking Using Other Properties

Haimes, Kaplan, and Lambert (2002) described some other properties that can be used to better describe
and eventually rank risk scenarios. Some of these properties shown in Table 19.6, as well as some explor-
atory questions engineering manager can use to better describe risk scenarios. These queries are useful to
start thinking about – What can be done to detect, control, and manage the risk events?

328
 Risk Management

Table 19.6. Exploratory Questions That Can Be Used to Describe Risk Scenarios

Properties Exploratory questions, and why the property is important in risk ranking.

How is it detected? What is the likelihood that it occurs without being

Undetectability detected (i.e., false-negative)? A seemingly benign but undetected risk can escalate
in magnitude and scope, e.g., a small gas leak turning into an explosion.
Uncontrollability/ Once detected, how soon and how much will it take to be controlled to avoid
further damage? Some risk scenarios, once triggered may be difficult or costly to
Irreversibility control or terminate, e.g., lose of cabin pressure during high altitude flight.
How many ways are there for it to occur? How much is known about these
Multiple paths to failure paths to failure? Likelihood of occurrence may be grossly under estimated if it is
know that there are other unaccounted causes.
How long does it or its effects last? Depending on the method used for estimation,
Duration of effects consequence may escalate beyond the estimate if the effects last longer than
foreseen.
Will it result to other risky scenarios? What may initially be a benign scenario
Cascading effects may actually be just one of several contributing to a catastrophic event, e.g., freezing
of an o-ring before a space shuttle launch.
Hardware/software Does it involve interaction among several types of system components?
/human/organizational Scenarios due to interaction of seemingly reliable components may actually result to
interaction higher likelihood than initially estimated.
Is it attributed to complexity or emergent behavior? Complexity and emergence
Complexity and emergent
denotes significant level of uncertainty, such that estimated likelihood and
behaviors
consequence may be underestimated.
How much is know (or unknown) about pertinent systems? Immature design,
Design immaturity
similar to complexity and emergence may have high degree of uncertainty.

19.5 Generation and Tradeoff of Mitigation Alternatives

19.5.1 Mitigation Strategies
Once the critical risks are identified, this activity involves the exploration of the many ways a particular
risk can be addressed. We extend the question of What can be done to detect, control, and manage the
risk events? to looking at What are the alternatives to manage the risk events? The primary objective of
risk mitigation strategies is to reduce the risk. In identifying risk mitigation alternatives, several concepts
need to be introduced:
• Vulnerability—openness to damage; usually inherent to the system of interest
• Threat—potential cause of system damage; usually external to the system of interest
• Security—measures taken to guard against damage
• Safety—relative protection from adverse consequences; usually associated with life and health

These concepts are the building blocks of almost any risk mitigation alternatives. Based on these
building blocks, the following questions can be asked to facilitate the generation of alternatives.
• How can vulnerabilities be removed or reduced?
• How can threats be removed or reduced?
• How can consequences be reduced?
• How can consequences be transferred?
Most likely, a risk mitigation alternative will address combinations of the above questions at varying
degrees. It is worth to note that by addressing the vulnerabilities and threats, the likelihood of the risk
scenario is essentially reduced. At this point, one is confronted with the decision to select between the
alternatives. The principle of As Low as Reasonably Practicable (ALARP) is discussed next.
329
Engineering Management Handbook

19.5.2 As Low As Reasonably Practicable

The ALARP principle supports the notion that residual risk shall be as low as reasonably practicable. In
ALARP, “reasonable practicability” involves weighing a risk against the benefits. And “low” suggests a
reduction of risk to a level wherein the benefits arising from further risk reduction are disproportionate
to the time, cost, and technical difficulty of implementing further risk reduction measures. For example,
is it worth to spend $30 on a bicycle helmet to gain an 88 percent reduction in the risk of severe brain
injury from riding a bike? If one chooses to make the investment, then one chooses to reduce the risk
to this ALARP level. In this case, the benefit of a reduction of risk from a bike injury is worth (or even
outweighs) the cost and effort of $30 and a trip to the store. Thus, the risk of injury from biking with-
out a helmet is not ALARP. While, the reduction of risk from biking with a helmet achieves a risk that
is ALARP. Note that even with biking with a helmet and its corresponding risk reduction, the risk from
biking is still not totally eliminated.
Conceivably, one can choose not to go biking at all, which would theoretically even further reduce
the risk of head or brain injury from biking to zero. But does one forgo the exercise and entertainment
provided by biking against this risk reduction of not engaging in the activity? Those who like biking will
conclude that this particular risk reduction is not ALARP. The benefit is not worth the cost (of not expe-
riencing the joys of bicycling). However, one can argue that there will be extremes, the few who choose
not to go biking because of the risk. For them, the choice not to go is ALARP. As can be inferred, ALARP
tends to be relatively defined, inherently subjective, and value laden.
The carrot diagram in Figure 19.4 illustrates the ALARP approach and is often used to display levels
of risk. The term carrot diagram comes from its appearance as an elongated triangle, which looks like a
carrot. At the top are the high (normally unacceptable) risks. Risks that fall in the unacceptable region
must be reduced regardless of cost, except in extraordinary circumstances. These risks are definitively not
at ALARP levels. They characteristically include those risks that may lead to death or disability. An exam-
ple of a risk in this region is not outfitting a car with seatbelts and airbags or window washing in skyscrap-
ers without harnesses. As can be expected, many risks that fall under unacceptable region are those that
are mostly controlled by laws, regulations, and codes. Industry practices are good references as well for
determining common preventive and control measures that achieve ALARP levels. Other significant risks
that should be identified in this region are those that may threaten the core mission of the organization.
Addressing these risks that are vital to the survival and sustainability of a business should be reduced at all
costs. The low risks fall at the bottom. These risks that fall in the broadly acceptable region are risks that
are tolerable. They are more likely to be at ALARP levels. For example, the risk of being pickpocketed is
so low that people do not feel the need to carry cash in separate pockets or hidden money belts. Similarly,
we manage slightly higher risks, such as crossing a neighborhood road by routine procedures (look left
and right) that we were taught as children. Looking before crossing the road reduces the risk to an indi-
vidual’s ALARP levels. Careful monitoring and attention must be done to ensure that risks in this region
remain at this level.

330
 Risk Management

Figure 19.4. Example of Risk Matrix to Rank Risk Scenarios Based on Consequence and Likelihood

If the costs are clearly very high and the reduction in risk is only marginal, then it is likely that the
situation is already ALARP and further improvements are not required. For example, is it worth to spend
$1 million to prevent 1 person in 500 getting a small bruise per year? If the answer is no, then the risk of
injury (bruise) of 1 person in 500 is deemed already low as reasonably practicable (at a level ALARP). The
benefit is not worth the cost and effort. The risk event of the bruise is tolerated. This risk falls in the low
risk acceptable region.
In other circumstances, the improvements may be relatively easy to implement and the risk reduction
is significant: Here, the existing situation is unlikely to be ALARP prior to the improvement, and thus
the improvement is performed (such is the case with the bicycle helmet example). In many of these cases,
a decision can be reached without further analysis. The difficulty is when the risk falls between the upper
and lower limits, the tolerable region, when the difference between the risk and the benefit are not grossly
disproportionate.
Comparative analysis tools such as those identified in the next section have been used to sup-
port these types of ALARP decisions. Decision-making models are also useful for supporting ALARP.
Multi-criteria decision making (MCDM) or multi-criteria decision analysis (MCDA) considers multiple
criteria other than cost. MCDM and MCDA are able to integrate factors that need not be assigned cost
valuations such as human life or environmental degradation. It allows criteria to preserve its intrinsic unit
of measure (e.g., mortality rate, pollution level). Nonetheless, even if cost conversion is circumvented, the
exercise of valuation (e.g., quantifying life) still exists in many decision-making models.

19.5.3 Comparative Analysis for Tradeoffs

Risk mitigation alternatives often have costs for implementation. This cost is not necessarily the monetary
and direct cost but can also be in the form of social and opportunity costs. There are a number of tools
to support engineering managers in comparing these alternatives. Some comparative analysis tools for
decision support are:
• Life cycle assessment (LCA) is a method for the comprehensive environmental assessment of products
and services.
• Programmatic comparative risk analysis (PCRA) refers to the application of comparative risk assess-
ment to set priorities for research and risk management actions.
• Risk tradeoff analysis (RTA), sometimes called risk-risk tradeoff analysis or risk-risk analysis for ana-
lyzing countervailing risks that occur due to the management of target risks.
331
Engineering Management Handbook

• Health-health analysis (HHA) (also known as wealth-health analysis) attempts to capture the complex
relationship between induced changes in personal disposable income that result from regulation or
policy and their public health consequences.
• Benefit-cost analysis (BCA) attempts to measure both benefits and costs connected to all consequences of
decision alternatives. Usually, monetary values are used as common metrics for both costs and benefits.
• Cost-effectiveness analysis (CEA) is similar in scope to BCA but measures nonmonetary consequences
in physical indicators.

The following table adapted from Hofstetter et al. (2002) shows when one tool may be more appro-
priate over the other.

Table 19.7. Risk Analysis Tools

Tool Units of Costs Units of Benefits Primary Objective

Benefit cost analysis Monetary Monetary Maximize net benefits
(BCA)
Life cycle assessment Physical impacts and Equal functional unit Lowest impact
(LCA) damages
Risk tradeoff analysis Direct health impact Differences in impacts Lowest health impact
(RTA)
Programmatic Ordinal ranking Not applicable Worst thing first
comparative risk
assessment (PCRA)
Cost effectiveness Monetary Direct health impact Biggest bang for the buck
analysis (CEA)

19.5.4 Analytic Hierarchy Process (AHP)

An example of an MCDA tool is described here—the Analytic Hierarchy Process (AHP). Developed
at the Wharton School of Business by Thomas Saaty, AHP is composed of previously existing concepts
such as hierarchical structuring of complexity, pairwise comparisons, redundant judgments, eigenvector
method for deriving weights, and consistency considerations. A popular software implementation of AHP,
“Expert Choice” was developed in 1983 and is currently widely used.
Some important capabilities of AHP are:
• Allows decision-makers to model a complex problem in a hierarchical structure showing the relation-
ship of goals, objectives, subobjectives, and alternatives
• Enables decision-makers to derive ratio scale priorities instead of arbitrarily assigning them
• More than just a decision-making tool can be used in forecasting, resource allocation, and other
applications
• Pairwise Relative Comparisons
• Process can be performed using words, numbers, or graphical bars, and typically incorporates redun-
dancy, which results in a reduction of measurement error
• Accommodates use of expert judgment and its bases (the hard data, knowledge, experience for the
judgments) instead of arbitrarily assigned weights
• AHP allows for inconsistency and provides a measure of inconsistency

A particularly useful concept in risk management built into AHP is the marginal rate of substitu-
tion—essentially showed by the old adage “How much apple is an orange worth for you?” Through the
compensatory natures of AHP, engineering managers are compelled to express utility or preference and
enable them to adopt the otherwise extrinsic objectives, essentially confronting the conflict in the choice
situation by allowing them to trade off a low value dimension for a high value dimension.
332
 Risk Management

19.6 Potential Problem Analysis

19.6.1 Stone-in-the-Pond Analogy
Comparative analysis shows the various costs and benefits of risk mitigation alternatives to the extent that
they can be expressed as unit costs and unit benefits. However, there may be more far-reaching effects that
can be attributed to these alternatives that are not captured by the comparative analysis tools. This step
seeks to answer the risk question – What are the effects beyond this particular time?
This goes to the core of the systems approach to risk management and the realization that elements
inside and outside the systems of interest are often more tightly coupled than initially thought. Hofstetter
et al. (2002) used the stone thrown in the pond and the ripples it produces as metaphor to describe the
effects of a present decision to future decisions, such that:
• The stone thrown stands for the chosen risk mitigation alternative
• The ripples represent the consequences, such that the number of ripples increases as time passes
• Ripples come in various sizes
• Ripples have both up and down sides representing both positive and negative effects

Aside from the original risk scenario, which prompts the whole decision process (aka target risk) often
reflected by the main objective (e.g., minimize public risks to WNV), there maybe two other types of
unintended risk scenarios:
1. Countervailing risk—The risk (i.e., undesirable effect) that arises from the action of managing the
target risk (e.g., increase in health risks due to traffic accidents and pollution).
2. Synergistic effect—Desirable consequence of managing risk other than reducing the target risk (e.g.,
reduction in crime rate at certain hours).

19.7 Implementation, Documentation and Monitoring

19.7.1 The Need for Documentation and Monitoring
At this point, the chosen risk mitigation alternatives are put into action, i.e., mitigation alternatives are
turned into mitigation actions. Due to the inherent uncertainty of risk and the significant resources that
go into its mitigation, the performance of any mitigation action has to be closely monitored all through-
out its implementation. Risk monitoring pertains to the systematic tracking and evaluation of the perfor-
mance of risk mitigating actions against established metrics (Conrow, 2005). This activity seeks to answer
the risk question – How well are the risks being managed?
Monitoring is best done by diligent documentation in the form of recording, maintaining, and
reporting assessments of the target risks as well as the emergence or expiration of synergistic and counter-
vailing risks. Note that the emergence of synergistic or countervailing risks may trigger another full-blown
risk management effort such that they may eventually become the target risks of another set of mitigation
actions. All of these monitoring and documentation is in addition to the traditional project management
activities concerned primarily with the cost, schedule, and performance aspects.

19.7.2 Lessons Learned for the Engineering Managers

Engineering managers will benefit greatly from lessons learned by risk analysts and managers on the com-
mon issues of managing risks toward successful research, development, and engineering activities. These
issues are as follows (some were adapted from Conrow, 2004):
1. Risk management is more than just risk assessment—Engineering managers have to keep in mind
that most organizations manage their risk as a secondary objective in support of their primary objec-
tive (e.g., when an automotive company tries to manage its financial liquidity risks).
2. Repeatability vs. flexibility in RM processes—Because every organization may have its own require-
ments for effective management of risks, the monitoring and documentation of risks mitigation
actions may come in many form but has to have some degree of repeatability for ease of scientific
analysis and comparison.
333
Engineering Management Handbook

3. Sensitivity and accuracy of quantitative results—Many quantitative tools in risk assessment (e.g.,
statistical analyses packages) may express numerical to a level of accuracy that is not expressive of the
inherent uncertainty of a particular risk scenario.
4. Intersection of knowledge domains and RM—Because the ripple effect of decision in risk manage-
ment transcends time and system boundaries, effective risk mitigation actions usually involves a
multi- and cross-disciplinary approaches.
5. Stove-piped RM processes—Engineering managers must be concerned not to perform risk man-
agement subject to the artificial constraints placed by organizational, cultural, political, or technical
boundaries; e.g., managing what is initially viewed as purely technical risk will most likely involve
some financial and socio-political risk.
6. Proper use of ordinal and cardinal values; many tools and techniques in risk assessment commits the
sin of adding and comparing ordinal numbers (e.g., adding ranks). Even though this sin is usually
acceptable to some degree of analysis, the engineering manager needs to be aware of the limitation
and possible pitfalls of these actions.
7. Symmetry between measures of probability and consequence—In the simplest form of expressing
risk as a direct mathematical product of consequence and probability resulting to a unit-less number,
the engineering manager should keep in mind the apparent lack of symmetry between the two, e.g.,
probability ranges from 0 to 1 while consequence ranges from $0 to theoretically $∞.
8. Other (elusive) properties of risk aside from probability and consequence—Related to the previous is-
sue, risk has properties that can be difficult to express quantitatively, much less be contained in either
probability and monetary consequences, e.g., social and cultural properties.
9. RM results are only as good as the analyst—Many risk assessment results may be expressed in
numbers particularly in quantitative risk assessment. However, the high degree of uncertainty and
cross-disciplinary nature of risk places considerable importance on the analyst as much as on the tools
and techniques that may have been used.
10. Choice of model and procedures—Similar to the previous issue, the proliferation of tools and meth-
ods in managing risks results to a lack of de facto standards. Thus, the engineering manager needs to
be aware of the chosen models and procedure and their suitability for the risk scenario at hand.
11. Multiple Stakeholders—Because risk transcends time and system boundaries, there are likely more
than one significant stakeholder who most likely equates to differences in their respective risk concep-
tion, objectives and behavior. These differences have to be recognized in generating alternatives and
tradeoff analysis and the potential for a suboptimal solution.
12. Multiple risk management processes—One very important purpose of monitoring and documenta-
tion in risk management is to be able to review the process at each step of managing risk. The wide
choice of tools and techniques in risk management, each with their own strengths and weaknesses,
may result to an after-the-fact realization of the omission or exaggeration of some risks. Good mon-
itoring and documentation hopefully will result to an early diagnosis of such cases and enabling the
engineering manager to avoid its recurrence.

19.8 Advanced and Other Topics

Table 19.8 contains important topics and the respective references for advanced risk analysis.

334
 Risk Management

Table 19.8. References for Advanced Risk Analysis

Importance to Engineering
Topic References
Managers
Risk-based For cases where financial Pinto, A.C., Arora, A., Hall, D., Schmitz, E., Challenges
economic and economic evaluation of to Sustainable Risk Management: Case Example in
evaluation alternatives are critical to Information Network Security. Engineering Management
decisions Journal, vol. 18, no. 1, March 2006.

Arora, A. D., Hall, C.A., Pinto, D.

Vulnerability For cases when threats and
assessment system vulnerabilities are
uncertain or dynamic
Ramsey, and Telang, R., Measuring the Risk-Based Value of
IT Security Solutions, IEEE IT Professional, vol. 6, no. 6,
pp. 35-42, 2004.
Gheorghe, A. Integrated Risk and Vulnerability Management
Assisted by Decision Support Systems. Relevance and Impact
on Governance (Ed.), Springer, Dordrecht, 2005.

Gheorghe, A. and Mock, R. Risk Engineering. Bridging Risk

Cybersecurity For cases when cybersecurity
plays a big part of managing
risks
Analysis with the Stakeholders Values, Kluwer Academic,
Dordrecht, 1999.
Moore, T. Introducing the Economics of Cybersecurity:
Principles and Policy Options. Proceedings of a
Workshop on Deterring CyberAttacks: Informing
Strategies and Developing Options for U.S. Policy http://
www.nap.edu/catalog/12997.html, 2010.

Flood, et al. Cryptography and the Economics of

Supervisory Information: Balancing Transparency and
Confidentiality. FRB of Cleveland Working Paper No. 13-
12, 2013.
Climate For cases when risks are due Schultz, M. The quantification and evolution of resilience
change and to climate change and sea-level in integrated coastal systems. U.S. Army Corps of
sea-level rise rise Engineers, Engineer Research and Development Center,
Environmental Laboratory and Coastal and Hydraulics
Laboratory http://acwc.sdp.sirsi.net/client/search/
asset/1007720, 2012.

19.9 References
Castillo, E., Extreme Value Theory in Engineering, San Diego: Academic Press, 1988.
Conrow, Edmund H., “Risk Management for Systems of Systems,” Journal of Defense Risk-Software Engin-
eering, Feb. 2005.
Conrow, Edmund H., “Risk Rant: The top 10 risk analysis issues and why they are important to you,”
Risk Management Intelligence Network, June 2, 2004.
Haimes, Y. Y., Kaplan, S., and Lambert, J. H., Risk filtering, ranking, and management framework using
hierarchical holographic modeling. Risk Analysis, vol. 22, no. 2, 2002, pp. 381-395.
Haimes, Yacov, Risk Assessment, Modeling, and Management, Second Edition, Hoboken, NJ: Wiley—Inter-
science, 2004.
Hofstetter, P. et al., “Tools for Comparative Analysis of Alternatives: Competing or Complementary Per-
spectives?” Risk Analysis, vol. 22, no. 5, 2002, pp. 833-851.
Pinto, C. A., and Garvey, P. R., Advanced Topics in Risk Analysis for Engineering Complex and Enterprise
Systems (Series: Complex and Enterprise Systems Engineering), Taylor & Francis LLC, 2012.
Pinto C. A., Magpili, L. M., Jaradat, R., Operational Risk Management: A Systems Approach, Momentum
Press, 2015.
335
336
 What is Quality Management?

20
What is Quality Management?

T. Steven Cotter
Old Dominion University

Brian J. Galli
Long Island University

Patrick Kush
Metropolitan State University

337
Engineering Management Handbook

20.1 A Definition of Quality Management

Quality management is responsible to assure that an organization maintains a desired level of organiza-
tional excellence in its processes output products and services, which provide required value to its custom-
ers and clients. Value is measured in eight dimensions.
1. Performance—Intended functionalityReliability—Failure rateDurability—Product lifetimeService-
ability—Ease of maintenance and repairAesthetics—Subjective product dimensionsFeatures—Com-
petitive satisfiersPerceived quality—ReputationConformance to standardsQuality management must
perform four main functions to achieve organizational excellence: quality planning, quality control,
quality assurance, and quality improvement.

20.2 A Brief History of Quality Management

As a discipline, quality management began in the 1920s with a transition from inspection to production
quality control concepts. The initial focus was in two areas: sampling theory and statistical quality control.
In 1923, Western Electric Company engineers first applied probability theory to the problem of final
inspections of central telephone office equipment. They were the first to define lot tolerance percent
defective and to develop probability of acceptance curves to choose between sampling plans. From 1923
to 1925, studies by the newly formed Inspection Engineering Department in Bell Telephone Laborato-
ries established the fundamentals of sampling theory still in use today. In 1926, the Laboratories and
the production division of Western Electric Company entered into a cooperative agreement to codify the
sampling plans into inspection tables for use in production. The initial tables set forth single and double
sampling tables for selected levels of process average nonconforming at the Lot Tolerance Percent Defec-
tive (LTPD) with a 10% consumers risk. The plans worked well for customer lots that were subdivisions
of continual production; however, experience in applying LTPD plans indicated that they were not effec-
tive for lot sizes constructed from portions of production lots solely for handling convenience. To address
this, researchers developed the concept of Average Outgoing Quality Limit (AOQL) and prepared and
tested additional tables based on AOQL. Harold F. Dodge and Harry G. Romig published results of this
work in 1929 and 1941 and have since become known as the Dodge and Romig sampling plans.
When Walter Shewhart joined Western Electric’s Hawthorne Works Inspection Engineering Depart-
ment in 1918, quality control focus was on inspecting and removing defectives from finished units. In
1924, Shewhart wrote a one-page memorandum proposing the essential principles of statistical qual-
ity control. Shewhart reframed the central issue of quality control in terms of “assignable cause” and
“chance cause” variation with the first simple diagram of a control chart. He went on to create the basis
of control charts through designed experiments that illustrated the importance of bringing a process into
a state of statistical control and maintaining it is this stable state with only residual chance cause varia-
tion. He summarized his work in his book Economic Control of Quality of Manufactured Product in 1931.
Shewhart’s control chart methodology was adopted by the American Society for Testing and Materials
(ASTM) in 1933 and used during World War II to control the quality of war materials.
After World War II, technical work continued on refinement of statistical quality control, develop-
ment of AQL and other sampling plans, and expansion of designed experimental methods. These devel-
opments led to establishment of inspection departments throughout industry. However, it was found that
inspection departments alone were insufficient to control the quality of increasingly complex products
due to the following causes.
• Increasingly difficult technical problems required analytical skills not possessed by production person-
nel.
• Production “inspection” personnel were often inadequately trained.

To address these deficiencies, organizations created quality control departments with separate quality
management and engineering functions. In turn, creation of Quality Control departments led to the ne-
cessity for establishment of quality standards and procedures, engineering planning of sampling systems,
training quality inspectors and auditors on required sampling practices, gathering and analyzing quality
data, and calibration and control of measuring equipment. For W. Edwards Deming (1982), Armand
338
 What is Quality Management?

Feigenbaum (1951, 1961), Joseph Juran and Frank Gryna (1970) and other quality leaders the focus now
turned to the effective management of the quality system.
Armand Feigenbaum, manager of worldwide manufacturing operations and quality control for the
General Electric Company, published his approach to total quality control in his 1951 book Quality Con-
trol: Principles, Practice, and Administration (later retitled Total Quality Control). For Feigenbaum, total
quality control meant that quality was used as a strategic business tool, which required participation by
the whole organization. He emphasized continuous quality leadership with planning, maintenance, and
improvement of customer-oriented quality activities. His book was the first to characterize quality costs
as the costs of prevention, appraisal, and internal and external failure.
Whereas Feigenbaum focused on manufacturing operations, Deming (1982) viewed quality as the
primary driver for business success and broader societal improvement. Deming advocated his 14 Points
for Management as the basis for transforming the competitiveness of American industry.
1. Create constancy of purpose toward improvement.
2. Adopt a new philosophy; recognize that we are in a time of change, a new economic age.
3. Cease reliance on mass inspection to improve quality.
4. End the practice of awarding business on the basis of price alone.
5. Improve constantly and forever the system of production and service.
6. Institute training.
7. Improve leadership, recognize that the aim of supervision is help people and equipment to do a better
job.
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate slogans and targets for the workforce such as zero defects.
11. Eliminate work standards.
12. Remove barriers that rob workers of the right to pride in the quality of their work.
13. Institute a vigorous program of education and self-improvement.
14. Put everyone to work to accomplish the transformation.

Deming set forth a “System of Profound Knowledge” as the theory of effective management thought
and action that can be applied by any leader seeking to transform and create a thriving organization.
• Appreciation of a system—Managers must have an understanding of the overall interrelated processes
involving suppliers, producers, and customers of goods and services.
• Knowledge of variation—The set of attribute causes, range of variation in measurable quality, and the
use of statistical sampling in measurements. Actions must be based on the source of variation: special
and assignable causes versus common or random causes.
• Theory of knowledge—The concepts underlying the current state of knowledge and the limits of that
knowledge. If no learning has occurred, there can be no theories for prediction.
• Knowledge of psychology—Understanding the variation in human capabilities and needs and the
bounds of human nature.

Juran and Gryna (1970) focused on quality training and education for management and defined
quality in terms of the tradeoff between:
• Income—Product features that produce income by meeting customer needs. Under this view, higher
quality yields higher prices.
• Cost—Product performance deficiencies and failures that result in not meeting customer needs. Un-
der this view, higher quality costs less.

Juran and Gryna defined three basic quality management processes required to balance the Income/
Cost tradeoff; quality planning, quality control, and quality improvement. Juran’s quality planning
roadmap for new product or revisions consists of (1) establishing quality goals, (2) determining those
goals that impact customers, (3) identifying customer needs, (4) designing product features, (5) devel-
oping process capabilities, and (6) establishing and transferring process controls to operations. Quality
339
Engineering Management Handbook

control is implemented at all organizational levels to (1) measure process performance, (2) compare
performance to goal, and (3) take action on gaps between actual performance and goals. Quality
improvement is implemented on a project-by-project basis through (1) identifying the quality improve-
ment need, (2) specifying projects to address needs, and (3) organizing and managing project teams.
Quality improvement is accomplished through project teams by (1) verifying the project need and
mission, (2) diagnosing root causes of failure, (3) developing remedies and proving their effectiveness,
(4) dealing with organization resistance to change, and (5) instituting controls to hold gains. Quality
planning, control, and improvement occurs recursively at the strategic, operational, and workforce
levels through the following management responsibilities:
• Creating awareness of the need and opportunity for improvement
• Making quality improvement part of every job description
• Creating an organizational quality infrastructure
• Providing training in quality improvement methods
• Regularly reviewing improvement progress
• Giving recognition to improvement teams
• Publicizing results to reinforce efforts
• Revising the reward system to reinforce improvement
• Maintaining momentum by including quality improvement goals in business plans

The quality management principles of Feigenbaum (1951), Deming (1982), and Juran and Gryna
(1970) (as well as Philip B. Crosby, Kaoru Ishikawa, and other quality management researchers) were
first integrated into an organization-wide effort through Total Quality Management (TQM). In the
spring of 1984, the Navy Material Command tasked the Navy Personnel Research and Development
Center to assess the application of statistical process control and the works of prominent quality
management researchers with the objective of making recommendations as to how to apply their
approaches to improve the Navy’s operational effectiveness. The recommendation was to adopt the
teachings of W. Edwards Deming. After significant quality improvements on first tests, the approach
was extended to other Navy operations. In 1985, the approach was labeled as Total Quality Manage-
ment. In 1990, the Chief of Naval Operations renamed the approach to Total Quality Leadership to
emphasize the importance of leadership in quality improvement. TQM is a customer-focused man-
agement system that involves all employees in continual improvement. It integrates quality discipline
into the organizational culture through strategy, data, and effective communications. The primary
elements of TQM are:
• Customer focus—Customer expectations, needs, and requirements ultimately determine the required
quality levels
• Total employee involvement—Participation of all employees toward common quality goals
• Process-centered—The process activities and performance measures needed to continuously monitor
for and detect unexpected variation
• Integrated system—Linking the interconnecting horizontal productive functions within the function-
al hierarchy
• Strategic and systematic approach—Continually defining and redefining the organization’s quality
vision, mission, and goals
• Continual improvement—Drives analytical and creative ways to become more competitive and more
effective at meeting customer requirements and stakeholder expectations
• Fact-based decision making—Continually collecting and analyzing data in order to improve decision
making accuracy, achieve consensus, and allow prediction based on past history
• Communications—Use communications to maintain morale and motivate employees toward the
quality vision during organizational change

TQM spread from the Navy throughout the United States Federal Government, to the United States
commercial and industrial sectors, and to Western Europe. Commercial and industrial businesses used
TQM principles for competitive leverage in bids for contracts with the United States Federal Government
340
 What is Quality Management?

and as a means of recapturing market share from Japanese companies. In the United States, TQM was
used widely in the 1980s and 1990s until the ISO 9001 and Lean Six Sigma quality movements replaced
it. European governments and businesses continued to apply TQM widely until about 2010. TQM is
still supported through the non-profit organization European Foundation for Quality Management.
Prior to 1987, there was no accepted international quality management standard. Each country de-
veloped its own standard. The United States had no national quality management standard. Depending
on contractual requirements, suppliers to the Department of Defense may have been required to conform
to MIL-Q-9858A, Quality Program Requirements, or MIL-I-45208A, Inspection System Requirements.
Likewise, depending on contractual requirements and industry sectors, large corporations developed
and required supplier conformance to their respective quality program requirements. MIL-Q-9858 was
the basis for the NATO Allied Quality Assurance Publications (AQAP) series issued in 1969 and for the
United Kingdom BS 5179, Guide to the Operation and Evaluation of Quality Assurance Systems, released in
1974. BS 5179 was revised into BS 5750, Quality Systems, and released in 1979.
In 1982, the British government produced a white paper entitled “Standards, Quality and Interna-
tional Competitiveness,” proposing the concept of international certification to a single quality man-
agement standard. This led to work within the International Organization for Standardization to the
development of ISO 9000:1987, Quality management systems, which had the same structure as BS 5750.
ISO 9000:1987 set forth three quality management system models based on the organizational scope of
activities to be certified: (1) 9001 model for quality assurance in design, development, production, instal-
lation, and servicing; (2) 9002 model for production, installation, and servicing; and (3) model for quality
assurance in final inspection and test. ISO 9001:1987 was composed of 20 clauses (evolved from BS
5750) oriented toward documenting the quality manual and the processes of typical manufacturing orga-
nizations and on conformity to those procedures rather than the overall process of quality management.
This structure made the 1987 version difficult to implement by governmental, health, service and software
organizations. ISO 9000:1994 attempted to correct this difficulty by emphasizing quality assurance, but
it continued to require evidence of conformance to documented procedures.
This difficulty with its manufacturing orientation led to the establishment of ISO Working Group 18
that was responsible for revising and drafting ISO 9000:2000 series of standard. The 2000 series focused
on process quality management with goals of assessing (1) management system effectiveness through
process performance metrics and (2) customer satisfaction through external feedback metrics. It was
comprised of three standards:
1. ISO 9000:2000, Quality management systems – Fundamentals and vocabulary
2. ISO 9001:2000, Quality management systems – Requirements
3. ISO 9004:2000, Quality management systems – Guidelines for performance improvements

The ISO 9000 standard set forth eight quality management principles designed to be a foundation for
quality management systems across diverse organizations.
• Customer focus—Understands current and future customer needs, meets customer requirements, and
strives to exceed customer expectations
• Leadership—Provides unity of purpose and direction
• Involvement of people—Enables employee’s abilities for the organization’s benefit
• Process approach—Manage activities and related resources as process
• System approach to management—Identifies, understands, and manage interrelated processes as a
system
• Continual improvement—Improves the organization’s overall performance as a permanent objective
• Factual approaches to decision-making—Bases effective decisions on analysis of data and information
• Mutually beneficial supplier relationships—Enhances the ability of interdependent suppliers and
organizations to create value

The following roles are specified for top management within the quality management system:
• Establish and maintain the quality policy and quality objectives
• Promote the quality policy and objectives to increase awareness, motivation, and involvement
341
Engineering Management Handbook

• Ensure focus on customer requirements

• Ensure appropriate processes are implemented to enable requirements of customers and other inter-
ested parties to be fulfilled and quality objectives to be achieved
• Ensure that an effective and efficient quality management system is established, implemented, and
maintained
• Ensure the availability of necessary resources
• Review the quality management system periodically
• Decide on actions regarding the quality policy and objectives
• Decide on actions for improvement of the quality management system

ISO 9001-2000 is the requirements standard to which organizations may seek certification. It sets for
the quality management systems requirements in the following sections:
0 Introduction
1 Scope
2 Normative reference
3 Terms and definitions
4 Quality management system
4.1 General requirements
4.2 Documentation
5 Management responsibility
5.1 Management commitment
5.2 Customer focus
5.3 Quality policy
5.4 Planning
5.5 Responsibility, authority and communication
5.6 Management review
6 Resource management
6.1 Provision for resources
6.2 Human resources
6.3 Infrastructure
6.4 Work environment
7 Product realization
7.1 Planning of product realization
7.2 Customer-related processes
7.3 Design and development
7.4 Purchasing
7.5 Production and service provision
7.6 Control and monitoring of measuring devices
8 Measurement, analysis, and improvement
8.1 General
8.2 Monitoring and measuring
8.3 Control of nonconforming product
8.4 Analysis of data
8.5 Improvement

Under ISO 9001:2000 clause 1.2, Application, an organization with no design and development
activities may seek exclusion from section 7.3 with it registrar.
The fourth edition of ISO 9001:2008 specified only minor amendments and clarified existing re-
quirements to improve consistency of approach with other management standards, like ISO 14001:2004,
Environmental management systems. ISO 9001:2008 added the following three notes clarifying the
requirements for control of outsourced processes.

342
 What is Quality Management?

NOTE 1: Processes needed for the quality management system referred to above include processes for
management activities, provision of resources, product realization, measurement, analysis and improve-
ment.
NOTE 2: an “outsourced process” is a process that the organization needs for its quality management
system and which the organization chooses to have performed by an external party.
NOTE 3: Ensuring control over outsourced processes does not absolve the organization of the respon-
sibility of conformity to all customers, statutory and regulatory requirements. The type and extent of
control to be applied to the outsourced process can be influenced by factors such as:
a. The potential impact of the outsourced process on the organization’s capability to provide product
that conforms to requirements,
b. The degree to which the control for the process is shared,
c. The capability of achieving the necessary control through the application of 7.4.

The ISO 9001:2015 revision was intended to update the standard to the common management
system framework required by Appendix 3 of ISO/IEC Directives, Part 1 Annex SL and to increase its
relevance to service industries and office environments. Its quality management system requirements were
revised into the following sections.
0 Introduction
1 Scope
2 Normative reference
3 Terms and definitions
4 Context of the organization
4.1 Understanding the organization and its context
4.2 Needs and expectations
4.3 Scope
4.4 Management system
5 Leadership
5.1 Management commitment
5.2 Commitment
5.3 Roles, responsibility, and authority
6 Planning
6.1 Actions to address risks and opportunities
6.2 Objectives and plans to achieve them
7 Support
7.1 Resources
7.2 Competence
7.3 Awareness
7.4 Communications
7.5 Documented information
8 Operations
8.1 Operational planning and control
9 Performance evaluations
9.1 Monitoring, measurement, analysis, and evaluation
9.2 Internal audit
9.3 Management review
10 Improvement
10.1 Nonconformity and corrective action
10.2 Improvement

Key changes include an emphasis on preventive action through risk-based management, achieving
value for the organization and its customers, responsiveness to the business environment, and enhanced
leadership requirements. There is a decreased emphasis on documents and records, but the standard
343
Engineering Management Handbook

expands the concept of documentation. Outsourcing was respecified as “external provision,” and the
requirements for a quality manual and management representative were deleted.
Because the ISO 9000 series of standards are very general in their language, its sections must be
carefully interpreted within each organization’s business context. As a result, various industry sectors have
created their own standardized quality management systems standards to ensure critical industry-specific
issues were addressed and to ensure assessment and certification by appropriately trained and experienced
auditors.
• AS9100 – Aerospace Basic Quality System Standard is an interpretation developed by major aerospace
manufacturers. AS9100 replaces the earlier AS9000 and fully incorporates the entirety of the current
version of ISO 9000. It adds quality and safety requirements unique to the aerospace industry.
• HS1-A2 Quality System Model for Healthcare establishes standards for policies and procedures for the
care of patients in clinics and hospitals.
• ISO 13485:2003 Medical Devices – Quality Management Systems – Requirements for Regulatory Pur-
poses. The primary objective of ISO 13485:2003 is to harmonize medical device regulatory require-
ments for quality management systems. As such, it includes some particular requirements for medical
devices and excludes some of the requirements of ISO 9001 that are not appropriate as regulatory
requirements.
• ISO/IEC 90003:2004 Software Engineering – Guidelines for the Application of ISO 9001:2000 to
Computer Software. ISO/IEC 90003:2004 sets forth guidelines for organizations in the application
of ISO 9001:2000 to the acquisition, supply, development, operation and maintenance of comput-
er software and related support services. These guidelines are not intended to be used as assessment
criteria in software quality management system registration or certification. The application of ISO/
IEC 90003:2004 is appropriate to software that is:
• Part of a commercial contract with another organization
• An independent product available for a market sector
• A product that is used to support organizational processes
• Embedded in a hardware productDelivery of software services
Additional software management guidance is found in the ISO/IEC JTC 1/SC 7 software engineer-
ing standards.
• ISO 15189 Medical Laboratories – Particular Requirements for Quality and Competence specifies the
quality management system for medical laboratories. The standard sets forth requirements for labora-
tory service, the collection of patient samples, the interpretation of test results, acceptable turnaround
times, how testing is to be provided in a medical emergency and the lab’s role in the education and
training of health care staff.
• ISO/TS 16949:2009 Quality Management Systems – Particular Requirements for the Application of ISO
9001:2008 for Automotive Production and Relevant Service Part Organizations. ISO/TS 16949:2009
replaced the QS9000 series of standards. Its primary focus in on managing the automotive supply
chain to identify problems and risks, eliminate root causes, and assess effectiveness of preventive and
corrective actions.
• IWA-1:2005 Quality Management Systems – Guidelines for Process Improvements in Health Service Or-
ganizations. This standard sets forth additional guidance for health service organizations involved in
the management, delivery, or administration of health service products or services, including training
and research in the life continuum process for human beings.
• TL 9000: Quality Management System Requirements for Telecommunications. TL 9000 encompasses
the ISO 9001 standard verbatim, plus additional telecommunications industry-specific requirements.
TL 9000 specifications are set forth in two documents:
• TL 9000 Requirements Handbook, release 5.5, which includes the full text of ISO 9001:2008
• TL 9000 Measurements Handbook, release 5.0

Whereas the above quality management systems standards specify minimum requirements, the
Malcolm Baldrige National Quality Award (MVNQA) for private-sector organizations and the Baldrige
National Quality Program (BNQP) for governmental and military organizations specify standards for
344
 What is Quality Management?

organizational excellence. The MBNQA was established by the U.S. Congress in 1987 to raise awareness
of quality management and recognize U.S. companies that have implemented successful quality man-
agement systems. Awards can be given annually in six categories: manufacturing, service, small business,
education, healthcare and nonprofit. As a quality management system model, the MBNQA criteria are
specified in seven sections.
1. Leadership—Examines how effectively an organization’s management guides and sustains the organi-
zation and how it addresses ethical, legal, and community stakeholder responsibilities
2. Strategic planning—Examines how the organization develops competitive strategy, sets strategic objec-
tives, and implements action plans to achieve those objectives
3. Customer and market focus—Examines how the organization determines customer expectations, pref-
erences, and requirements and how the organization builds customer relationships
4. Measurement, analysis, and knowledge management—Examines how the organization identifies, gath-
ers, selects, analyzes, manages, and improves its data, information, and knowledge assets
5. Human resource focus—Examines how the organization promotes employee learning and motivation
and establishes work systems to enable employees to utilize their full potential in alignment with the
organization’s strategic objectives
6. Process management—Examines the organization’s product, service, and business processes ability to
generate value
7. Business results—Examines the organization’s performance and improvement outcomes in leadership
and social responsibility, human resource results, operational performance, product and service quali-
ty, customer satisfaction, and financial and marketplace performance

Similar national quality awards that can be used as quality management system models include the
European Quality Award and the Deming Prize and the Shingo Prize for Excellence in Manufacturing, the
latter two in Japan.

20.3 Quality Planning

Quality planning focuses on designing expected and required quality levels into products prior to initi-
ation of production, services prior to contact with customers, or the deliverables of projects before the
first task activities. In the following discussion, the term “product” will be used synonymously to mean
physical products, services, or project outputs, since the later two are forms of products.

Identify Customer Information. The first step in quality planning is to identify the customers of the
product, service, or project. A “customer” is any person, who or organization that, is affected or impact-
ed by the product, service, or project’s benefits or costs. In this broader sense, customers include end
users, retailers and wholesalers, logistics personnel, service personnel, production personnel, and support
personnel, the latter three of which may belong to the organization and participate in production and
delivery of the product, service, or project. Where customers are numerous, it is often helpful to apply
the Pareto principle to classify customers into the categories of the vital few and the useful many. The
vital few customers experience the majority of the benefits or incur the majority of the cost. Conversely,
the useful many are affected only marginally by benefits or costs.

Once customers are identified, an information base must be established for each customer. The
information base should be designed to collect solicited and unsolicited, qualitative and quantitative,
and structured and random customer information. Structured information may include prior internal
sales and complaint or warranty reports, customer tests production reports, quality reports, or external
surveys, trade reports, standards organizations reports, governmental reports, and public legal documents.
Random information may include trade visit reports, customer contact reports, consultant reports, con-
vention proceedings, trade journal articles, trade show lists, vendor and supplier surveys, and employee
training files.

345
Engineering Management Handbook

Determine Customer Needs. Step two is to solicit customer expectations, needs, and requirements and
combine these with acquired customer information to develop a complete view of how customer will in-
teract with the product or service and the benefits they expect to attain. The fundamental problem is that
customers state their needs in their language from their viewpoint. Real quality needs (the eight value
dimensions) most usually differs from stated needs, and actual customer use (and misuse) of products and
services may differ from suppliers’ intended use. Typical methods of discovering customer needs include:
• Communicating with customers
• Interacting with designs from the customer’s perspectives
• Cause and effect matrix
• Quality function deployment
• Simulating customers’ needs

Some customers (especially internal customers) may resist the introduction of new product, process,
or service features, because they feel those features carry undesirable social or physical consequences or
require additional learning or effort on their part. Overcoming resistance to change may involve any
combination of these tactics: (1) Get customers to participate in making the change. (2) Understand and
address personal concerns behind the resistance to change. (3) Link the change to positive benefits valued
by customers. (4) Demonstrate how the new benefits offset current or potential loss or inefficiencies. (5)
Understand the “blind spots” in supplier understanding of customer needs. (6) Tailor information about
new product or service features to customers’ expectations. (7) Sell the change to an influential group
within the customer base and help them spread the change. (8) Communicate the benefits of change in
concrete and local terms. (9) Appeal to the whole brain—provide emotional as well as technical informa-
tion about the change. (10) Provide only relevant information to help customers accept the change; do
not overload customers with too much change information. (11) Most important, be fully knowledgeable
about the pros and cons of the proposed change.

Translate Customer Needs into the Supplier’s Language. The language used by customers to express
expectations, needs, and requirements is usually vague and often expressed in terms of multiple dialects;
performance, dependability, purchasing, managerial, industry standards, legal, etc. It is essential to
translate multiple customer dialects into the supplier’s design language. The following tools assist in this
translation:
• A design glossary of key terms and their agreed definitions for each
• A samples library for product sensory features
• Internal or external standards
• Standard measurement systems that specify units of measure, valid range of measurement, and the
means of measurement
• Design specialists with expertise in translating customer requirements

Product Development. Determine the product features and functions necessary to meet translated
customer expectations, needs, and requirements given constraints of customer abilities, suppliers and
internal production capabilities and capacities, technical, socio-technical, political, and legal/regulatory
environments. Quality planning is initiated in parallel to establish quality goals for each of the eight qual-
ity dimensions and specify sampling points in the process, inspection and test methods, sampling plans,
statistical quality controls, quality training and certification requirements, and product handling controls.
Multiple tools are applied to guide quality planning. Criticality analysis is applied to identify the “vital
few” product functions and features along the eight quality dimensions that determine the core product
benefits. Competitive analysis compares proposed design features and functions to those in existing and
expected future competitors’ products. Stability analysis attempts to establish the relationships between
product features and functions and actual performance in satisfying customer expectations, needs, and
requirements. Customer behavior analysis studies which current similar products customers purchase and
do not purchase and the reasons behind their purchase decisions. Marketing research seeks to understand
customer perceptions and opinions of proposed product features and functions. Value analysis summariz-
346
 What is Quality Management?

es the prior information in the form benefit/cost ratios that measure the per-unit cost of various combina-
tions of product features and functions.

Optimize Product Design. The set of optimum designs is determined by each design’s benefit/cost ratio.
That is, the efficient benefit/cost design frontier is identified by those designs that maximize benefits of
varying levels of feature-functionality combinations per varying units of costs of delivering those features
and functionality. Suboptimal benefit/cost designs are eliminated. The design question then becomes
where along the efficient design frontier to select the combination of product features and functionality
that meet or exceed customer expectations, needs, and requirements versus the price (cost + profit) that
the customer is willing pay. For some products, there may be benefit/cost break points that define differ-
ent product categories (economy, standard, deluxe; low, medium, high performance; etc.). Quality plan-
ning adjusts quality goals for each of the eight quality dimensions, inspection and test methods, sampling
plans, statistical process controls, quality training and certification requirements, and product handling
controls to align with the selected optimized benefit/cost ratio design(s).

Process Development. Process development is the set of activities required to provide production ac-
tivities with the means of delivering the selected benefit/cost optimized product design(s). For process
engineering, the end result of process development includes:
1. The process design of (a) physical production facilities, (b) associated computer information and con-
trol hardware and software, and (c) configuration controlled information on the procedures needed to
operate, control, and maintain the physical facilities.
2. Identification and acquisition of the technologies necessary to realize the physical production facili-
ties, control systems, and information systems.

In this phase, quality planning refocuses to process control—the means of establishing and maintain-
ing the process in a planned stable and capable state. Critical process steps are identified first. A process
step is critical if it poses large risks to human safety, environmental impacts, or suboptimization the se-
lected product design(s) benefit/cost ratio(s). The following features may be built into the process control
systems to minimize identified risks:
• Selection, training, and qualification of control personnel
• Redundancy in various elements of process control feedback loops
• Independent audits to assure compliance with procedures and specifications
• Critical incident analyses with a focus on identifying and eliminating root causes of failures

For each inspection or sampling point in the process, control planning involves:
• Identifying the product characteristic (feature or functionality) to be controlled
• Setting the unit of measure
• Establishing the target, variance, stability, and capability goals
• Specifying the measurement sensor with sufficient capability of evaluating actual performance in the
specified unit of measure
• Specifying the standard for actual performance
• Specifying interpretation(s) and action(s) for observed difference(s) between actual and goal

Transfer to Operations. Transfer to operations, the final step in quality planning, involves validating
quality control and process control plans, finalizing quality procedures, and shifting responsibility to pro-
duction personnel. Three major activities must be completed:
• Proof of process control and stability under standard operating conditions including measurement
system repeatability and reproducibility, validation of functional relationships between process vari-
ables and product features and functionality, verification of type I and type II sampling and control
chart risks, and maintainability
• Proof of process stability and capability under standard operating conditions starting with small-scale
pilot runs and concluding with full-scale production
347
Engineering Management Handbook

• Transfer of quality knowledge in the form of training verification on process specifications and proce-
dures, control procedures, and accuracy of quality information

20.4 Quality Assurance

ISO 8402:1994 Quality management and Quality Assurance – Vocabulary defines quality assurance as “All
those planned or systematic actions necessary to provide adequate confidence that a product or service
will satisfy given requirements for quality.” Quality assurance provides continual assessment of the state
of quality processes and the level of product quality. Quality assurance is accomplished through quality
systems audits, process audits, product audits, and quality surveys.
Quality systems audits are systematic examinations of a quality management system carried out by an
internal or external auditor or audit team at planned intervals to assure that the organization has clearly
defined and implemented internal quality system monitoring procedures. Quality systems audits assess
the suitability, adequacy, and effectiveness of quality processes in achieving quality objectives, improving
the quality management system processes, improving product performance relative to customer require-
ments, and supplying sufficient resources to support the system. Systems audits scope and activities
include:
• Engineering documentation for use of the most current specifications and procedures and revision
control to assure design changes reach production in a timely manner
• Job instructions exist and are adequate to achieve required process and product quality levels
• Machines, tools, and software are suitable, adequate, and maintained
• Calibration procedures provide accuracy and precision traceable to national or international standards
and the degree to which calibration intervals are met
• Production and inspection personnel are adequately trained and certified for critical skills
• Production facilities are appropriately organized, maintained, and environmentally controlled
• Inspection instructions are written and are adequate to assess quality levels
• Inspection results are documented, sufficient in detail, and provide useful feedback to production personnel
• Materials are identified relative to product configuration and inspection status and that nonconform-
ing product is segregated and controlled
• Material handling procedures for critical materials are sufficient to protect them from handling dam-
age and in-process storage environments are effective to prevent deterioration

Quality process audits are independent evaluations of an individual process or set of processes for
adherence to specifications and procedures and the effectiveness of process controls. Process audit scope
and activities include:
• Effectiveness of the selection, training, and qualification of control personnel
• Estimating process quality levels achieved
• Evaluating the effectiveness of process control information and process control decisions to maintain
process stability and capability
• Evaluating the robustness of redundant feedback control loops
• Evaluating the effectiveness of critical incident analysis in mitigating or eliminating the root causes of
process and product failures

Quality product audits are independent evaluations of product quality to determine conformance to
specification and fitness for use. Product audits are conducted after inspection points in the process and
from finished goods. Product audit scope and activities include:
• Effectiveness of the selection, training, and qualification of production and inspection personnel
• Estimating in-process product quality conformance to specifications
• Estimating finished goods fitness for use to customer expectations, needs, and requirements and
maintenance of efficient benefit/cost designs
• Effectiveness of material handling procedures in preventing handling damage and storage environ-
ments in preventing deterioration
348
 What is Quality Management?

Quality surveys collect information on customers, employees, and stakeholders’ perceptions of organi-
zational quality standing, opportunities for improvement, and unexpected threats to its quality standing.
Quality surveys may assess:
• The quality standing in the marketplace relative to competitors
• End users’ fit for use experience with respect to product performance and cost over the life of the product
• Opportunities for reducing costs of poor quality, improving the product performance/cost ratio, or
developing new product quality attributes and characteristics
• Future product design and development quality issues
• Challenges to top management with respect to quality policies, goals, objectives, premises, and axi-
omatic beliefs
• Employee perceptions of training, quality of work life, process performance, and product quality

Quality surveys can be developed by outside professional survey organizations or from published cri-
teria such as the Malcolm Baldrige National Quality Award or other national quality award criteria, or ISO
or other international or national quality management standards.

20.5 Quality Control

Quality control is the inspection and test regulatory process that measures actual quality performance,
compares it to standards and requirements, and acts on the difference to maintain required levels of pro-
cess and product quality. Quality control is comprised of the activities and techniques applied to achieve,
maintain, and improve quality of a product or service. It involves integrating:
• Standards and specifications of what is needed
• Design of the product or service to meet standards and specifications
• Production or installation to meet the full intent of the standards and specifications
• Inspection and test to determine conformance to standards and specifications
• Review of product or service fit for use to provide information for the revision of standards and speci-
fications toward quality improvement

Statistical quality control (SQC) and statistical process control (SPC) are the application of statistical
methods to collect, analyze, and mathematically determine product quality levels and process stability and
capability. SQC and SPC involve data collection, summary into statistics, analysis relative to statistical
limits, and the reporting of product and process attributes and characteristics quality levels, aggregate
product quality levels, and aggregate process stability and capability.

20.6 Quality Improvement

Quality improvement is a formal approach to the analysis of quality performance deficiencies and sys-
tematic efforts to remove those deficiencies. Quality performance improvement may focus on a single
product or process parameter, a whole process, a product, departmental quality, or on the general quality
management system itself.
Quality improvement typically focuses on chronic rather than sporadic failures. Processes for the
detection and elimination of sporadic failures are designed into the out-of-control action plans (OCAP)
of online quality control. Conversely, chronic failures arise from deficiencies in the original process design
and require long-term remedies by management and engineering. Approaches to providing long-term
remedies are the focus of quality improvement. Various quality improvement models have been proposed
and applied. The most prominent include:
• Kaizen, the Japanese approach to continuous improvement, systematically seeks to achieve small, in-
cremental improvements in processes efficiency and quality through the involvement of all employees.
For sporadic failures, work is directed toward refining corrective actions to improve early detection
and correction. For chronic failures, work is directed toward better target levels of annual perfor-
mance. For process refinements, work is directed toward achieving target quality levels and reducing
variation around those target levels. The Kaizen activity cycle is as follows:
349
Engineering Management Handbook

• Standardize the selected operation’s processes and activities

• Measure the operation quality level
• Compare measured quality levels against requirements
• Innovate to meet requirements and improve quality
• Standardize the new, improved operation
• Continue cycle ad infinitum
• PDCA (plan-do-check-act) or PDSA (plan-do-study-act) is an iterative four-step management meth-
od for the control and continual improvement of processes and products. PDCA was originated by
Walter Shewhart (1931) and promoted by W. Edwards Deming (1982). Later in his career, Deming
modified PDCA to “Plan-Do-Study-Act” (PDSA), because he felt that “Check,” emphasized inspec-
tion over analysis. For a given process or product, the PDCA cycle steps involve:
• Plan—Establish quality objectives and processes necessary to achieve those objectives.
• Do—Implement the plan, execute the process, and make the product. Collect data for charting
and analysis.
• Check (Study) —Analyze and study the actual results (collected in “Do” step above) and compare
against the expected results (objective goals from the “Plan” step) to ascertain any differences.
Look for deviations in implementation from the plan and also look for the appropriateness and
completeness of the plan to enable the execution.
• Act—If the Check step shows that the Plan as implemented in the Do phase is not an improve-
ment, then the existing standard baseline will remain in place. If the Check phase shows that
the Plan as implemented in Do phase is an improvement to the prior standard baseline, then the
improved process becomes the new standard baseline for how the organization should Plan and
Do going forward.
• Juran’s project-by-project approach to quality improvement focuses on one chronic failure chosen for
solution. Juran’s continuous improvement approach is implemented in four steps:
1. Prove the Need—Collect factual information to objectively measure the magnitude of the cost of
poor quality at a process point. Determine objective benefits that are possible from an improve-
ment program. Use the benefits to justify requested resources for the improvement program.
2. Identify Projects—Nominate improvement projects by Pareto analysis of the cost of poor quality.
Middle management reviews potential projects and makes recommendations to top management
for approval and allocation of resources. A problem and mission statement are specified for each
project. The problem statement identifies a visible deficiency in planned quality, and the mission
statement provides a project improvement goal and direction for the project team.
3. Organize Project Teams—The project team consists of personnel (limited to 6 or 8) drawn from
multiple departments based on their respective specialize skills and knowledge and assigned the
project’s successful conclusion. The project team follows team rules and processes until the suc-
cessful conclusion of the project by a quality breakthrough.
4. Institute Controls to Hold the Gain—The final step of the breakthrough sequence is holding the
gains such that the process cannot revert to its former state. It consists of three steps. (1) Provide
production personnel with a new stable process capable of holding the gains under the new operating
conditions. (2) Establish new operating procedures and train production personnel in the applica-
tion of those procedures. (3) Provide new systematic process controls capable of holding the gains.
• CQI – Continuous Quality Improvement (CQI) is a management philosophy that contends that
most things can be improved. As such, CQI depends on management leadership for implementation
organization wide. CQI focuses on the process rather than individuals in the process, recognizes both
internal and external customers, and promotes the need for objective data to analyze and improve
processes. CQI evolved from the PDCA cycle and from Juran’s quality improvement approach and is
implemented in the following steps.
• Form a team that has knowledge of the system needing improvement
• Define a clear quality objectives and targets
• Understand the needs of the people who are served by the system
• Identify and define measures of success
350
 What is Quality Management?

• Brainstorm potential change strategies for producing improvement

• Plan, collect, and use data for facilitating effective decision making
• Apply the scientific method to test and refine changes

Benchmarking, Lean, and Six Sigma are specific methodologies for implementing CQI.
• FADE – Focus, Analyze, Develop, Execute/Evaluate is a quality improvement cycle that is part of the
Organizational Dynamics’ Quality Action Team approach to total quality management. FADE was
based on the PDCA and has much in common with Six Sigma DMAIC. The FADE improvement
cycle is as follows:
• Focus—Define the process to be improved or the process to be addressed
• Analyze—Collect and analyze data to establish baselines, identify root causes, and point toward
possible solutions
• Develop—Develop action plans for improvement, including implementation, communication,
and measuring/monitoring
• Execute/Evaluate—Implement the action plans and ongoing measuring/monitoring of the system
to ensure success
• TQM – Total Quality Management, discussed under A Brief History of Quality Management, was a
quality management philosophy that attempted to install organization-wide efforts to make perma-
nent a climate in which an organization continuously improved its ability to deliver high-quality
products and services to customers. The TQM improvement model, largely based on the PDCA
cycle, was implemented in the following steps.
• Customer focus—Customers exist both outside and within the organization. Understand cus-
tomer expectations and needs as well as stated requirements. Focus on delivering combinations
of expectation-needs-requirements fulfillment that translates into customer satisfaction.
• Planning process—TQM requires the organization to analyze and evaluate customers’
expectation, needs, and requirements to determine the best approach to meet them. TQM
strategic planning prioritizes and focuses process planning around customers’ expectations,
needs, and requirements and puts plans into place to fulfill them, to predict business envi-
ronment changes that impact customers, and position the organization to develop an edge
that differentiates it from its competitors. The final product and goal of the organization is
creating value for consumers.
• Process management—TQM views an organization as a collection of processes and maintains
that organizations must strive to continuously improve these processes by incorporating the
knowledge and experiences of workers.
• Process improvement—Continuous process improvement must be based on analysis of data
and facts but allow human creativity to find more effective and competitive products that
fulfill customers’ expectations, needs, and requirements.
• Total participation—Customer satisfaction requires total employee involvement with all
employees working toward common quality goals.
• Lean Six Sigma—Six Sigma is a set of techniques and tools embedded in the process
improvement model. It was developed by Motorola in 1986 to address increasing defect rates
with continued microchip circuitry miniaturization. Six Sigma seeks to improve process and product
quality by identifying and removing the causes of defects and by minimizing variability
in manufacturing and business processes through application of empirical statistical methods.
Six Sigma seeks to create deep process improvement knowledge through a special infrastructure of
experts within the organization known as Champions, Black Belts, and Green Belts. The Lean
process improvement methodology was added to Six Sigma to address short- to medium-term proj-
ects not requiring empirical statistical methods. Lean Six Sigma quality improvement is achieved by a
sequence of projects that follow the Define, Measure, Analyze, Improve, and Control (DMAIC) steps.
• Define customers and their requirements, organizational requirements needed to fulfill customers’
requirements, the organizational system processes needed to achieve requirements, the problem to
be addressed, and the project improvement goals.
351
Engineering Management Handbook

• Measure key aspects of the current process capability by collecting relevant data and calculating
the “as-is” process capability.
• Analyze process data to investigate and verify cause-and-effect relationships. Determine the criti-
cal few relationships while ensuring that all factors have been considered. Seek out root cause of
the defect(s) under investigation.
• Improve or optimize the current process based upon data analysis using techniques such as design
of experiments, poka-yoke or mistake-proofing, and standard work to create a new, future state
process. Set up pilot runs to establish new process capability.
• Control the future state process to ensure that the new process is robust to deviations or that any
deviations from the target are corrected before they result in defects. Implement control systems
such as statistical process control, production boards, and visual workplaces. Establish continu-
ous monitoring of the improved process.

20.7 The Seven Quality Tools

Engineering have a variety of quality management tools that can assist them during their continuous
improvement efforts. There are seven tools that have been developed over the past decades to assist in
guiding their mission to quality; process maps, check lists, histogram, Pareto charts, Ishikawa diagram,
control charts and scatter charts. These tools combine statistical methodologies with standardized charts
to allow managers to efficiently determine where opportunities for improvements exist in a repeatable
process. When used properly, these tools visually assist the manager in maintaining control and perform-
ing an analysis of variations when the process becomes out of control.

20.7.1 Process Maps

Process maps provide a visual representation of processes in the system as shown in Figure 20.1. Process
maps are also known as flowcharts. Process maps help managers identify and analyze the steps in a process
where quality can be introduced. Identifying upstream and downstream value chain decisions through a
process map will help the manager define quality opportunities throughout the process. Complex process-
es may facilitate the need for multiple process maps to examine any sub-processes within the system.

Figure 20.1. Process Map Example

Raw/Source Raw/Source
Materials Materials

Prepare
Materials

Transformation Process

Product Quality Assurance

Waste

Recycle/ Waste By-

Packaging product
Reclaim

Distribution

352
 What is Quality Management?

20.7.2 Checklists
Checklists are a basic tool to compile data into valuable information. Checklists are used to quickly gath-
er, compile and analyze the data. This data can be in the form of either variable or attribute data. Variable
data, also known as continuous data, is used when managers need to use all the data that is collected,
counted and used, sometimes continuously. Attribute data is used in complex situations by counting
the number of defective items or the number of defects per unit (Schroeder, 2008). It is important for
managers to know the type of data they are collecting so that they can use the information wisely. Once a
checklist is developed, it can be a useful guide for evaluation that can encourage discussion into identify-
ing areas of improvement (Dennis & Componation, 2004).

20.7.3 Histograms
Histograms can serve as a comparison tool between data sets. A manager can quickly assess whether the
introduction of new conditions align with expectations. On the most basic level, a histogram should con-
vey the success and/or failure rates due to the introduction of process enhancements. In an ideal situation
for the charts shown in Figure 20.2, you can see that the goal should be improved while variations of the
goal were eliminated.

Figure 20.2. Histogram Examples

Ideal Baseline Histogram Ideal Post-Improvement

Goal Deviations Goal Deviations

20.7.4 Pareto Charts

A Pareto chart is a useful tool to address variations in the process. Variations are defined as being common
or special. A common type variation is inherent to the system and can be examined after addressing spe-
cial variations. Special variations are situations in the process that can introduce inefficiencies that need
to be corrected. Special variations are random and usually cannot be predicted. An example of a common
variation in manufacturing may be the environmental conditions around the process. Temperature and
lighting conditions may not directly impact the manufacturing process but it may play a role with the
human resources. A special variation to the manufacturing process may be the unexpected loss of power
to the facility.
There are a number of items in a Pareto chart that help the engineering manager identify where to
direct quality improvement efforts. Special variations on a Pareto Chart are listed on the horizontal axis in
decreasing order. The number of special variations can be found by using a checklist to identify variable
data in the sample population. The frequency of the variations is labeled on the left vertical axis. Another
353
Engineering Management Handbook

significant feature of the Pareto chart is the addition of a cumulative percentage line. The total number of
each type of variation is divided by the total number of variations in the sample set to determine the per-
centage for that specific type of variation. The cumulative percentage line adds each percentage of varia-
tions beginning from the largest variation on the left. The cumulative percentage line is commonly labeled
on the right vertical axis. Figure 20.3 is an example of a Pareto chart.

Figure 20.3. Pareto Chart

The Pareto chart gives the manager a quick look to see what can be addressed in a process. Vilfredo
Pareto (1848-1923) was an Italian economist who was curious where the wealth existed in Milan. Pareto
determined that 85% of the wealth was from 15% of the population. Joseph Juran identified this rela-
tionship and summarized it as the Pareto principle in 1950 (Collier & Evans, 2013). The Pareto principle
focuses on the few variations that occur most frequently. This is also called the 80/20 principle.
The Pareto principle can be applied to many situations. Banasik and Beruvides (2012) applied the
Pareto principle to identify the largest cost to quality by identifying the largest expenses. In their analy-
sis, the authors found that a small increase in a large category will have significantly more impact than a
large charge in a negligible expense category (Banasik and Beruvides, 2012). The Pareto results for El Paso
Water Utility is shown in Table 20.1.

354
 What is Quality Management?

Table 20.1. Pareto Results Example

EL PASO WATER UTILITY

Account Number Account Description - name % Of Total Expense
7020 O & M Salaries and Wages 35.6%
7060 Electricity Expense 15.7%
7850 Maintenance of Equipment 6.0%
7500 Chemicals 6.0%
7080 Water Purchased for Resale 4.4%
7010 Capital Salaries & Wages 3.5%
7530 Sludge Hauling Fees 2.7%
7880 Maintenance of Mains 2.3%
7710 Natural Gas Expense 2.0%
7860 Maintenance of Services 1.6%
7420 Postage 1.4%
7790 Software Expense 1.4%
7720 Professional Services 1.3%
7120 Transportation 1.2%
7210 Turf Rebate Program 1.1%
86.2%

20.7.5 Ishikawa Diagram

An Ishikawa diagram is shown in Figure 20.4 and is also known as a cause and effect chart or a fishbone
diagram. An Ishikawa diagram is a visual chart developed through brainstorming methods to find the root
cause of special variations in the process. The technique known as the “5 whys” can help find the source of
the root causes that affect the process. Root causes can be found by asking “why” four to five times during
the examination of the variations.

Figure 20.4. Ishikawa Diagram

355
Engineering Management Handbook

20.7.6 Control Charts

Control charts (see Figure 20.5) are also known as run charts or Shewhart charts. Walter Shewhart devel-
oped control charts during his work Harold Dodge, George Edwards and others at The Western Electric
group (Evans, 2011). Control charts enable managers to monitor processes and identify when the process
becomes out of control. A process is “in control” when the product or service is within specified statistical
parameters. The process is “out of control” when the process exceeds these limits (see Control Chart Ex-
ample). The mean is determined from the data sets in the process. The data is also used to determine the
standard deviations. The type of standard deviation used is determined by selecting whether the data from
the process is the entire population or from just a sample. Equations for each are provided below (Evans
& Lindsay, 2011).
For the entire population:

, Where µ = population mean

For a sample:

, Where = sample mean

Figure 20.5. Control Chart 1

In the chart in Figure 20.5, processes that are in control are only influenced by common variations.
The control limits are calculated as follows.

Upper Control Limit (UCL) = + kσ, where k = number of standard deviations

Lower Control Limit (LCL) = - kσ, where k = number of standard deviations

A manager needs to address the special variations when the process becomes out of control (see Figure
20.6). The manager can use a Pareto analysis in conjunction with an Ishikawa diagram to determine the
improvements necessary to regain control of the process. After the improvements have been implemented, the
process can then be evaluated to determine success. In Figure. 20.6, there is a visible shift in the mean from X1
356
 What is Quality Management?

to X2 after improvements were implemented from the Pareto analysis. The standard deviations have reduced
and the range of control limits has narrowed. These are indicators that the improvements were successful.

Figure 20.6. Control Chart 2

In addition to the control charts, there are a number of other statistical charts that could help the
engineering manager to ascertain the integrity of the process. A chart (or X-bar) is a tool to examine the
centering of the process. An R-chart measures the variations in the process. To determine the proportion
of nonconforming units, a P-chart can be utilized.

20.7.7 Scatter Charts

Scatter charts, as shown in Figure 20.7, are tools used to test the relationships between two sets of data. The
data is gathered and measured at the same time to examine possible correlations between variables. While
scatter charts do not validate the existence of a cause between the variables, a higher correlation suggests a
possible relationship (Pande, 2002). Further examinations of the possible relationships may help the engi-
neering manager to find a possible root-cause to any special variations found in the process. In Figure 20.7,
the trend line increases to the right. This is indicative that the variables have a positive correlation together.
This does not verify that the variables are related, just that they may have influence over each other.

Figure 20.7. Scatter Chart Reflecting Positive Correlations

357
Engineering Management Handbook

The scatter chart can also show when the correlations between the variables are not related. In these
circumstances, the chart trend line would either be a vertical or horizontal line. The scatter chart can also
visually indicate when there are negative correlations between the variables. Figure 20.8 shows an example
of negative correlations between two variables.

Figure 20.8. Scatter Chart Reflecting Negative Correlation

20.8 Quality Leadership and Teams

According to Kotter (1990), “Leadership complements management; it doesn’t replace it.” Managers
plan and budget, organize and staff, and control and problem solve. Managers are appointed and are
responsible for the efficient application of resources. Leaders envision and set direction, align people to
the vision, and motivate them to overcome obstacles to achieve the vision. A leader is an individual who
is recognized by others as the right person to lead an effort. A leader may or may not hold an appointed
management position.
Quality leadership is focused team outcomes toward accomplishment of the vision. As such quality
leadership is exercised through:
• Facilitation—Serving the needs of the team
• Appraisal—Helping the team compare options toward achieving the vision
• Forecasting—Providing independent and unbiased predictions of future outcomes given a set of
options for action
• Advising—Informing the team about facts of their problem(s) and suggesting best courses of action
• Enabling—Ensuring the team has the resources and authority to act on a selected course of action
• Following—Being an adherent devotee to the team’s success

Good quality leaders challenge the status quo, set an example of professionalism, and recognize and
celebrate team successes.
Quality improvement is accomplished through teams. A team is a group of people who perform in-
terrelated tasks toward accomplishment of a common vision or mission. There are seven basic team types
that can be involved in direct or indirect support of quality improvement.
• Process Improvement Teams—A project team that focuses on developing a new process or improving
an existing process through a breakthrough. These teams have a management sponsor who char-
ters the team and ensures that it has sufficient resources to accomplish its goal(s). The team has an
independent leader who meets with the team on a regular basis and a facilitator who works with the
organization to assist in successful project completion.
• Self-managed Teams—Groups of employees involved in directly managing the daily operations of
their process. They are authorized to make basic operational management decisions such as setting
objectives, assigning resources, and conflict resolution. The team members typically select their lead-
358
 What is Quality Management?

er, and leadership is rotated among members over time.

• Work Groups—Teams of employees who have responsibility for a particular process and who work
together in a participative environment. Team autonomy and authority can range from very limited
to a fully self-managed team. Team members are responsible to monitor and improve processes on an
ongoing basis.
• Cellular Teams—A work group whose process is organized into a cell. As opposed to the general
work group, cell team members are totally cross-trained in every process step. Cell team members
assume full responsibility for process ownership and improvement. Team effectiveness depends on
coordination, timing, and cooperation. The lead operator may or may not be rotated among team
members. The lead operator is responsible for training new team members, balancing the process
workflow, and reporting team output.
• Temporary/Ad Hoc Teams—Temporary cross-functional teams of required expertise established to
address a specific problem or situation.
• Special Project Teams—Groups formed to address long-duration projects such as implementing a new
product, process, or production facility. These teams may operate as a parallel organization. Core
team members are typically assigned for the project duration, and other personnel with special exper-
tise may be assigned to the project team, as their skills are required.
• Virtual Teams—Any team whose members do not work in the same geographic location and accom-
plish teamwork via an Internet virtual meeting space, telephone, and email.

20.9 References
Banasik, M., & Beruvides, M., “A Case Study of the costs of Quality: Water Utilities,” Engineering
Management Journal, vol. 24, no. 2, 2012, pp. 3-14.
Besterfield, Dale H., Quality Control. Upper Saddle River, NJ: Prentice Hall, 2001.
Bossert, James L., Quality Function Deployment: A Practitioner’s Approach. Milwaukee: ASQ Quality Press,
1991.
British Standards Institute, BS 5179, Guide to the Operation and Evaluation of Quality Assurance Systems,
1974.
British Standards Institute, BS 5750, Quality Systems, 1979.
Clinical and Laboratory Standards Institute, HS1-A2 Quality System Model for Healthcare, 2004.
Collier, D., and Evans, J., Quality Management. In South-Western Cengage Learning (5 ed.). Operations
Management (p. 334) Mason, OH, 2013.Defeo, Joseph, and Juran, Joseph M. Juran’s Quality Hand-
book: The Complete Guide to Performance Excellence. New York: McGraw-Hill, 2010.
Deming, W. Edwards., Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering Study,
1982.
Dennis, H., Componation, P., An Examination of the Trade Study Process at NASA. Engineering Manage-
ment Journal, vol. 16, no. 4, 2004, pp. 10-18.
Department of Defense, MIL-I-45208A, Inspection System Requirements, 1963.
Department of Defense, MIL-Q-9858, Quality Program Requirements, 1959.
Dodge, Harold F. and Romig, Harry G., A Method of Sampling Inspection. The Bell System Technical
Journal, vol. III, no. 4, October 1929.
Dodge, Harold F. and Romig, Harry G., Single and Double Sampling Inspection Tables. The Bell System
Technical Journal, no. 1, January 1941.
European Foundation for Quality Management, European Quality Award, 1992.
Evans, J., Foundations of Quality and Performance Excellence. In South-Western Cengage Learning (7
ed.). Quality and Performance Excellence (p. 11) Mason, Ohio, 2011.
Evans, J., and Lindsay, W., Statistical Methods in Quality Management. In South-Western Cengage
Learning (9 ed.). Managing for Quality and Performance Excellence (p. 272) Mason, Ohio, 2011.
Feigenbaum, Armand V., Quality Control: Principles, Practice and Administration. New York: Mc-
Graw-Hill, 1951.
Feigenbaum, Armand V., Total Quality Control. New York: McGraw-Hill, 1961.
359
Engineering Management Handbook

International Organization for Standardization, ISO 8402:1994 Quality management and quality assur-
ance – Vocabulary. http://www.iso.org/iso/catalogue_detail.htm?csnumber=20115.
International Organization for Standardization, ISO 9000:1987 Quality management systems, 1987.
International Organization for Standardization, ISO 9000:2000 Quality management systems, 2000.
International Organization for Standardization, ISO 9000:2015 Quality management systems, 2015.
International Organization for Standardization, ISO 13485:2003 Medical Devices – Quality Management
Systems – Requirements for Regulatory Purposes, 2003.
International Organization for Standardization, ISO 14001:2004 Environmental management systems,
2004.
International Organization for Standardization, ISO 15189:2003 Medical Laboratories – Particular Re-
quirements for Quality and Competence, 2003.
International Organization for Standardization, ISO/IEC 90003:2004 Software Engineering – Guidelines
for the Application of ISO 9001:2000 to Computer Software, 2004.
International Organization for Standardization, ISO/IWA-1:2005 Quality Management Systems – Guide-
lines for Process Improvements in Health Service Organizations, 2005.
International Organization for Standardization, ISO/TS 16949:2009 Quality Management Systems –
Particular Requirements for the Application of ISO 9001:2008 for Automotive Production and Relevant
Service Part Organizations, 2009.
Japanese Union of Scientists and Engineers, Deming Prize, 1951.
Juran, Joseph M. and Gryna, Frank M., Quality Planning and Analysis. New York: McGraw Hill, 1970.
Kotter, John P., What Leaders Really Do. Harvard Business Review, vol. 68, no. 3, 1990, pp. 103-111.
National Institute of Standards and Technology, Malcolm Baldrige National Quality Award, 1987.
Pande, P., Neuman, R., Cavanagh, R., Analyzing Data and Investigating Causes. In McGraw-Hill (1 ed.),
The Six Sigma Way (pp. 219-220) New York, 2002.
QuEST Forum, TL 9000: Quality Management System Requirements for Telecommunications. 1998.
Schroeder, R., Quality Control and Improvement. In McGraw-Hill Irwin (4 ed.), Operations Manage-
ment. (pp. 169-190), New York, 2008.
Shewhart, Walter A., Economic Control of Quality of Manufactured Product. New York: D. Van Nostrand
Company, 1931.
Shingo Institute at Utah State University, Shingo Prize for Excellence in Manufacturing, 1988.
Society of Automotive Engineers, AS9100 – Aerospace Basic Quality System Standard, 1999.
Westcott, Russell T. (ed.), The Certified Manager of Quality/Organizational Excellence Handbook. Milwau-
kee: ASQ Quality Press, 2006.

360
 Strategic Management

21
Strategic Management

Timothy G. Kotnour
University of Central Florida

361
Engineering Management Handbook

21.1 Introduction
21.1.1 Importance of Strategic Management to Engineering Managers
Why is strategic management important to engineering managers? Strategic management is important
to the engineering manager because the engineering manager needs to make decisions and take actions
consistent with the organization’s strategies. As a leader, the engineering manager will need to build
strategy for his or her group that is consistent with the organization’s overall strategy. Also, the engineering
manager will also contribute to the development of the organization’s strategy.

21.1.2 What is Strategic Management?

As shown in Figure 14.1, strategic management is defined to contain eight functions supported by a
core of three elements. Strategic management is a continuous process aimed at aligning everyday actions
with the organization’s long-term direction based on its customers’ needs. Using a strategic management
process produces positive results (Pekar and Abraham, 1995; Taylor, 1984; Waalewijn and Segaar, 1993;
Wilson, 1994). These findings indicate that strategic management is a key to providing organizations
long-term growth, profitability, and a sustained competitive advantage. However, barriers to strategic
management exist (Hahn, 1991; Sandy, 1991; Waalewijn and Segaar, 1993; Wilson, 1994). To manage
the organization’s strategy, an eight-step strategic management process is used. Strategic management is a
continuous process aimed at aligning everyday actions with the organization’s long-term direction based
on its customers’ needs. The strategic management process includes the functions of Strategic Planning,
Implementation Planning, Execution, and Performance Evaluation (NASA, 1996). We’ve expanded this
cycle by focusing on the interface or deployment phases between the four functions.
The strategic management process includes eight functions:
1. Set Strategic Intent is a group process (strategic planning) by which the organization defines or refines
the organization’s vision, mission, goals, and objectives.
2. Deploy the Strategic Intent is the set of activities to share the strategic intent throughout the
organization.
3. Set Strategy is the process (implementation planning) by which the organization develops specific
strategies and actions to implement the strategic intent and defines the specific performance
measures to track progress.
4. Deploy Resources assigns resources to the specific initiatives defined in Set Strategy.
5. Execute the Strategy is when the projects and activities are actually performed.
6. Deploy Results is the process by which the organization measures its performance in accomplishing
goals and objectives.
7. Review Performance is the process (performance evaluation) to review performance to produce lessons
learned and recommendations on how to improve the organization and adjust the strategic intent.
8. Deploy Learnings is the use of lessons learned and recommendations in the next cycle of strategic
management.

These functions can take place across many levels of the organization (e.g., the corporation, business
unit, division, or office). These eight steps provide the structured process for the management team to lead
and manage the strategic transformation path (i.e., continuously set strategy and make the strategy real).
Before we discuss each of these functions, we’ll explore the core of the process.

362
 Strategic Management

Figure 21.1. Strategic Management Process

1.
Set
Strategic 2.
8. Intent Deploy
Deploy
the Strategic
Learnings
Intent

7. open, honest 3.
Review conversations Set
Performance Strategy & Strategy
Measures

6. 4.
Deploy Deploy
Results 5. Resources
Execute
the Strategy

21.2 Strategic Management Process

21.2.1 Introduction
The tutorial below will help you get a better understanding of the concepts of strategic management. This
section presents information on the core of strategic management and the strategic management func-
tions. This basic section will help you better understand strategic management and also give you insights
and knowledge to help you read and interpret your organization’s strategic plan.

21.2.2 Core of the Strategic Management Process

At the core of the strategic management process are three elements:
• Open, honest conversations
• Strategy
• Measures.

Taken together, these three elements are what a transformation requires. A transformation requires a
management team holding conversations to develop a strategy for change. Measures translate the strategy
to concrete quantifiable outcomes. These measures help determine where the organization needs to go.
The management team uses the measures during conversations to help refine the strategy.

Strategic Management Core 1: Holding Open, Honest Conversations

The first core of strategic management is to hold open, honest conversations. Strategic conversations focus
on the organization’s ever-changing environment and how well the organization’s strategy is working. The
aim is to adjust the strategy to the environment. Having routine strategic conversations is important, but
equally importantly is the need to have these conversations in an environment in which people can talk
openly and honestly. The individuals in the conversation must feel that they can share their opinions without
fear of repercussions. If people are afraid of the ramifications of sharing their thoughts, they will not create
new paradigms or share “unfavorable” assessments of the external environment and internal workings of
the organization. (By unfavorable, I mean the conversations that go against the perceived thoughts of the
leadership or power team.) Many “unspoken” conversations will be left hanging. The needed conversations
363
Engineering Management Handbook

that get to core issues will be held in the halls and small groups, not in the larger management team where
actions need to be taken. Open, honest conversations are needed to raise and answer the fundamental issues
facing the organization. Without open, honest conversations, strategy is destined to fail—commitment and
involvement in the strategy will decrease. The specific conversations for each of the eight functions of strate-
gic management will be highlighted when we discuss each function in the next eight sections.
One challenge in holding continuous strategic conversations is finding the time to devote to them.
Annual management strategic offsites are one tool to hold these conversations, but the problem with stra-
tegic offsites is that they are held usually just once a year. Once the strategic offsite is over, people go back
to work on the daily, routine issues. The organization needs to find a way to hold strategic conversations
on a routine basis.

Strategic Management Core 2: Strategy

Before we spend a lot of time talking about developing, deploying, implementing, and evaluating strategy,
we first must define what we mean by strategy. The Merriam-Webster Dictionary defines strategy as:
• A careful plan or method
• The art of devising or employing plans toward a goal
• An adaptation or complex of adaptations that serves or appears to serve an important function in
achieving evolutionary success.

Using the work of Minztberg (1994), we can define strategy as the strategic intent of the organization
(e.g., mission, vision, goals) and the plan or pattern of decisions to implement the strategic intent on a
daily basis. Mintzberg (1994) defined strategy using four concepts:
• Strategy as a plan: A direction, guide, or course of action into the future, a path to get from here to
there
• Strategy as a pattern: Consistency in behavior over time
• Strategy as position: The determination of particular products in particular markets
• Strategy as perspective: An organization’s way of doing things—its concept of the business

Rumelt (2011) defined strategy as:

• “Good strategy is not just ‘what’ you are trying to do. It is also ‘why’ and ‘how’ you are doing it” (p. 85)
• “Strategy is at least as much about what an organization does not do as it is about what it does” (p. 20).

Mintzberg (1994) further defined the strategy concept by focusing on strategy that is implemented or
realized. Realized strategy is a function of four components:
• Intended Strategy (IS): the strategy we planned and intend to follow
• Deliberate Strategy (DS): the intended strategy implemented
• Unrealized Strategy (US): the intended strategy we abandoned
• Emergent Strategy (ES): the unplanned strategy that emerged over time

Therefore, strategy = realized strategy = DS + ES = IS – US + ES.

Using Mintzberg’s concepts, we define strategy to be of two types: strategic intent and daily strategy.
Strategic intent is the macro view to the organization’s position and perspective. The strategic intent is
typically defined by items such as a mission statement, vision statement, goals, and guiding principles.
This strategic intent provides the overarching theme to drive change in the organization. This strategic in-
tent is translated into everyday actions by what we call daily strategy. Daily strategy as a pattern or plan is
the use of planning tools to connect the strategic intent to a specific action. How well we align and imple-
ment both strategic intent and daily strategy is important. Daily strategy can be thought of as the projects
used to move the organization forward. Strategy (strategic intent and daily strategy) is made quantifiable
through the use of measures.

364
 Strategic Management

Strategic Management Core 3: Measures

Measures help translate the desired outcomes to quantifiable numbers that can be used to set strategy. To
further help clarify some of the more common products (i.e., mission, vision, goals, objectives, measures,
and strategies), we provide a graphical model to connect these terms. The mission and goals drive the
specific objectives or the measurable performance to accomplish. One way to define an objective is:

() (measure) by (amount) by (date).

This format provides a clear link to the measurable performance that is important to the organization.
These types of objectives drive both the daily work and improvement efforts. Figure 21.2 provides further
definition of how goals, objectives, measures, and strategies are related. Objectives translate the desired
outcomes into measurable performance criteria. The current versus desired performance is analyzed for
performance gaps. The root cause of the gap is used to define and select the improvement strategies.

Figure 21.2. Goals, Objectives, Strategies

What is the core business?

Vision
What is the ideal organizational Mission
state?
Stable

Why does
the Goal Goal Goal Goal
organization
exist?

What specific Change when

outcomes must be accomplish
Objective Objective Objective Objective
achieved to reach the measured
goal? performance
change

How will you take the steps? Strategy Change as

• Performance targets complete
What are the detailed steps?
• Project(s) specific
• Responsibilities efforts

Conversations, strategies, and measures are the core of the strategic management process. We’ll next
explore the eight steps or functions of the strategic management process.

21.2.3 Strategic Management Process Functions

The next eight sections review each function of the strategic management process. For each function, we
define:
• The function’s aim
• The strategic questions addressed in the function
• The function’s products
• The focus areas for executing the function
• The methods to use to execute the function.

From this understanding, a leader can set an agenda on how to implement strategic management to
help transform an organization.
365
Engineering Management Handbook

21.2.4 Setting Strategic Intent Through Strategic Planning

Overview
Strategic planning is a group process by which the organization defines or refines the organization’s strate-
gic context and intent. The process involves understanding both internal and external environments (e.g.,
strengths, weaknesses, opportunities, threats). Strategic planning through this disciplined process estab-
lishes the vision of the future, mission, and a specific set of goals, objectives, and policies developed in
response to customer requirements and the external and internal environment. In this section we explore
the aim, questions, products, focus areas, and methods for strategic planning.

Strategic Planning Aim

The aim of strategic planning is to develop good strategy for the organization. Good strategy:
• Reflects the reality of the environment
• Is agreed upon by the management team
• Is implemented
• Is based on the concepts of strategic thinking
• Achieves the desired outcomes of the organization.

Strategic planning requires a set of conversations to occur.

Strategic Planning Questions

In this step of the strategic management process, the following strategic conversations or questions need
to be addressed:
• Who are we?
• What is the state of our environment?
• Where are we today?
• Why do we need to change?
• Where do we want to be in the future?
• How do we get to our future?
• How will we lead?
• What is our evolution?
• What is guiding our thinking?
• What is the essence of our strategy?

Strategic planning answers fundamental questions about the environment and organization. These
questions and answers are more complex than they appear. The challenge is having the senior manage-
ment team (and later the entire organization) answer these questions in open, honest, and meaningful
conversations. The products associated with strategic planning are used to answer these questions.

Strategic Planning Products

We can divide the strategic planning products the products that are the inputs to and the outputs from
strategic planning.
The products that are inputs to strategic planning focus on giving the planning team the common un-
derstanding to produce the output products. The input products include assessment of the environment
and the organization. The output of strategic planning is an integrated set of “strategies, goals, objectives,
action items, action teams, and action plans to improve performance” (Sink and Tuttle, 1989, p. 39). The
output products include items focused on defining the organization’s strategic context (e.g., environment,
strategic assumptions, industry trends, scenarios) and the organization’s strategic intent (e.g., mission/core
business statement, vision/ideal future state, goals, and objectives).
366
 Strategic Management

Strategic Planning Focus Areas

When carrying out strategic planning, the organization needs to focus on developing good strategy that is
shared among and agreed upon by the management team. The strategic planning focus areas include:
• Learning from the past, present, and future
• Seeing changes in the external environment
• Understanding the issues facing the organization
• Converting strategic conversations to decisions and actions.

Learning from the Past, Present, and Future

The first focus area of strategic planning is to learn from the organization’s past, present, and future. The
organization must understand where it has come from and embrace lessons learned from the past. With-
out learning from past strategy attempts, the organization may repeat strategic mistakes. The organization
also needs to understand the factors that have led to the organization’s success to date, and who the orga-
nization is. Learning from the present explores where the organization is today, and provides the ground-
ing of current market position and organizational performance. Learning from the future refers to the
organization understanding the potential future scenarios facing it, and provides a basis for understanding
what the organization needs to become.

Seeing Changes in the External Environment

The second focus area of strategic planning is seeing changes in the external environment. An organization
needs to understand where the external world is going and what that means for the organization. The
organization needs to be able to connect the events into trends and then into implications for the orga-
nization and its business. The challenge is making sense of events and trends from a different perspective,
not from an old perspective that might no longer be the most acceptable, valuable, or relevant. When it
surveys its environment, an organization must be careful to not filter out or ignore events and trends that
don’t meet its commonly accepted perspectives or views. An organization that does not see a “sea change”
in the environment could miss threats and opportunities for the organization.

Understanding the Issues Facing the Organization

The third focus area of strategic planning is understanding the issues facing the organization. The organi-
zation needs to understand all of the issues facing it, from multiple perspectives:
• How relevant, responsive, and ready are we?
• How well are we externally positioned?
• Is our mission or vision relevant?
• How well are we internally aligned?
• How well is our strategic management process helping us position and align ourselves?

Answering these questions helps the organization pinpoint the changes it needs to make in its stra-
tegic intent, and the specific objectives and strategies it needs to pursue. The challenge is answering these
questions openly and honestly with the right data.

Converting Strategic Conversations to Decisions and Actions

The fourth focus area of strategic planning is converting conversations into actions. This focus area
is especially important for delivering the transformation. Once a strategic conversation occurs, the
organization needs to act to make the strategy a reality. Without action, the conversation doesn’t mean
much. I’ve been in strategic planning meetings where the group was looking to put action items togeth-
er at the end of the meeting, and the leader said, “No need to do that now, we can do that next week.”
At this point you could see the participants’ faces turn sour. They knew they had just wasted their time.
Once an action is identified, someone must be held accountable for completing it, and that account-
ability must be enforced.
367
Engineering Management Handbook

The intent of this section was to describe the strategic planning function. The strategic planning
function was described using its aim, questions, products, and focus areas. Once the strategic in-
tent is set through strategic planning, the strategic intent needs to be shared with the organization.

21.2.5 Deploying the Strategic Intent

Overview
Deploying the strategic intent is the process of sharing the strategic intent with the organization and its
stakeholders. Deploying the strategic intent helps the rest of the organization understand the organiza-
tion’s strategic context and intent. This understanding creates a foundation for the organization to make
plans to implement the strategic intent. In this section we explore the aim, questions, products, and focus
areas for deploying the strategic intent.

Deploying the Strategic Intent Aim

The aim of deploying the strategic intent is to develop throughout the organization a shared understand-
ing of the organization’s strategic context and intent. From this shared understanding the organization
raises issues and identifies challenges to successfully implement the strategic intent, and develops actions
for making the strategy succeed. To accomplish these aims through deploying strategic intent, a set of
conversations needs to occur.

Deploying Strategic Intent Questions

In this step of the strategic management process, the organization needs to address these strategic conver-
sations or questions:
• What is right with our strategy?
• What do we need to be aware of?

To answer these questions and deploy the strategic intent, the management team creates a set of prod-
ucts. To help management answer the questions above, the management team needs to answer another set
of questions:
• Who are the intended audiences for our strategic intent message?
• What is the purpose of our message?
• What is the message?
• What are the different approaches for sharing our message?

Answers to these questions help the organization design the methods to deploy the strategic intent.

Deploying the Strategic Intent Products

We can divide the products for deploying the strategic intent the products that are inputs to and the out-
puts from deploying the strategic intent function.
The products that are inputs to deploying the strategic intent focus on helping the organization
understand its strategic context and intent. The output of deploying strategic intent is the organization’s
insights, issues, and challenges to making the strategy real. The output products help the management
team understand where the roadblocks are and what issues the organization may have with the strategic
intent. These insights can help the management team adjust the strategic intent.

Deploying the Strategic Intent Focus Areas

When deploying the strategic intent, the organization will focus on two areas. These focus areas attempt
to ensure that the organization shares and understands the strategic intent that is developed. The focus
areas of deploying the strategic intent are:
368
 Strategic Management

• Sharing the message throughout the organization

• Understanding organizational concerns with the message.

Sharing the Message Throughout the Organization

The first focus area of deploying the strategic intent is sharing the message of the strategic context and
intent throughout the organization. Once set, the strategic intent needs to be shared with the organi-
zation. Without an understanding of the strategic intent, the rest of the organization does not have the
context or rationale for the actions the organization is taking. The organization needs to understand the
“why” and “what” of the strategy. The rest of the organization is usually the people who are implementing
the strategic intent. The challenge is ensuring that the entire organization gets the same message no matter
where they are in the organization, when they hear it, or who shares it with them. Once they understand
the strategic message, employees can give their feedback so that senior management can adjust the strategy
to ensure success.

Understanding Organizational Concerns

The second focus area of deploying the strategic intent is understanding the organization’s concerns with
the strategy. Once the strategy is developed, the organization needs to identify the challenges and issues
with implementing it. Those working on the front lines of the organization may have insights into these
issues and challenges. The management team needs to share the strategic intent and get feedback from the
rest of the organization. By understanding the implementation issues ahead of time, the organization can
adjust its strategic intent before it makes a mistake.
The intent of this section was to describe the deploy the strategic intent function. The deploy the stra-
tegic intent function was described using its aim, questions, products, and focus areas. Once the strategic
intent is shared and understood by the organization, the strategic intent needs to be made real through
more detailed planning.

21.2.6 Setting Strategy Through Implementation Planning

Overview
Setting strategy, or implementation planning, is the process by which the organization develops specific
strategies or actions to implement the strategic intent, and defines specific performance measures of the
progress of the planned actions. Implementation planning develops detailed plans and proposed resource
allocation to implement the goals, objectives, and strategies. In this section we explore the aim, questions,
products, and focus areas for implementation planning.

Implementation Planning Aim

The aim of implementation planning is to align the organization’s activities with the strategy. An organiza-
tion uses the implementation plan to guide day-to-day behaviors and execution. Implementation plan-
ning develops the specific, individual strategies to make the overall strategic intent a reality. To accomplish
these aims through implementation planning, a set of conversations needs to occur.

Implementation Planning Questions

The strategic conversations that happen during implementation planning help the organization translate
the strategic intent into specific actions. In this step of the strategic management process, the following
strategic conversations or questions need to be addressed:
• How do we define actions to move the organization forward?
• What are the potential improvement ideas?
• What are the potential daily business efforts?
• How do we convert our strategic intent to specific actions?
369
Engineering Management Handbook

• How do we get our employees to see their roles in the strategic intent?
• How do we get our employees to set specific performance expectations?

To answer these questions through setting strategy, a set of products is produced.

Implementation Planning Products

We can divide the implementation planning products into the products that are inputs to the outputs
from implementation planning.
The products that are inputs to implementation planning are the strategic intent products from stra-
tegic planning and the additional ideas from the information gathered from the deployment of the stra-
tegic intent. The outputs of implementation planning are the proposed actions that need to be resourced.
This set of actions can be described using four “buckets”:
• The normal, day-to-day processes to administer today’s business
• The improvement initiatives that cut across the organization—the big projects that reflect the projects
the leader will put his or her energy into
• The specific improvement initiatives each organization needs to take on as part of a corporate-wide
initiative (e.g., involvement in ISO)
• The specific improvement initiatives each organization needs to take in relation to its specific respon-
sibilities.

These initiatives need to be evaluated, selected, and resourced. The organization does not have enough
resources to invest in all of these areas, so it must focus on aligning these efforts to the strategic plan.

Implementation Planning Focus Areas

In executing the implementation planning function, the organization will focus on three areas. These focus
areas convert the strategic intent into actionable plans. The implementation planning focus areas include:
• Converting the strategic intent to operational terms
• Aligning organizational roles
• Aligning objectives and measures.

Converting the Strategic Intent to Operational Terms

The first implementation planning focus area is converting the strategic intent to operational terms, which
are the specific objectives, measures, and actions that make the strategic intent a reality. The organization
must make decisions and take actions that move the organization from its current state to the desired
state. As defined earlier, the strategic intent contains items such as vision and goals to define the end or
desired state. The best way to define the actions is to first explicitly define the objectives and measures. A
quantifiable objective can be defined as {increase or decrease} {measure} by {amount} by {date}. The objec-
tive defines the gap to be closed—the amount of the measure to be changed by a given date. With good
objectives and measures, the organization can make the strategy more realistic. After defining objectives
and measures, the organization can then define strategies. As discussed earlier, measures are a core part of
the strategic management process. The challenge facing the organization is to take the high-level strategic
intent, as defined by vision, mission, goals, and transformation path, and turn it into very specific objec-
tives, measures, and strategies.

Aligning Organizational Roles

The second focus area of implementation planning is aligning roles in the organization to the strategic in-
tent. In deploying the strategic intent and implementation planning, organizational sub-units and employees
will want to know how they fit within the strategy. To foster understanding and commitment to the strategic
intent, the management team needs to help employees see how their contributions relate to the strategy. The
challenge is helping the employee answer three basic questions for the work he or she does:
370
 Strategic Management

• Why do I do this work?

• What do I need to accomplish with this work?
• How do I do the work?

By working with employees, the management team aligns employee roles to the strategic intent of
transforming the organization.

Aligning Objectives and Measures

The third focus area of implementation planning is aligning objectives and measures across the organiza-
tion. This begins with aligning the organization’s overall objectives and measures with any higher-order
organization. The organization must then align the internal objectives and measures of each sub-unit with
the organization’s overall objectives and measures.
The intent of this section was to describe the implementation planning function. The implementation
planning function was described using its aim, questions, products, and focus areas. Once the potential
projects and activities are defined by the organization, the organization needs to select and resource the
efforts that it will implement.

21.2.7 Deploying Resources

Overview
Deploying resources is the process of allocating the organization’s limited resources to the strategy. This
allocation is made against the four types of activities defined in the implementation planning function. In
this chapter we explore the aim, questions, products, and focus areas for deploying resources. Deploying
resources is important because:
• The organization’s resources are limited
• Not all activities can be funded
• Any expected outcome to be achieved must have resourced activities to deliver the outcome. That is,
an outcome cannot be expected to be achieved unless resources are assigned or deployed to it.

Deploying Resources Aim

The aim of deploying resources is to put the right resources on the right activities to move the organiza-
tion forward with its strategy. The strategy process can absolutely fail in this step. If the organization does
not explicitly devote resources and accountabilities to the strategy, the strategy will fail. Many times, orga-
nizations hold strategic offsites, define actions, and then fail to put the necessary resources on the strategy.
Deploying resources is crucial to strategy—in fact, all four of the deployment functions are the linkages or
breaking points of the strategy process.
As discussed in the strategic thinking section, the organization is using its resources to meet today’s
business while investing in activities to move it to the future. To accomplish these aims through deploying
resources, a set of conversations needs to take place.

Deploying Resources Questions

To help select and resource the efforts, the management team needs to assess the efforts from an organiza-
tion-wide perspective by asking questions. In this step of the strategic management process, the following
strategic conversations or questions need to be addressed:
• What are the funded improvement ideas?
• What are the funded daily business efforts?
• How will we select and prioritize efforts?
• What are the criteria for selecting the efforts?
• What is the filter for selecting the efforts?
371
Engineering Management Handbook

To answer these questions through deploying resources, a set of products is produced.

Deploying Resources Products

We can divide the products for deploying resources into the products that are the inputs to the outputs
from deploying resources.
The inputs to deploying resources are (1) the set of potential efforts related to the daily work that must
continue, (2) the set of potential improvement projects to pursue (i.e., the portfolio of potential improvement
efforts), and (3) the set of criteria to evaluate the efforts. The output from this step is the set of resourced im-
provement projects and the daily work to execute. This step also defines the daily work to stop doing.

Deploying Resources Focus Areas

The organization will face many challenges when deploying resources. These challenges center on funding
the strategy within a constrained resource environment. The deploying resources focus areas include:
• Selecting efforts
• Funding the investment to reach the vision.

Selecting Efforts
The first focus area of deploying resources is selecting the right efforts to fund and deploy resources to.
We can look at deploying resources from a funnel perspective. Coming into the funnel are the potential
efforts from the implementation function. The size of the top of the funnel is driven by the number of
projects or efforts. The size of the bottom of the funnel, and thus, how many of the proposed initiatives
get through the funnel, is based on the amount of resources that can be applied to the organization’s
strategy. The organization faces the challenge of balancing multiple responsibilities with limited resourc-
es. Deploying resources is where this challenge comes to a head. The challenge in deploying resources is
selecting the right portfolio of efforts across four areas:
1. Meeting the requirements of today’s mission.
2. Building the business—investing in areas to improve and change the business.
3. Meeting the requirements of the evolving or new mission.
4. Catering to crisis.

As part of the selection process, the organization needs to find the resources to allocate to the efforts
the organization chooses to implement.

Funding the Investment to Reach the Vision

The second focus area of deploying resources is funding the investment to reach the vision. Because the
organization is challenged to find the resources to invest in multiple areas, it needs to find “excess” capaci-
ty to invest in emerging areas. Excess capacity can be gained from stopping current activities. The organi-
zation needs to find the resources to fund the selected efforts. Without funding, the improvement efforts
will not be implemented.
The intent of this section was to describe the deploy resources function. The deploy resources func-
tion was described using its aim, questions, products, and focus areas. Once the potential projects and
activities are selected and resourced, the organization needs to implement these efforts.

21.2.8 Executing the Strategy

Overview
Execution is carrying out the strategy and implementation plan. Execution is the process of producing the
outputs and outcomes for the organization customers. Execution is where the “rubber meets the road”—
meeting accountabilities for the strategy. One challenge is that everyday business activities will overrun
372
 Strategic Management

efforts to execute the strategy of transforming the organization. In this section we explore the aim, ques-
tions, products, and focus areas for executing the strategy.

Executing the Strategy Aim

The aim of execution is to deliver on the strategy and make it real by delivering on the efforts to close the gaps
or delivering on the objectives defined earlier. As defined earlier, this aim is met through the execution of:
• The normal, day-to-day processes to administer today’s business
• The improvement initiatives that cut across the organization—the big projects that reflect the projects
the leader will put his or her energy into
• The specific improvement initiatives each organization needs to take on as part of a corporate-wide
initiative (e.g., involvement in ISO)
• The specific improvement initiatives each organization needs to take in relation to its specific
responsibilities.

To accomplish these aims through execution, a set of conversations needs to occur.

Executing the Strategy Questions

In this step of the strategic management process, the following strategic conversations or questions need
to be addressed:
• What are the improvement initiative plans?
• What are the daily business plans?
• What do we need to accomplish?
• How do we ensure we meet expectations for products and services?
• How do we ensure we meet expectations for the improvement projects?
• How do we put the right resources on execution?
• How well are we accomplishing what we need to accomplish?

To answer these questions through execution, a set of products is produced.

Executing the Strategy Products

We can divide the products for deploying resources into the products that are inputs to and the outputs
from executing the strategy.
The input products are the approved and resourced/funded efforts. The outputs from the execution
are the specific products/services delivered from the efforts and the results or measures that describe how
well the efforts were performed.

Executing the Strategy Focus Areas

In executing the execution function, the organization will face many challenges. These challenges focus on
driving accountability. The execution focus areas include:
• Aligning and delivering processes
• Delivering improvement projects.

Aligning and Delivering Processes

The first focus area of execution is aligning the organization’s processes to the strategy. Processes are the
means by which the organization carries out and manages work. These processes need to be aligned to
where the organization is going. The challenge is determining which processes to start, stop, and continue.
For processes that will continue, there is a second set of decisions that need to be made: whether the pro-
cesses will continue as is, will be improved, or will be re-engineered. By stopping processes or improving
processes, the organization can find the resources necessary to invest in future activities.
373
Engineering Management Handbook

Delivering Improvement Projects

The second focus area of execution is delivering the improvement projects. During implementation plan-
ning and deploying resources, specific projects are funded to carry out the strategy. The organization faces
the challenge of executing these projects. The day-to-day efforts of delivering today’s mission and meeting
the requirements of today’s customers will often overrun these efforts. The organization must maintain
focus on these projects and ensure that they are completed. Projects that build or improve the business are
the lifeblood of the future of the organization.
The intent of this section was to describe the execution function. The execution function was de-
scribed using its aim, questions, products, and focus areas. Once the efforts are being implemented, the
results from the efforts need to be measured and gathered to support performance evaluation.

21.2.9 Deploying Results

Overview
Deploying results is the process of gathering performance measurements from across the organization for
an organization-wide performance evaluation. In deploying results, the organization is getting the results
from the execution so that the management team can understand how well they are making the strategy
real. In this section we explore the aim, questions, products, and focus areas for deploying results.

Deploying Results Aim

The aims of deploying results are to gather the results for performance evaluation and to drive account-
ability for completing the efforts to meet the objectives. To accomplish these aims through deploying
results a set of conversations needs to occur.

Deploying Results Questions

In this step of the strategic management process, the following strategic conversations or questions need
to be addressed:
• What are we accomplishing on the improvement initiatives?
• What are we accomplishing on the daily business activities?
• How do we convert actions/efforts to results?
• How will we measure performance?
• How will we collect and analyze performance data?
• How do we share the results throughout the organization?

To answer these questions through deploying results a set of products is produced.

Deploying Results Products

We can divide the products for deploying results into the products that are inputs to and the outputs
from deploying results.
The input products are the results from the execution phase. These can be actions and measurable
results. The outputs are the actual reports on the actions taken and results (e.g., standard formats for
performance metrics).

Deploying Results Focus Areas

In deploying results, the organization will face many challenges. These challenges focus on understanding
how well the strategy is being executed. The deploying results focus areas include:
• Measuring performance
• Rolling up results.

374
 Strategic Management

Measuring Performance
Measuring performance is about collecting the performance data and converting it into information. The
challenge is first determining what to measure and then how to get the measures. As we discussed earlier,
measures are at the core of strategic management. When we translate the strategy into operational terms
we are defining the desired outcomes we want with the objectives and measures. In deploying the results
we are collecting the data to develop the measures. The challenge is ensuring that the measures are collect-
ed and analyzed for performance evaluation.

Rolling Up Results
Once individual efforts have been measured, the second focus area is to roll the results up from individ-
ual efforts into overall organizational performance. The organization’s performance and outcomes are a
function of the integration of many actions. The organization needs to roll these individual outcomes into
a higher-level perspective to gauge overall performance.
The intent of this section was to describe the deploy resources function. The deploy resources func-
tion was described using its aim, questions, products, and focus areas. Once the efforts are being mea-
sured, the results need to be evaluated.

21.2.10 Reviewing Performance Through Performance Evaluation

Overview
Performance evaluation is how the organization measures and evaluates whether the organization achieved
intended results. Performance measurement and evaluation produces tangible results that can be stud-
ied to produce lessons learned and recommendations for improving the organization and adjusting the
strategic plan. In this chapter we explore the aim, questions, products, and focus areas for performance
evaluation.

Performance Evaluation Aim

The aims of performance evaluation are (1) to understand how well the strategy is being achieved, (2) to
understand where the areas for improvement are, (3) to identify lessons learned, and most importantly,
(4) to drive accountability for achieving results. Without reviewing performance, accountability cannot be
achieved—a necessary step for results is accountability and reviewing performance. To accomplish these
aims through performance evaluation a set of conversations needs to occur.

Performance Evaluation Questions

In this step of the strategic management process, the following strategic conversations or questions need
to be addressed:
• How well are we accomplishing the improvement initiatives?
• How well are we accomplishing the daily business activities?
• How do we understand performance and the learnings from the results?
• How do we understand the true reasons for a performance gap?

To answer these questions through performance evaluation a set of products is produced.

Performance Evaluation Products

We can divide the products for evaluating performance into the products that are inputs to and the out-
puts from evaluating performance.
The inputs are the original strategy and the performance measures that describe how well the strategy
is being achieved. The outputs include the lessons learned, the items to be continued, and the opportuni-
ties for improvement.
375
Engineering Management Handbook

Performance Evaluation Focus Areas

In evaluating performance, the organization will face many challenges. These challenges focus on understanding
what the results mean to the organization and strategy. The performance evaluation focus areas include:
• Reviewing performance
• Understanding performance gaps.

Reviewing Performance
This first focus area is an obvious one, but the one most often forgotten. The strategy and results need to
be evaluated. The organization must make the time, energy, and environment available to conduct the
reviews. The reviews are a meeting in which basic questions are asked and answered using the measures
developed and shared in the deploying results stage. However, the right environment for conducting the
performance evaluations must be created.

Understanding Performance Gaps

Given that progress has been measured and a meeting has been held to review the performance, the orga-
nization needs to be able to get to the root cause of any performance gaps. However, the learning required
to identify the true root cause may not happen. The challenge for the management team is to ensure that
the learning loop is completed and not abandoned.
The intent of this section was to describe the performance evaluation function. The performance eval-
uation function was described using its aim, questions, products, and focus areas. Once the performance
is evaluated, the results from the evaluation need to be shared with and used by the organization.

21.2.11 Deploying Learnings

Overview
Deploying learnings is the process of sharing the results (i.e., decisions) from performance evaluation to
continue to drive the strategy throughout the organization. In this section we explore the aim, questions,
products, and focus areas for deploying learnings.

Deploying Learnings Aim

The aim of deploying learnings is to close the loop of the strategy process and support further execution
and adjustment of the strategy.

Deploying Learnings Questions

In this step of the strategic management process, the following strategic conversations or questions need
to be addressed:
• What changes to the daily business do we need to make?
• What changes to the improvement initiatives do we need to make?
• How do we share learnings throughout the organization?
• How do we use the learnings to reinforce or stop efforts?

To answer these questions through deploying learnings a set of products is produced.

Deploying Learnings Products

We can divide the products for deploying learnings into the products that are the inputs and the outputs
from deploying learning.
The inputs are the findings and decisions from the performance evaluation. The outputs are the best
practices to share and institutionalize throughout the organization, and the opportunities for improve-
376
ment. To accomplish these aims through deploying learnings a set of conversations needs to occur.
 Strategic Management

Focus Areas for Deploying Learnings

In deploying learnings, the organization will face many challenges. These challenges focus on adjusting
the strategy. The deploying learnings focus areas include:
• Institutionalizing best practices
• “Killing” non-performing projects.

Institutionalizing Best Practices

As the organization tries new approaches and implements new projects to move forward, some of them will
produce positive results. The organization needs to identify these internal “best practices” and institutionalize
the new methods. The organization is growing to the future, therefore it needs to share the “seeds” that are
fostering this growth. The challenge is identifying and institutionalizing these best practices.

“Killing” Non-Performing Projects

The second focus area of deploying learning is “killing” non-performing projects. As with best practices,
the organization is trying new methods. Not all efforts will meet performance requirements. The organiza-
tion needs to decide to stop these actions. As others have discussed (Royer, 2003), stopping projects is not
always completed. The organization needs to stop these projects and reinvest the resources in other efforts.
Strategy is a learning process and adjusting the strategy by stopping some items is just as important as
starting new ones.
The intent of this section was to describe the deploy learnings function. The deploy learnings
function was described using its aim, questions, products, and focus areas. Once the learnings are
shared, the organization needs to implement these learnings in the next round of the strategic and
implementation planning functions. This last function closes the loop of the cyclic strategic manage-
ment process.

21.3 Bibliography and References

The following sources can be useful to help you further understand strategy and organizational transfor-
mations.
• Planning and Measurement in Your Organization of the Future by D. Scott Sink and Thomas Tuttle
• The Strategy Focused Organization by Robert S. Kaplan and David P. Norton
• Beyond Strategic Vision by Michael Cowley and Ellen Domb
• Team-Based Strategic Planning by C. Davis Fogg
• Scenario Planning: Managing for the Future by Gill Ringland
• The Rise and Fall of Strategic Planning by Henry Mintzberg
• Building a Shared Vision by C. Patrick Lewis
• The Art of the Long View by Peter Schwartz
• Hoshin Kanri by Yoji Akao
• The Art of Framing by Gail T. Fairhurst and Robert A. Sarr
• Storytelling in Organizations by John Seely Brown, Stephen Denning, Kataline Groh, and Laurence
Prusak
• The Story Factor by Annette Simmons
• Smart Thinking for Crazy Times by Ian Mitroff
• Don’t Jump to Solutions by William B. Rouse
• Smart Choices by John S. Hammind, Ralph L. Keeney, and Howard Raiffa
• Keeping Score by Mark Graham Brown
• Performance Scorecards by Richard Y Chang and Mark W. Morgan
• Improving Performance by Geary A. Rummler and Alan P. Brache
• Organizational Learning: A Theory of Action Perspective by Chris Argyris and Donald A. Schon
• The Knowing-Doing Gap by Jeffrey Pfeffer and Robert Sutton

377
Engineering Management Handbook

Hahn, D., “Strategic management—Tasks and challenges in the 1990s,” Long Range Planning, vol. 24,
no. 1, 1991, pp. 26-39.
Kaplan, Robert and Norton, David, Balanced Scorecard, Harvard Business School Press, 1996.
Mintzberg, Henry, Rise and Fall of Strategic Planning. Free Press, 1994.
National Aeronautics and Space Administration, 1996, NASA Strategic Management Handbook, Washing-
ton, DC.
Pekar, P., and Abraham, S., “Is strategic management living up to its promise?” Long Range Planning,
vol. 28, no. 5, 1995, pp. 32-44.
Royer, Isabelle, Why Bad Projects Are So Hard to Kill, Harvard Business Review, February 2003.
Rumelt, Richard P., Good Strategy, Bad Strategy: The Difference and Why It Matters. New York: Crown
Business, 2011.
Sandy, W., “Avoid the breakdowns between planning and implementation,” The Journal of Business Strat-
egy Sept./Oct., 1991, pp. 30-33.
Sink, D. Scott and Tuttle, Thomas, Planning and Measurement in Your Organization of the Future, Insti-
tute of Industrial Engineers, 1989.
Taylor, B., “Strategic planning—which style do you need?” Long Range Planning, vol. 17, no. 3, 1984,
pp. 51-62.
Waalewijn, P., and Segaar, P., “Strategic management: The key to profitability in small companies,” Long
Range Planning, vol. 26, no. 2, 1993, pp. 24-30.
Wilson, I., “Strategic planning isn’t dead—It changed,” Long Range Planning, vol. 27, no. 4, 1994,
pp. 12-24.

378
 Innovation and Entrepreneurship

22
Innovation and Entrepreneurship

Shereazad Jimmy Gandhi

California State University – Northridge

Nakul Sharma
California State University – Northridge

379
Engineering Management Handbook

22.1 Introduction
There has been a great deal of attention paid to the subject of entrepreneurship over the past few years,
stemming primarily from the discovery by economic analysts that small- and large-scale enterprises con-
tribute considerably to economic growth and vitality. Moreover, many people have chosen entrepreneurial
careers because doing so seems to offer greater economic and psychological rewards as compared to doing
a 9-to-5 job. To understand entrepreneurship, we need to first understand what it means to be an entre-
preneur and also understand the term “intrapreneurship.” Most people think being an entrepreneur is all
about coming up with a marketable idea. But what’s more important than coming up with an idea is how
to reach interested sets of customers in an effective and affordable way to provide value to the customer.
An entrepreneur is someone who can take an idea, whether it is a product or service, have the will, skill
and courage to take extreme risks to do whatever it takes to turn that concept into reality and not only
bring it to market, but also make it a viable product or service that people want or need. In a similar role
to that of entrepreneurs, intrapreneurs are the drivers of innovation within larger firms as they seek to
provide new products/solutions to unique market driven demands/problems by taking risks within their
scope of work. In fact, it is often taking on intrapreneurial tasks that allow someone to build the skill
needed to eventually become an entrepreneur. Entrepreneurship is the willingness to take risks, develop,
organize and manage a business venture in a competitive global marketplace that is constantly evolving
(Di-Masi, 2015). Simply put, entrepreneurship is the art of turning a unique idea into a business. A good
entrepreneur must have the ability to recognize talented intrapreneurs.

22.2 Entrepreneurial Mindset and Qualities of an Entrepreneur

Whether you are part of an existing business or are getting ready to launch your own business, one of
your most pressing priorities is how to develop and strengthen your entrepreneurial mindset. Regardless,
of whether you want to start your own business or take ownership of your job as if it is your own busi-
ness, in today’s world if you want your organization to move past beyond the point of just striving to
survive between a plethora of competitors, then you must have an entrepreneurial mindset to differentiate
yourself. For most engineering managers who work in technical firms, an entrepreneurial mindset for
themselves as well as their team members is what will help them differentiate their firm from the competi-
tion and thus create a competitive advantage that they could capitalize on.

22.2.1 So What Exactly Is Entrepreneurial Mindset?

The entrepreneurial mindset refers to a specific state of mind that orientates human conduct toward
seeking opportunities, taking risks to realize those opportunities and have the tenacity to push an idea
through to make it a reality. Individuals with entrepreneurial mindsets are often drawn to opportunities,
innovation and new value creation. Thus, the entrepreneurial mindset is an asset that would be useful for
starting your own business or to create further value within an existing business.
Entrepreneurial characteristics include high problem-solving skills, having a creative mindset, and the
ability to take calculated risks or at times taking high risks with an acceptance toward failure. It is import-
ant to note that this does not mean being reckless but on the contrary refers to taking an educated risk.
An acceptance toward failure allows an entrepreneur/intrapreneur to take moderate risks and make quick
decisions. Procrastination, caused by excessive fear of failure, can lead to missed opportunities. Self-con-
fidence is a quality that could lead to successful entrepreneurs as they do not dwell on failure, but on
the contrary they maintain their self-belief by accepting that there are some factors beyond their control
(Emerson, 2015). Effective communication skills enable entrepreneurs to have the ability to influence,
convince and inspire various stakeholders involved in the process. Entrepreneurs should have integrity
and charisma; should be excellent delegators as well as have the ability to identify an opportunity before
everyone else and act on it. Lastly, perseverance, self-motivation and acceptance to change and tolerance
for ambiguity are qualities that entrepreneurs need to instill in themselves if they are going to be success-
ful. Simply put, an entrepreneurial mindset demonstrates initiative, creativity and leadership.

380
 Innovation and Entrepreneurship

22.3 Functions of an Entrepreneur

An entrepreneur performs a series of functions necessary right from the genesis of an idea up to the estab-
lishment and effective operation of the enterprise. They recognize the commercial potential of a product
or service, formulates operating policies for production, product design, marketing and organizational
structure. They are thus the nucleus for high growth of the enterprise (Kumar, 2015). Few of the func-
tions of an entrepreneur are shown in Figure 22.1.

Figure 22.1. Functions of an Entrepreneur

Marketing
opportunities To gain
perceptions, Obtain command Human Upgradation
marketing of financing for over scarce
Purchasing relationship of procedures
product & a new raw material
imputs development & production
response to venture and inventory (HRD) quality
competition control

Some of the major functions of an entrepreneur can classified into three broad categories:
1. Managerial Functions
An entrepreneur performs a variety of managerial functions like determination of business objectives,
formulation of production plans, product analysis and market research, competitor analysis, organization
of sales procuring machine and material, recruitment of personnel and the undertaking of business oper-
ations. He or she also undertakes the basic managerial functions of planning, organizing, coordinating,
staffing, directing, relationship management, motivating and controlling in the enterprise (Kumar, 2015).
Though in large establishments, these managerial functions of the entrepreneur are delegated to managers
for more effective and efficient execution.

2. Decision Making and Organizational Function

The most vital function of an entrepreneur is focusing on decision making in various fields of the enter-
prise he or she leads. The entrepreneur is the decision maker of all activities of the enterprise. He deter-
mines the business objectives suitable for the enterprise at that moment of time according to the needs of
the market. He decides when to secure adequate financial resources for the organization and maintains
good relations with the existing and potential investors and financiers; he or she decides when to intro-
duce advanced modern technology in the enterprise to cope up with changing scenarios of the manu-
facturing process. Entrepreneurs seek disequilibrium—a gap between the wants and needs of customers
and the products and services that are currently available. The entrepreneur then brings together the
factors of production necessary to produce, offer and sell desired products and services (Kumar, 2015).
An entrepreneur is one who combines the land of one, the labor of another and the capital of a third and
thus produces a product. He or she brings together various factors of production and ensures continuing
381
Engineering Management Handbook

management. An entrepreneur is an organizer who alone determines the lines of business to expand and
capital to employ more judiciously. He or she is the ultimate judge in the conduct of the business.

3. Innovative and Risk Bearing Function

Part of innovative mindset is to ask the right questions to be able to understand and then meet customer
needs. An entrepreneur/intrapreneur needs to clearly understand what the customer wants. To keep up
with changing market scenarios and to keep being market leader, the basic function an entrepreneur needs
to perform is to innovate and come up with new products, services, ideas or information for the enter-
prise. As an innovator, the entrepreneur/intrapreneur foresees a potentially profitable opportunity and
tries to exploit it (Kumar, 2015). He or she is always involved in the process of exploring new options and
creating new products/services to meet unfulfilled needs. An engineering manager would be responsible
for recruiting and managing intrapreneurs within a project team/organization so that they can create new
value by tapping into the unmet needs of the organization’s customer base.

Whenever a new idea occurs, entrepreneurial efforts are essential to convert the idea into practical
product or service to fulfill the customers’ needs. The entrepreneur/intrapreneur assumes all possible risks
of business that emerges due to the possibility of changes in the tastes of consumers, modern techniques
of production and new inventions. Such risks are not insurable and are incalculable. In simple terms such
risks are known as uncertainty concerning a loss. Risk tolerance or uncertainty bearing remains one of the
most important functions of an entrepreneur/intrapreneur, which he or she tries to minimize by initiative,
skill and good judgment. An engineering manager is also very likely to need these skills when the team is
embarking on creating a new product or service, offered by their organization.

22.4 Intrapreneur
An intrapreneur is a relatively recent concept that focuses on employees of a company that have many of the
attributes of an entrepreneur. Obviously there have always been go-getters in companies who try to move the
needle forward and push the status quo, but never before has there been such a push for employees to take
ownership of their own corner of a company. This means creating a new division or launching a new initia-
tive within the company. An intrapreneur is someone within a company that takes risks in an effort to solve
a given problem or create something new from scratch (Newlands, 2015). These are those highly valuable
executives and team members who have learned to apply the essential principles of entrepreneurship to the
roles they fill within the company. These aren’t employees trying to do better at their existing jobs or move
up the ladder; this is them wanting to create something new that does not currently exist. Intrapreneurs are
not afraid to change course, nor fear failure. It is not outward bravado that drives them but an inner con-
fidence and courage that every step takes them closer to their ultimate goal. Intrapreneurship is the act of
behaving like an entrepreneur while working within a large organization.

22.4.1 Difference between Entrepreneur and Intrapreneur

The distinction between entrepreneurs and intrapreneurs can be seen as a difference in the level of focus.
While an entrepreneur should see the company as a vision from starting point to end; the intrapreneur is
a facet of this broader vision. The intrapreneur works within the company to solve specific problems, thus
intrapreneurs must have more directly applicable skills for a given task. They will take risks, but within the
context of their job in the company. Intrapreneurs, unlike the entrepreneurs, are not focused on the entire
company, but rather processes within it. Intrapreneurs are the drivers of innovation within companies. In
a similar role to that of entrepreneurs, intrapreneurs seek to provide solutions to unique market-driven
problems. They seek policies, technologies and application that resolve a barrier to productivity increas-
es (Newlands, 2015). Like the entrepreneur who starts a company with the goal of providing a good or
service, the intrapreneur takes on a task within the company to increase the capacity of the company.
Intrapreneurs certainly respect the value and importance of money. They understand the economic drivers
that allow the organization to succeed and are able to support this fundamental truth and not fight it.
382
 Innovation and Entrepreneurship

One should really understand how intrapreneurship and entrepreneurship are linked. In fact, it is
often taking on intrapreneurial tasks that allows someone to build the skill needed to eventually become
an entrepreneur. Basically, intrapreneurship is the first step on the ladder to becoming an entrepreneur.
Successful intrapreneurs understand trends; they see where the company needs to go before anyone else.
Any successful company must have a number of intrapreneurs to see future trends and meet them before
their competitors do. As Intrapreneurs build the aptitude to recognize and solve important problems they
build the skills necessary to one day start a company (Newlands, 2015). A company must be aware of its
most successful intrapreneurs, it must recognize and promote them as soon as possible. It is through this
recognition that a company will succeed and grow. Intrapreneurs are the most fundamental component
of an innovative and growing company as they require intrapreneurs at each level to solve problems and
integrate each process into the greater whole. Intrapreneurs see the ability to grow personally along with
the company and in this sense, should be seen as investors in a company, rather than just employees. An
intrapreneur is someone who grows with the company. A company grows when they find a balance be-
tween in the virtuous cycle of entrepreneurs hiring intrapreneurs. A good entrepreneur recognizes talented
intrapreneurs and as they are promoted they in turn recognize good intrapreneurs below them. As this
cycle continues, the company is bound to become a true leader in innovation.

22.5 Innovation and Its Importance in Entrepreneurship

Innovation is like the lifeline of any organization. Innovation helps companies adapt to market changes,
technology changes, survive recessions and create whole new market opportunities. Innovative companies
generally create higher profits, higher stock values and they also create more jobs. Since innovation helps
create a competitive advantage for companies, all organizations are keen to create an “innovation culture”
so they can stay ahead of the competition; however, this is easier said than done. Being innovative does
not include the mere adoption of new procedures and guidelines in daily work schedules or the R&D
department working in isolation to come up with new innovative ideas so as to make the company higher
profits. Innovation involves the whole company working together in a coherent setup to achieve a com-
mon goal and maintaining a competitive advantage on a sustainable basis. Most of the significant inven-
tions of the past two centuries have not come from flashes of inspiration but from collaborative endeavors
that are outcomes of an entrepreneurial mindset.
Below are a few points that can help companies create a corporate culture that is more conducive to
innovation.
1. One of the most common causes for new product failure is the failure to meet customer needs. People
working in each department of a company would know something essential about customer needs
but their knowledge would be partial. Sales people would understand the buying and selling process.
Engineering and R&D would know everything about product functionalities. Supply chain would
understand procurement processes, trends and planning, but it is necessary to merge all these depart-
mental perspectives together into a complete package. Each of the departments mentioned should
think innovatively and try to evolve on a continuous basis. Furthermore, new product development
teams cannot work in isolation to develop revolutionary products and it is impractical to develop a
new product sequentially, handing work off from one department to another. It is necessary to put
together multifunctional teams that are a combination of individuals from different departments of
a company, working together on all phases of product development, to “define, design, develop and
launch” new products. It is everyone’s job to innovate and contribute his or her expertise to the collec-
tive effort of new value creation.
2. Another way to inject innovation into the heart of the company is to incentivize the innovation
process. Companies should introduce high reward system to recognize the employees that drive
innovation. This incentive program serves the company twofold; firstly, it makes the employees feel
valued and recognized; secondly it encourages the other employees to take similar innovative actions.
Whether through employee recognition events, staff wellness activities, or any other ways, an organi-
zation should communicate that it values innovative contributions made by its employees. Another
way of making this scheme more personalized is to ask employees at the beginning of the year about
383
Engineering Management Handbook

their specific needs, as to what they would like to have as their reward for being innovative. A desired
outcome/reward can have a huge impact on employee’s orientation toward implementing innovation
and ultimately meeting the company’s goals.
3. Tolerance toward failure is another contributor to the success of major companies. Failure is not an
end point, but can be thought of as a source of learning and continuous improvement. Incremental
innovation is the process of taking small steps over a period of time toward a large breakthrough.
Incremental innovation cannot happen without incurring failures. Discouraging failure within the
organization could have catastrophic outcomes for the growth of the company. An organizational cul-
ture that values creativity, provides space for dialogue and can leverage lessons learned from failures, is
well on its way to building a culture that is innovative in nature.

Research has shown that two countries namely United States and China have the highest number
of new startups every year and also have most number of companies doing breakthrough innovations as
compared to any other region in the world. The reason behind the success of startups in these two coun-
tries is that these countries nurture innovative culture within their organizations and they give autonomy
to their employees for being innovative and take steps accordingly. They encourage people to think out of
the box and take risk at the stake of failure. By establishing easy and accessible communication opportuni-
ties, such as employee newsletters and suggestion boxes, leadership can gain access to important feedback,
and the better your organization can articulate what is and what is not working, the quicker it can work
toward reaching innovative solutions and move forward.
Figure 22.2 presents the six stages of innovation process that takes ideas from inception to impact. It
may vary from industry to industry.

Figure 22.2. Innovation Process - Six Stages (modified from - https://bia.ca/from-vision-to-reality-the-innova-

tion-process/)

384
 Innovation and Entrepreneurship

22.6 Innovation: The Likely Cause of Successful Sustainable Businesses

The key to a successful business and to remain successful on a sustainable basis is to come up with new
ideas to keep products, operations and services fresh so that consumers find them attractive. The process
of bringing these ideas to reality is called innovation. While thinking up new ideas is one step of the
process, businesses feel a much greater challenge in trying to convert those ideas into an actual product
or service that will benefit customers (Brooks, 2013). The companies that do this best are the ones that
ultimately sustain and succeed in market. Companies that take the largest risks, close the biggest gaps and
identify the newest opportunities are rewarded with the biggest market shares and are titled as true inno-
vators by their consumers. Such companies create customer satisfaction, which in turn creates
brand loyalty.
Truly innovative companies have a very small risk of losing its customer base to newcomers in the
market. If customers are offered new or improved products consistently, which continue to meet their
needs, then there is a significantly reduced probability that those set of customers will lose interest in that
particular company. For example, Apple has a strong following, despite the fact that Apple has only one
phone to offer, it still controls the biggest share in smartphone market. This is due to the fact that Apple
consistently keeps innovating and launching better products every year, whereas companies that stagnate
or struggle with innovation like Nokia see their fortunes dissolve within short span of time. Customers
now are more aware and more demanding. They always need something new and something fresh, and if
the demand for something new is not met, they do not shy away from moving to other products. In order
to successfully innovate, businesses need to install the strategies that best fit their needs and goals.

22.6.1 Types of Innovation

As an engineering manager, you could consider a number of frameworks to look at different types of in-
novation. When trying to be innovative, businesses can choose from a variety of different strategies. Each
offers advantages and disadvantages.
a. Disruptive: Disruptive innovation is when new products or services start out at the bottom of the
marketplace but ends up eventually moving up and displacing their competitors. Initially, a disruptive
innovation is formed in a niche market that may appear unattractive or inconsequential to indus-
try incumbents, but eventually the new product or idea completely redefines the industry (Brooks,
2013). Examples of disruptive technology include mobile phones being developed as a replacement
for home phones. Mobiles were not highly welcomed when they first hit the market, but over time, as
they improved on the original designs, they eventually took over the existing market.
b. Reverse: Reverse innovation is when products or services are developed first for use in developing na-
tions and after their success in those markets they are launched in developed markets (Brooks, 2013).
Examples of reverse innovation include dried noodles that Nestle developed for use in Asian markets
but eventually became so popular that it took all over the world.
c. Incremental: Incremental innovation is when companies make small changes to products and ser-
vices to ensure they keep and grow their share in the marketplace. Rather than changing the product
line or services completely, incremental innovation simply builds upon and betters what already exists
(Brooks, 2013). Examples of incremental innovation can be the mobile phone or automobile produc-
ers, which periodically update their products by introducing new features and technology.
d. Breakthrough: Breakthrough innovation, also commonly referred to as radical innovation, is de-
veloping a completely new idea or concept that doesn’t currently exist in the market. This could be
applicable to products, services or processes. Often developed by research and development teams,
breakthrough innovations use new technology as a way to quickly climb to the top of new markets
(Brooks, 2013). The Internet is a very good example of breakthrough innovation.
e. Open: Open innovation is when companies use internal and external ideas to help advance their
operations. With external ideas a firm can take help from either its suppliers or third parties to help
advance the company’s technology offerings. Internal ideas means that at times company employees
can come up with breakthrough ideas and can help the firm in modifying or completely revamp-
ing the process by which it does its operations or handles services to help save the company money
385
Engineering Management Handbook

(Brooks, 2013). When developing a complex product that involves many sub-technologies, such as an
automobile, this kind of innovation occurs frequently.

22.6.2 Factors Affecting Innovation

In the past, many organizations have been able to survive even with very limited amounts of innovation.
They focus on providing quality products and simply update them to a level that maintains their competi-
tiveness in the market. This method still applies to some products with long lifecycles and few opportuni-
ties for innovation. But more recently, some trends have emerged that make innovation process absolutely
necessary for any organization to primarily sustain its business and then grow it further (Innovation: The
Basics, 2015). Due to factors such as globalization and outsourcing, there is an increased push to improve
efficiency and effectiveness of organizations.
Organizations need more than good products to survive; they require innovative processes and man-
agement that can drive down costs and improve productivity. Although every organization will have its
own priorities and sector-specific issues to balance, businesses that fail to innovate run the risk of losing
ground to competitors, losing key staff, or simply operating inefficiently. To put a positive spin on innova-
tion, it can be described as the primary need for the advancement of society around the world. New and
innovative products can increase the standard of living and provide people with opportunities to im-
prove their lives. Breakthroughs in medicine and technology have significantly improved living standards
around the world. Innovation has also lead to significant improvements in the way businesses operate and
has closed the gaps between different markets. Below are a few factors that drive innovation:

a. Consumer Expectation
Consumer expectations drive the amount of innovation in the market to a major extent. Customers are
used to products that continually improve and make their life easier. Modern consumers are more in-
formed and have more options in terms of what they buy and who they buy it from. Essentially, cus-
tomers will not accept mediocrity because they know they can always go somewhere else. This keeps
companies under mounting pressure to continuously innovate and introduce new products and services
ever faster. Being late to the market is simply not acceptable by the customers as by the time an identical
product reaches the market consumers expect the next thing to be the next big thing—and when it is not,
they do not hide their disappointment.

2. Rising Competition
Innovation can be a key differentiator between market leaders and their rivals. Innovation is also driven
by the amount of innovation your competitors are doing. Being first to market with a new product can
provide you with a significant advantage in terms of building a customer base. It is difficult to compete if
your products are seen as obsolete or out of date. Also, it is difficult to compete with the innovation levels
of a large multinational as they have surplus fund that they can pour into innovation process as compared
to a startup or a mid-size industry. Innovation is the key to differentiate your product from the compe-
tition. If you can’t compete on price, you’ll need innovative products and ideas to make your business
stand out from the crowd. Your customers may be willing to pay more for your well-designed, novel and
innovative product or service, rather than choosing a cheaper, but less exciting rival.

22.7 Metrics to Measure Innovation

To improve the level of innovation in your business, first you need to assess where you currently stand.
You should be aware of your strengths and weaknesses and understand how they impact what you are able
to achieve. You also need to assess the potential within your team for innovation as well as ensure that you
have the right kind of employees, which refers to people who are creative, knowledgeable and motivated
to develop new ideas to find solutions to existing problems. It is also important that you provide your
employees with the resources they need to create and develop new ideas. Identifying the people who are
likely to be creative will help you to delegate tasks effectively.
386
 Innovation and Entrepreneurship

Assessing your organization’s level of innovation means looking at your past successes and failures. Try
to work out what made one project a success, and where other similar projects did not work out. Look
for areas that your company can improve upon and try to learn from past mistakes. Looking at ideas that
did not work previously might give an insight for trying new methods this time around, and it might also
provide you with ideas that did not work in the past because of situations like technology vacuum or not
having the right people for the task, but may have a sound future potential now. Sometimes an idea will
fail simply because of mismanagement or poor timing. Some of these ideas could be updated or adapted
and given a second chance.
When assessing your organization’s level of innovation, also consider the amount of innovation
coming from your competition, as well as what is happening in the market. This will help you to decide
whether or not you are being innovative enough to remain competitive. Consider whether or not your
organization is focusing a sufficient amount of time and resources into developing new ideas. How many
employee ideas are actually followed up on after they are initially brought forward? Many organizations
miss out on opportunities because they do not put enough effort into developing good ideas. An innova-
tion audit takes into account the opinions of your customers and your employees. Work out how much
you have invested in innovation over a period of time and compare that to the amount of return you have
received from your investment. A thorough understanding of your organizations level of innovation can
help you achieve the title of market leader.

22.8 The Design Thinking Process

The design thinking process was developed at the Design School at Stanford University that engineering
managers have to be aware of design thinking so they can facilitate the process to help team members
function innovatively and think outside the box to maintain a competitive advantage. The process starts
by first defining a problem and then implementing the solution, always keeping the needs of the user
demographic at the core of concept development. This process focuses on need finding, understanding,
creating, thinking, and doing (Stanford Design Thinking Process, 2012). At the core of this process is a
bias toward action and creation, which says that by creating and testing something, you can continue to
learn and improve upon your initial ideas. It consists of five steps as shown in Figure 22.3.

Figure 22.3. Design Thinking Process (Source: http://dschool.stanford.edu/dgift/)

EMPATHIZE: In this step you try to understand your customers, within the context of your design chal-
lenge. It is your effort to understand the way they do things and why they do it, understand their physical
and emotional needs, understand how they think about world, and what is meaningful to them. Work to
387
Engineering Management Handbook

fully understand the experience of the user for whom you are designing. Observing what people do and
how they interact with their environment gives you clues about what they think and feel. It also helps
you learn about what they need. By watching people, you can capture physical manifestations of their
experiences—what they do and say (Stanford Design Thinking Process, 2012). Engaging with people
directly reveals a tremendous amount about the way they think and the values they hold. Sometimes these
thoughts and values are not obvious to the people who hold them, and a good conversation can surprise
both the designer and the subject by the unanticipated insights that are revealed.

DEFINE: In this step of the design process is all about bringing clarity and focus to the design space.
Process and synthesize the findings from your empathy work in order to form a user point of view that
you will address with your design. The goal of the define mode is to craft a meaningful and actionable
problem statement. This statement should be a guiding statement that focuses on insights and needs of a
particular user, or composite character. The define mode is critical to the design process because it presents
your point of view regarding the problem you are striving to address (Stanford Design Thinking Process,
2012). More importantly, your point of view defines the right challenge to address. If not defined clearly,
you may end up addressing a noncritical problem rather than a critical one.

IDEATE: Ideate is the mode of the design process in which you concentrate on idea generation. Ideation
provides both the fuel and the source material for building prototypes and getting innovative solutions
into the hands of your users. Explore a wide variety of possible solutions through generating a large quan-
tity of diverse possible solutions, allowing you to step beyond the obvious and explore a range of ideas. In
ideation you combine the understanding you have of the problem space and people you are designing for
with your imagination to generate a possible solution concept. Particularly early in a design project, ide-
ation is about pushing for a widest possible range of ideas from which you can select, not simply finding
a single, best solution (Stanford Design Thinking Process, 2012). The determination of the best solution
will be discovered later, through user testing and feedback.

PROTOTYPE: The prototype mode is the iterative generation of artifacts intended to answer questions
that get you closer to your final solution. A prototype can be anything that a user can interact with.
Transform your ideas into a physical form so that you can experience and interact with them and, in the
process, learn and develop more empathy.

TEST: The test mode is when you solicit feedback about the prototypes you have created from your users
and have another opportunity to gain empathy for the people you are designing for. Testing is another
opportunity to understand your user, but unlike your initial empathy mode, you have now likely done
more framing of the problem and created prototypes to test (Stanford Design Thinking Process, 2012).
Try out products and use observations and feedback to refine prototypes, learn more about the user, and
refine your original point of view.

22.9 The Entrepreneurial Process

There are many ways to organize the effort of planning, launching and building a venture, but there are a
set of fundamentals that must be covered in any approach. It is useful to break the entrepreneurial process
into seven phases. Figure 22.4 represents the seven steps of any entrepreneurial process starting from in-
ception of idea until the launch of the business. Although it is natural to think that the early steps might
occurring sequentially, but they can actually proceed in parallel in some cases.

388
 Innovation and Entrepreneurship

Figure 22.4. Stages of Entrepreneurial Process (modified from Entrepreneurship: Successfully Launching New
Ventures by Bruce R. Barringer/R. Duane Ireland, 2012)

22.10 How Can Small/Medium Enterprises (SMEs) Incorporate Innovation

Small businesses, startups and to a certain extent medium-sized businesses are the breeding grounds for
innovation. While some people think of creativity and innovation as just theories, a significant amount of
small business owners become complacent and let their business run its course, but in the long run have a
lot of lost opportunities, which they could have acted on. On the contrary, those entrepreneurs who have
a passion for growth, know that innovation means survival in today’s competitive marketplace. Innovation
requires creative ways of looking at problems and is absolutely necessary for survival and growth (John-
ston, 2015). Unhindered by the same tethers that hold down big businesses, small companies are free
to innovate in ways that their larger counterparts cannot. In fact, they don’t have the financial means to
accomplish many of their goals, and thus they need to find creative means to become bigger.
Small business owners and serial entrepreneurs who understand the relationship between a satisfied
customer, increasing revenues and innovation are able to exploit it to achieve financial success. Under-
standing pain points of larger businesses, creating innovative solutions and then developing those solu-
tions into a scalable product will undoubtedly attract attention of larger companies. This can result in
company buyouts, leases, licensing agreements, or partnerships that can provide financial windfalls for the
389
Engineering Management Handbook

small business (Templeman, 2014). Big corporations are constantly on the hunt for smaller startups that
can fill a void.
The biggest advantage small businesses have over larger counterparts is their agility to change their oper-
ating processes and thus meeting changing customer needs in a relatively short period of time. A large man-
ufacturing unit that does mass production cannot quickly change their operations but a small manufacturing
unit can, which puts them in a position of advantage over large businesses while taking new or surprise
orders. Small businesses can improve their customer experience in a multitude of ways, but the best innova-
tion delivers value to the market as soon as humanly possible. As a small business owner, one has immediate
access to the customer experience and can focus on innovative efforts in their direction right away.
Cross-fertilization is critical to delivering successful innovation, as great ideas generally come from
unique and sometimes unrelated combination of sources (Marshall, 2013). Big companies might struggle
to gather outside ideas or have trouble sharing knowledge due to departmental silos. A small business does
not suffer these impediments. Owners and managers of small businesses can easily reach beyond their
operations and involve customers, friends, and external experts.
Small businesses cannot win against the big ones if they do not have big resources to back them up—
but they can win in a niche to which they are willing to dedicate all of their attention. Big companies
trying to juggle tons of products and services often tend to give them all “some” attention, but never as
much as they probably deserve (Roberge, 2012). Small businesses can win the niche market while the big
companies are distracted because of their multiple points of focus. Once a small business is established as
subject matter expert on that niche, it will have the audience and credibility to expand on from there into
more product or service offerings.

22.11 Continuous Improvement

Continuous improvement process is a systems approach to improve the work flow in an organization (see
Figure 22.5 for a typical process). Continuous improvement processes allow project team members to
uncover problems and determine ways to fix them. Through careful analysis, team members can see how
individual tasks impact a business’s overall process. Because project teams work closely together, work
group conflicts can also be resolved as a part of the continuous improvement effort.
Typical phases of the model include an analysis phase to identify specific problems. During this
phase, teams conduct brainstorming sessions and interviews to gather relevant information. The next
phase is called the design phase. Here the project team determines what to do to remedy the problems
(Duggan, 2015). During the implementation phase, the team members responsible for carrying out the
tasks take action. Finally, during the evaluation phase, team members monitor the outcome and deter-
mine if the adjustment to the process has produced the desired result.

Figure 22.5. Continuous Improvement Process (from www.govirtualoffice.com/vision/process-improve-

ment/)

390
 Innovation and Entrepreneurship

22.12 Competitive Advantages for the U.S.

As mentioned previously companies must innovate in order to keep ahead of their competitors. If an or-
ganization wants to create a business strategy that keeps it at the forefront of innovation, it must develop
ways of making that strategy work. Development and growth of any economy is directly proportional to
the innovation happening within that society. If there is no development or no new innovation happening
within an economy, then it is destined to crumble or lag behind other innovative economies. Crisis is con-
nected with the very notion of innovation and Greece is the best example of such an economy. There have
been no major technological breakthroughs that have happened in Greece in past 15 years. In the U.S.,
on the other hand, is crowned as the hub for innovation. The U.S. has the highest number of successful
startups coming up every year. The culture within the U.S. economy has always been of nurturing innova-
tion. You cannot know beforehand if an innovation will work well in a market or not, and the companies
in U.S. encourage people to go out of the way to innovate. The best example for this is the Apple iPhone.
Apple didn’t know if the iPhone would work or not before launching it in the market. The only option
they had was to launch the product in the market and see the results. Launching the iPhone could have
had catastrophic outcomes for Apple, since it was the only company at that time to switch to complete
touchscreen phones, but it ended up completely revolutionizing the phone market.

22.13 References
Di-Masi, Paul, http://www.gdrc.org/icm/micro/define-micro.html (Accessed on August 12, 2015).
Duggan, Tara, “Continuous Improvement Process Definition” Demand Media, http://smallbusiness.
chron.com/continuous-improvement-process-definition-4534.html (Accessed on October 12, 2015).
Elkhodary, Mohamed, “12 Tips to Delegate Tasks Effectively,” https://www.linkedin.com/pulse/12-tips-
delegate-tasks-effectively-mohamed-elkhodary (Accessed on September 21, 2015).
Emerson, Melinda, “How to Cultivate an Entrepreneurial Mindset” -http://succeedasyourownboss.com/
cultivate-entrepreneurial-mindset/, (Accessed on August 14, 2015).
“Innovation: Key to Successful Business,” http://www.businessnewsdaily.com/5167-innovation.html (Ac-
cessed on August 20, 2015).
“Introduction To Design Thinking Process Guide,” https://dschool.stanford.edu/sandbox/groups/dresour-
ces/wiki/welcome/attachments/8e447/d.school’s%20Design%20Thinking%20Process%20Mode%20
Guide.pdf?sessionID=925299ef8e28277a661b9d9ea530db2e1490a68b (Accessed on September 22,
2015).
Johnston, Kevin, “How to Incorporate Creativity into Your Business Practice,” Demand Media, http://
smallbusiness.chron.com/incorporate-creativity-business-practice-56286.html (Accessed on Septem-
ber 29, 2015).
Kulkarni, Madhura, “Drab to Exciting: Easy tips for success at work,” https://www.linkedin.com/pulse/

391
Engineering Management Handbook

drab-exciting-simple-guide-corporate-success-madhura-kulkarni?articleId=5992224708714651648
(Accessed on September 12, 2015).
Kumar, Chinmoy, http://www.preservearticles.com/201101143322/functions-of-an-entrepreneur.html
(Accessed on August 14, 2015).
Marshall, Drew, “How Small Businesses Can Drive Big Innovation”, https://www.washingtonpost.com/
blogs/on-small-business/post/how-to-breed-big-innovation-inside-a-small-business/2013/03/26/
b1a8953e-962a-11e2-9e23-09dce87f75a1_blog.html (Accessed on October 1, 2015).
Newlands, Murray, “10 Things Entrepreneurs Need to Know about Intrapreneurship” - http://www.inc.
com/murray-newlands/10-things-entrepreneurs-need-to-know-about-intrapreneurship.html (Ac-
cessed on August 12, 2015).
Roberge, Mark, “7 Ways Small Businesses Can Compete With the Big Guys,” https://www.salesforce.
com/blog/2012/12/7-steps-for-small-businesses-to-compete-with-the-big-guys.html (Accessed on
October 1, 2015).
Templeman, Mike, “Innovation: Small Businesses Live It, Big Businesses Buy It,” http://www.entrepre-
neur.com/article/231962 (Accessed on October 1, 2015).
“The Design Thinking Process,” http://dschool.stanford.edu/redesigningtheater/the-design-thinking-pro-
cess/ (Accessed on September 22, 2015).
Tracy, Brian, “The Role of the Entrepreneur,” http://www.entrepreneur.com/article/78478 (Accessed on
August 20, 2015).
“Why business innovation is important,” https://www.business.qld.gov.au/business/business-improve-
ment/becoming-innovative-business/why-business-innovation-important (Accessed on August 29,
2015).

392
 Supply Chain Management for Engineering Managers

23
Supply Chain Management for
Engineering Managers

Shereazad Jimmy Gandhi

California State University – Northridge

Marina Lemos Fajardo

Universidade Federal de Juiz de Fora

393
Engineering Management Handbook

23.1 Introduction
23.1.1 Definition of a Supply Chain
Supply chain involves all parts of the product manufacturing or providing of a service until it gets to con-
sumers, including the raw material from suppliers, the manufacturing process, distribution including to
wholesalers, retailers and consumers. As reported by Beamon B. (1998), a supply chain is “a structured
manufacturing process where raw materials are transformed into finished goods, then delivered to the
end customers.” In order for this to be achieved, all the parts, from raw material suppliers to distribution,
retailers and consumers, must be connected and have good communication among them because each one
depends on one another to achieve their end goal of providing the customer a quality product. Providing the
customer with a “quality product” could include providing the customer with the quantity of goods/services
needed, in the time required and simultaneously reduce costs associated with the product/service to provide
the customer the best value. A supply chain is the network among all companies that have influence on the
product; this includes suppliers, manufacturers, distributors and retailers. Most products are not produced
entirely by one organization, so every company that has contact with the product or service provided is
included in the supply chain. A number of supply chain definitions are provided in Table 23.1.

Table 23.1. Varying Definitions of Supply Chain as Provided by Different Authors

Author Supply Chain Definition

Little, A. (1999) “The combined and coordinated flows of goods from origin to final destination,
also the information flows that are linked with it.”
“Supply chain is the group of manufacturers, suppliers, distributors, retailers and
Chow, D. and Heaver, T. (1999) transportation, information and other logistics management service providers that are
engaged in providing goods to consumers. A Supply Chain comprises both the external
and internal associates for the corporate.”
Supply chain is defined as “life cycle processes involving physical goods,
Ayers,J. B. (2001)
information, and financial flows whose objective is to satisfy end consumer requisites
with goods and services from diverse, connected suppliers.”
Mentzer, J., Witt, W. D., Keebler, Supply chain is “a set of entities (e.g., organizations or individuals) directly
J., Min, S., Nix, N., Smith, D. & involved in the supply and distribution flows of goods, services, finances, and
Zacharia, Z. (2001) information from a source to a destination (customer).”

As an engineering manager, you can see that even though there is a universal understanding of what a
supply chain is, there are different definitions of a supply chain and hence you have to pick the definition
that is most applicable to your organization.
Figure 23.1, as adopted from John Gattorna (2013), depicts the functions that could be included in
a supply chain:

Figure 23.1. Supply Chain Organizational Pyramid (Adapted from Gattorna, 2013)

Value
Perceived

Design of the Supply Chain

Chain Network

Planning end- Sourcing,

Logistics
to-end Production
Operations
operations and inventory

Skills,
Information Capabilities and Process and Great
Technology Organization Procedures Performance

394
 Supply Chain Management for Engineering Managers

From an engineering management perspective, from Figure 23.1 it can be seen that functionally, a
supply chain, if used correctly, can contribute toward supporting an organization as well as make a positive
impact on the operational, structural and strategic aspects of the organization. An engineering manager has
to be aware of this big picture and the impacts that a supply chain could have, to implement it correctly and
help the project or department that he or she is in charge of, to add value to the organization.

23.2 Supply Chain Management

According to the Council of Supply Chain Management Professionals (2015), “Supply chain management
encompasses the planning and management of all activities involved in sourcing and procurement, conver-
sion, and all logistics management activities. Importantly, it also includes coordination and collaboration
with channel partners, which can be suppliers, intermediaries, third party service providers, and customers.”
Supply chain management does not include only the supply of products, but also the demand of it within
companies. The term supply chain management is sometimes confused with logistics, which is one of the
parts of supply chain management. The logistics of supply chain includes warehousing and transportation.
It is crucial to keep less inventory, reliable and worthy transportation, and good communication among
the partners. The Council of Supply Chain Management Professionals (2015) further states that, “Logistics
management is that part of supply chain management that plans, implements, and controls the efficient,
effective forward and reverses flow and storage of goods, services and related information between the point
of origin and the point of consumption in order to meet customers’ requirements.” Part of the logistics
operations includes when a company stocks raw materials or products, moves the goods from area to area, or
transports the goods to retailers. The supply chain management focuses on all connections among industries
to deliver value to customers, reducing costs and achieving a “sustainable competitive advantage,” according
to Dr. Robert Handfield (2011). Handfield also stated that, “The organizations that make up the supply
chain are ‘linked’ together through physical flows and information flows.” Hence, as an engineering manager
understanding that information flow is also a critical part of the supply chain is necessary.
Supply chain management includes the coordination of product, information, and finance flow among
all organizations and entities included in the supply chain. The objective of good supply chain management
is to have a smooth flow of products and information and have lower inventory in an industry. The outcome
of this would likely be a reduction in cost of production, which is a saving that can be passed on to the
customer; thus resulting in a competitive advantage related to cost. In today’s competitive global business
environment, it should be evident to an engineering manager that creating a competitive advantage for one-
self based on price can make the difference between success and failure, as costs and consequently the selling
price, dictate a lot of things such as profit margins, sales volumes and market share.
Based on the above-mentioned importance of cost, many strategies can be used to reduce costs. It is
important to optimize the supply chain, and the company needs to incorporate strategies to achieve opti-
mization and reduce costs. According to Kauffman and Crimi (1998), those strategies include “reduction
of the number of suppliers, reduction of overall inventory in the system, improved packaging, handling,
and transportation, reduced process cycle times as well as use of pull instead of push material supply sys-
tems.” Reducing the number of suppliers is a practice that many companies, like Apple, are implementing
to lower the costs associated with managing a complex supply chain and thus reduce the overall cost asso-
ciated with the product. Before implementing any strategy, it is important to know all the costs associated
with the supply chain of the company involved. As an engineering manager, it is his or her responsibility
to calculate all costs, including the freight, handling, inventory carrying as well as duty, shipment costs,
among others. Once the company knows where it should lower the costs, it needs to design a supply
chain strategy and work toward lowering the costs. However, while it does this, it also needs to consider
any risks that may arise due to changes made to the supply chain. The parts of supply chain are sourc-
ing, manufacturing, logistics and sales. The manager needs to identify which one he or she should focus
on, such as in the sourcing area where the company can be competitive in negotiating the price with the
providers of raw material. According to L.N. Balaji (2013), supply chain network design is a good model
to reduce costs because “it incorporates end-to-end supply chain cost, including purchase, production,
warehousing, inventory and transportation.” Balaji (2013) also stated that the individual objectives in
395
Engineering Management Handbook

the supply chain, which are the objectives of each of the constituents of the chain (improve quality for
example), need to meet the company objectives and it is important to analyze and define in which sector
of the whole chain each strategy would be applied. Some of the objectives of the chain are having con-
stant demand volume, full truckload and flexibility in customer services. Those objectives sometimes are
opposites among the companies that composes the chain, so that they need to analyze strategically the
sourcing, manufacturing area, logistics and sales role of the business.
One of the points to implement a lean supply chain and lower costs is that all companies involved need to
have a holistic perspective of the whole chain. In a holistic view, the company can see an extended supply chain,
which contains the suppliers of its suppliers and the customers of its customers. Figure 23.2 shows the use of a
suppliers, inputs, process, outputs, and customers (SIPOC) diagram, which is an overview of the process.

Figure 23.2. SIPOC Diagram (Adapted from Corbett, 2012)

By virtue of obtaining an extended supply chain and the SIPOC diagram, it is possible to create a
value chain. According to Andrew Feller, Dan Shunk, and Tom Callarman (2006), “…the primary focus
in value chains is on the benefits that accrue to customers, the interdependent processes that generate
value, and the resulting demand and the flow of funds that are created.” Companies in a value chain have
their focus in the customer’s customer and is worried about their requirements and in what they see value.
The authors also stated that, “the customer is the source of value, and value flows from the customer, in
the form of demand, to the supplier.”
According to John Hatton (2013), in order to reduce costs “high-tech companies such as Apple,
grocery retailers including Tesco and online distributors such as Amazon have emulated these achieve-
ments and become highly respected exemplars of lean supply.” The SIPOC diagram can be useful to build
a holistic view of the whole chain that the company is involved. With this view an engineering manager
could clarify the understanding of what the value chain is, how he or she is managing it and what needs
his or her attention. It is an important way to be focus on what really brings value to the customer.

23.3 Lean Supply Chain

According to Manrodt, Thompson, and Vitasek (2008), lean supply chain is “a set of organizations direct-
ly linked by upstream and downstream flows of products, services, finances and information that collab-
oratively work to reduce cost and waste by efficiently and effectively pulling what is needed to meet the
needs of the individual customer.” It is important that all the partners of the supply chain understand the
benefits of implementation of lean will generate for them. A lean supply chain is complicated and to see
the benefits, it is essential that whole of the company is involved and aligned.
In his article, Hatton (2013) establishes some steps to implement a lean process and some principles
to lead to a lean supply chain:
1. Specify “value,” from the view of the customer: this is a key point to understand for an engineering
manager. That value should be perceived from the customer perspective and hence the customer
should be a stakeholder involved in the process of incorporating a lean supply chain. The customer
should be involved in the decisions related to deciding what is value added and non-value added.
396
 Supply Chain Management for Engineering Managers

2. Identify all steps in the process, eliminating those steps that do not create value.
3. Run the “value steps” in tight sequence, so the product flows smoothly toward the customer.
4. As part of continuous improvement, reiterate and continue the process until value is created with
minimal waste.
5. Involve people: engage the companies to improve continuously through waste elimination and prob-
lem solving.
6. Build in quality: engineer processes by using concepts such as poka-yoke, to make them mis-
take-proof; thus preventing errors before they happen.
7. Reduce lead times: establish a continuous flow of materials, equipment and process such that prod-
ucts are pulled through the supply chain at the right place, the right time and in the right quantity.
8. Standardize: document the best practices and make sure they are followed.

Manrodt et al. (2008) also stated some additional points that could enhance lean supply chain success:
1. Use success stories to promote a better understanding of the value of lean within the supply chain to
get better buy-in from your suppliers.
2. Lean education and training must be expanded outside your organizational boundaries and should
include your suppliers as well.
3. Management and practitioners must step up efforts to improve collaboration and partnership
throughout the supply chain.
4. There must be a set of metrics and benchmarks for validating the benefits of lean. This is key because
if the benefits cannot be measured and portrayed, it is challenging to keep the suppliers involved.
5. All firms involved must monitor and report on performance.

Figure 23.3 summarizes the key components necessary to build and maintain a lean supply.

Figure 23.3. Attributes of Lean Supply Chain (Adapted from Mandrot et al., 2008)

Demand
Management

Collaboration
Reduce Waste
Besides
and Cost
Companies
Lean
Supply
Chain
Industry Standardization
Standardization of the Process

Transformation
of Culture

23.4 Importance of Supply Chain Management for Industries

An efficient implementation of supply chain management is essential to maintain organizational pro-
ductivity and ultimately influences customer satisfaction. It could possibly have a resultant effect on the
quality and timely manner in which the product would be delivered to the customer. The optimization
of operations is the primary goal for good supply chain management. This is because it can deliver goods
397
Engineering Management Handbook

in less time, lesser cost and reduces risks. Using software and tools to decrease complexity of the supply
chain is important. A good example is how communication can be improved by using cloud computing.
Another important way to optimize is collaboration between manufacturer and supplier. Ravi Shankar
(2011) stated that, “This will help organizations reduce inventory, improve fulfillment rates and product
availability at point of purchase and ensure a lean supply chain improving margins and profitability.” Ac-
cording to Stan Mack (2015), the company can increase its competitive advantage by delivering a product
“as fast and as cheaply as possible without sacrificing quality.” He also claims that it is not easy and “top
companies accomplish this by using complicated logistics tools, such as computer algorithms that choose
optimal routes for product shipping and large company databases that allow distant employees to pool
order information and coordinate their efforts in real time.”
Another important point of an efficient supply chain management is that the company gains power
to negotiate with other organizations, including suppliers and retailers. In order to negotiate with sup-
pliers and retailers, companies can make agreements around large quantities of products in exchange for
more competitive unit pricing. The companies involved in the partnership should establish the expecta-
tions it has with each one of its supply chain members. For example, if a company needs to buy a huge
amount of raw material from a supplier, both organizations can negotiate a better price and establish a
contract to purchase a certain quantity at a fixed price for the duration of the contract. It can also lead to
exclusivity if it is beneficial for both businesses.

23.5 Supply Chain Management Risks

23.5.1 Definition
Zsidisin (2003) has done research in the area of supply chain risks and includes many definitions from
different authors. He proposed: “Supply risk is defined as the probability of an incident associated with
inbound supply from individual supplier failures or the supply market occurring, in which its outcomes
result in the inability of the purchasing firm to meet customer demand or cause threats to customer life
and safety.”
Supply chain risks can affect the entire chain in organizations, even influencing performance of com-
panies down the chain and having no direct connection with your organization (O’Keeffe, 2004). Most
of the risks are caused due to a lack of a proactive approach and due to a hesitation to invest in effective
solutions (Chopra and Sodhi, 2014).
According to the Supply Chain Risk Leadership Council (2011) “an effective supply-chain risk
management (SCRM) is essential to a successful business.” Supply chain risk management requires studies
to improve methods to mitigate risks and continuing observation by the managers of the system. A good
SCRM needs to be monitored and controlled, so the changes that need to be made over time do not put
the company and its supply chain in any undue risky situations.

23.5.2 Risks
According to Manuj and Mentzer (2008), there are four categories of risks: “supply, demand, operational,
and security risks.” The risk of operations is related with the results of distributions of events that are not
expected and affect the internal capacity to produce. Demand risk is variation of quantity the costumer
could order affecting distribution in the outbound flow. Risk of security is the outcomes that can “threat-
en human resources, operations integrity, and information systems.” Furthermore, all of these risks can
affect each other and increase the damage in supply chain management and “it is also important to note
that an outcome for one firm in the supply chain may be a ‘risk event’ for another firm” (Manuj and
Mentzer, 2008).
The risks in a global supply chain occur because of its complexity resulted by the huge number of
products manufactured and stored in different locations. A good practice to prevent risk is minimizing
this complexity designing a supply chain system. Segmenting or regionalizing the supply chain will limit
the damage caused by a disruption risk. Thus, the loss of the disruption that could happen in a segment
of the supply chain will not impact in another part of the system. The globalization of the supply chain
398
 Supply Chain Management for Engineering Managers

permits the companies to site facilities in different locations in the world, which makes the segmentation
easier and more cost effective. An excellent example is Zara, when the company started producing in low-
cost locations like Asia and Turkey minimizing the economic impact of a risk and reducing the chances of
a potential disruption to affect products from a different geographical area (Bosman, 2006; Chopra and
Sodhi, 2014).
According to Dittmann (2014) there is a simple three-step process to prevent organizations from
facing risks of a supply chain system. Going step by step, the first is the identification of the risk. Iden-
tifying the risk is important because many companies start a risk management process facing the wrong
threats because they do not know which risks the company really needs to mitigate (Supply Chain Risk
Leadership Council, 2011). The Council states that, “Risk identification might begin with brainstorming
sessions, previous risk assessments, surveys, or still other efforts to identify and list potential risks with-
in supply chain processes.” The second step is analysis and prioritize the risks according to the damage
that they can cause the company. Dittmann (2014) claimed that a good strategy to prioritize risks is the
failure mode and effect analysis (FMEA) that is based on “Seriousness of consequences; Likelihood of the
problem ever occurring or frequency of occurrence; Likelihood of early detection of the problem.” This
method will help to identify the most important risks that should be treated first. After identifying and
prioritizing the risks that organizations could face, it is necessary to design strategy plans to mitigate those
risks with high priority (Dittmann, 2014). The supply chain risk management needs to be implemented
with all partners of the company, which includes the suppliers, carriers, and the logistics providers (Supply
Chain Risk Leadership Council, 2011).
According to Gandhi, Gorod and Sauser (2012), “The process of risk management usually begins
with a study to identify the potential risks that a project could generate or to which it could be exposed.
The authors list in Table 23.3 the risks of an outsourcing project, which could also be considered potential
supply chain risks.

Table 23.2. Outsourcing Risks (Adapted from Gandhi, Gorod, and Sauser (2012)

Type of Operational Risk Definition of Risk

Schedule Risk It happens when the product or service could not be delivered in the right time.
Technical Browning (1998) defined a technical risk as the uncertainty in the capability of the
technology to provide the expected performance benefits (Gandhi, Gorod and Sauser,
2012).
Financial According to Browning (1998), “A financial risk is defined as the uncertainty of not be-
ing able to complete a project within a given budget and the consequences thereof.”
Vendor According to Gandhi, Gorod, and Sauser (2012), “Vendor risk can be defined as the
uncertainty of choosing an inappropriate vendor that could impact project perfor-
mance.”
Culture Culture risks can be defined as the culture differences between the organizations that
can affect the quality of the product or service delivered.
Reputation It happens when an organization earns a negative reputation because of outsourcing
and this can make the customers to boycott its products (Gandhi, Gorod, and Sauser,
2012).
Intellectual Property Gandhi, Gorod, and Sauser (2012) claimed that, “Intellectual property (IP) risk is de-
fined as the possibility that the vendor could use or share the client’s ideas or product
to another competitor, causing the client to lose market share.
Flexibility Nilchiani (2002) defined flexibility risk as the ability of an organization to respond to
changes in a timely and cost-effective manner, affecting its value delivery (Gandhi,
Gorod, and Sauser, 2012).
Compliance Compliance risk is related to respect the laws of the organizations involved in the
supply chain.
Quality According to Gandhi, Gorod and Sauser (2012), “Quality risk is defined as the inability
of the end deliverable (product or service) to meet customer requirements.”
399
Engineering Management Handbook

All of the these risks should be managed from a systemic perspective, i.e., the engineering manager
should not just consider the individual risks listed in Table 23.2, but also speculate about how they could
affect one another and the outcome of that interaction on the organization. This is important as a supply
chain is a complex network and the effects of risks could be felt both up and down the supply chain.
An example of a huge risk that a supply chain can suffer is the need to rapidly change its strategy.
Supply chain agility is a crucial characteristic that companies should have.
Figure 23.4 shows that companies have different concepts about what is agility in supply chain.
Supply chain agility is a constant problem that plagues companies due to a fast changing business envi-
ronment. According to Lora Cecere (2012), companies have lean programs and powerful systems, but
they are not flexible in the global supply chain. Cecere also defined agility as “…the design of the supply
chain to have the same cost, quality and customer service given the level of demand and supply volatil-
ity.” There are many occasions when supply chain agility is important. One of them is when there is a
crisis in the economy or some sector involved in the supply chain. An example of this is what is currently
happening in Brazil. Logistics companies in Brazil, which generally specialize in transporting minerals
and steel, are being affected because of decreasing minerals and steel products that they have to transport
and deliver due to a weak economy, which is directly affecting their revenue. As a result, these companies
that are affected need to change their strategy in and are looking to transport general products like sugar,
corn, and salt. This may not seem like a huge change but they have to start dealing with completely new
partners and are giving rise to unforeseen risks in the supply chain. According to Pierre Mercier, Harold
Sirkin, and Jennifer Bratton (2010), “Uncertainty and unpredictability are facts of life in today’s business
environment. Nobody can truly predict the future, no matter how complex or accurate a company’s
forecasting model is.” Also, “it becomes increasingly clear that greater flexibility and thus the ability to
react to rapidly to changing market conditions are just as important as forecasting skills when it comes
to optimizing end-to-end operations.” Changes in the supply chain could occur when the demand of the
market changes and companies are required to respond to this change. Figure 23.5 shows constituents of
an agile supply chain.

Figure 23.4. Definitions of Supply Chain Agility by Executives (Adapted from Cecere, 2012)

400
 Supply Chain Management for Engineering Managers

Figure 23.5. Agile Supply Chain (Adapted from Christopher, 1999)

Information
Technology

Market Agile
Process
Research Supply
Integration
Chain

Network

23.6 Role of Engineers in the Supply Chain

As mentioned throughout this chapter, supply chain management is a crucial process in organizations and
could have a significant influence on costs, profit, and production and on how the company can indulge
in partnerships with other companies. Supply chain management also takes a lot of risks impacting the
bottom line, so that companies need managers with abundance of knowledge to deal with this critical part
of business operation.
The companies expect that engineers to understand the functioning of a supply chain and also under-
stand supply chain management to be able to make changes to the processes between suppliers, retailers
and customers as cheap as possible, with minimal risks and in a sustainable way. Furthermore, since an
engineer designs and builds a product, he or she should be involved in the supply chain, particularly
when working with suppliers to be able to make the best choices of input for the product or service under
consideration.
According to University Alliance (2015), “firms value supply chain/engineering managers because
they decrease the use of large fixed assets such as plants, warehouses and transportation vehicles in the
supply chain. Also, cash flow is increased because if delivery of the product can be expedited, profits will
also be received quickly.” However, it is not easy to find confident supply chain managers in the market.
Robert J. Bowman (2006) stated, “CEOs know there’s a widening talent gap in the supply-chain sector.”
The problem of attracting supply chain talents comes from two different reasons: the lack of recruitment
of personnel dedicated to this field and little access to this subject within the universities, particularly in
engineering programs. According to Bowman before supply chain became a formal discipline “the term
“supply chain” was barely heard at the college level and in high school, not at all.” According to Fish-
er (2014), about 1.4 million new jobs in the supply chain field would be needed to be filled by 2018.
Hence, it can be seen that it is a growing field and one that is important for engineers to focus on.

23.7 Application of Supply Chain in Industries

23.7.1 Examples
Every industry faces varying supply chain challenges. According to Debra Hofman (2011) in Supply
Chain Management Review, companies that have obtained excellence in supply chain, are those able to
401
Engineering Management Handbook

link supply management (manufacturing, logistics, and sourcing), demand management (marketing, sales,
and service), and product management (R&D, engineering, and product development). When these three
areas work functionally and together, the company can meet the market demand as quickly as possible,
while fulfilling quality demands from the customer.
One of the companies that have achieved excellence in supply chain management is Walmart.
Walmart is in the top 20 of Gartner’s rank (a ranking of the world’s leading supply chains) since 2010.
According to the Supply Chain Digest (2012), “Walmart stocks products made in more than 70 countries,
operate more than 11,000 stores in 27 countries around the world, and manage an average of $32 billion
in inventory.” Walmart establishes partnerships with suppliers that can offer the best price and can meet
demand. Those strategic partnerships allow Walmart to offer long-term contracts with high volume and
for the lowest price. The communication between Walmart and its partners is what helps it achieve this
supply chain excellence, so that it can improve material flow with less inventory and thus at the lowest
possible cost. A strategy used by Walmart is cross docking; this system gives the advantage of lesser inven-
tory in their warehouses and fast fulfillment in Walmart stores around the country.
Apple is another leader in supply chain and number one at Gartner’s rank for three years in a row.
Apple has around 156 primary suppliers in the world and only one warehouse located in California. Ap-
ple’s supply chain is relatively simple and this makes its processes easier to manage and thus saves on costs
related to managing the supply chain. Apple constructed relationships with their suppliers, listing the
expectations that the company have in the partnerships moving forward to exclusivity in return of high
volume of guarantees. According to University Alliance (2015), “the company has used its deep pockets
to ensure adequate production capacity by placing high volume pre-orders with suppliers,” which prevent
competitors to achieve access to the same products manufactured by the same suppliers as Apple.

23.7.2 Best Practices in Supply Chain Management

The Global Supply Chain Leaders use different practices in order to minimize costs and maximize quality
in their supply chain processes. Below are some of the most used practices in supply chain management:
• Sales and operations planning for balance: According to Hofman (2011), sales and operations
planning for a balanced process “focuses on the critical activity of supply/demand balancing, match-
ing demand that incorporates customer and market intelligence to the organization’s asset, resource
and material constraints to arrive at a feasible production plan.” Procter & Gamble uses this tactic; its
process is managed with the components of its different businesses, and it is integrated to the finan-
cial forecast.
• Cross docking: According to Clara Lu (2014), cross docking means “the direct transfer of products
from inbound or outbound truck trailers without extra storage, by unloading items from an incoming
semi-trailer truck or railroad car and loading these materials directly into outbound trucks, trailers, or
rail cars (and vice versa), with no storage in between.”
• Working toward a lean and agile supply chain: As was previously mentioned, having a lean supply
chain management involves all the chain working to minimize costs and reduce waist. But the lean
management also should be agile and respond quickly to changes in the market, according to custom-
er demand.
• Value chain: According to Chris Werling (2007), “The value chain is a process whereby the corpo-
ration passes value on to the customer, with the least possible cost to the business.” A good tactic for
this practice is to build a SIPOC diagram, so the manager can have a holistic view of the chain, with
a clear understanding of the value added to the product at each stage of the process.
• Establish a governing council: Creating a good relationship among the partners of the supply chain
is crucial to reach the goals of each company involved. According to Robert J. Engel and Jon We-
soky (2010), the people who should be on this council should include the supply chain organization
leadership but more importantly, the group should consist of members of the executive group, key
internal business unit leaders, and other influential stakeholders such as product designers, manufac-
turing engineers and also representation from the primary suppliers.

402
 Supply Chain Management for Engineering Managers

• Adopting supply chain finance: In order to reduce costs, a practice that many companies are using
is supply chain finance. According to Beth Enslow (2015), it “is a combination of trade financing
services provided by an enterprise or a financial institution and a technology platform that unites the
trading partners electronically. It can involve early payment discount programs, inventory financing,
and other programs to help improve payment predictability and cash flow for suppliers while helping
buyers extend payment times and lower unit costs.”
• Managing supply chain complexity: It is important to not have too complex of a supply chain be-
cause managing it becomes very resource intensive. The key is to be able to come up with clear suppli-
er qualification criteria and then optimize the number of tier 1 suppliers.

23.8 Innovation in Supply Chain Management

According to James P. Strong (2011), reliability, responsiveness, flexibility, lower costs, speed to market,
great service, and technological innovation are some of the things that companies search for when search-
ing for suppliers to collaborate with. Once the qualification criteria are met, managing those suppliers
are key to maintaining a successful relationship. Thus there are several innovations in recent times that
can help manage your suppliers. A good example is the enhancement that has been made in communi-
cation technology. Information technology professionals are essential for the integration of the chain and
to make the control of the suppliers and customers innovative and easier. An example is the enhanced
communication technology that has reduced lead times in the supply chain considerably and has helped
improve the flow by having “electronic kanban systems.” According to the The 2015 MHI Annual In-
dustry Report, some of the strategies to fulfill customer expectations are: Holding inventory closer to key
customers/markets, building or modifying facilities forming-channel distribution and fast cycle-time, high
volume shipments, Collaborative logistics (sharing transportation or distribution facility capacity with
other companies), Introducing “postponement” strategies to reduce turn-around time on final packaging
or assembly.
When the company is integrated well with the supply chain, innovation can come from its suppliers.
According to Veinott (2005), “firms in more than a few supply chains realize that there are important
benefits from sharing information too. For example, the potential for making supply chains more respon-
sive and efficient, by sharing information.” According to the The 2015 MHI Annual Industry Report, the
innovations most likely to be implemented in the supply chain from 2015 to 2025:
• Inventory and network optimization tools
• Sensors and automatic identification
• Cloud computing and storage
• Prediction analytics
• Robotics and automation
• Wearable and mobile technology
• 3D printing
• Driverless vehicles and drones

23.9 Conclusion
Since no company operates in isolation, supply chain management plays a significant role in almost all
companies nowadays. Although there are leaders in the field of supply chain management, it is an im-
portant challenge for all companies to address since it is the foundation and infrastructure of successful
businesses. Companies, big or small, need to be aware of and understand the complexities of their supply
chain, without which they will not be able to prosper in the 21st century’s interconnected business envi-
ronment. The need for good engineers in the supply chain domain is clear and hence companies as well
as universities should work together in order to produce engineers and engineering managers who have a
level of awareness and understanding of their product as well as organization’s supply chain. This would
not only help an organization boost customer satisfaction by delivering products and services on time, but
also help create better overall value for the customer; thus increasing quality.
403
Engineering Management Handbook

23.10 References
“Apple’s SCM Make It a Global Supply Chain Leader,” University of San Francisco Online. University
Alliance. Accessed 6 June 2015.
Balaji, L. N., “How to Reduce Costs through Supply Chain Network Optimization.” Industry Week, 8
July 2013.
Bosman, R., The New Supply Chain Challenge: Risk Management in a Global Economy, 2006. Accessed
from http://www.fmglobal.com/pdfs/ChainSupply.pdf.
Cecere, Lora., “Preparing to Run the Race: Supply Chain 2020.” Supply Chain Shaman, 25 Apr. 2012.
Chopra, S. and Sodhi, M. S., “Reducing Risk of Supply Chain Disruption,” MIT Sloan Management
Review, 2014.
Corbett, Meryle, “SIPOC - An Amazing Way to Reduce Waste and Streamline Workload.” BC Biz-
CoachOnline, 30 Apr. 2012.
“CSCMP Supply Chain Management,” CSCMP Supply Chain Management. Council of Supply Chain
Management Professionals. Accessed 4 June 2015.
Engel, Robert and Wesoky, Jon, “10 Best Practices for Supply Management Organizations.” Institute for
Supply Management. 95nd Annual International Supply Management Conference, 1 Apr. 2010.
Enslow, Beth, “Global Supply Chain Excellence: New Best Practices to Master.” Supply Chain Brain.
Accessed 18 Dec. 2015.
Gandhi, Shereazad Jimmy, Gorod, Alex, and Sauser, Brian, “Prioritization of Outsourcing Risks from a
Systemic Perspective.” Emerald Insight 5.1, pp. 39-71, 2012.
Gattorna, John, Dynamic Supply Chains. 3rd Edition ed., 2015.
Handfield, Robert, “What Is Supply Chain Management?” Supply Chain Management, SCM, SCRC Sup-
ply Chain Resource Cooperative, Poole College of Management, North Carolina State University. 11 Jan.
2011.
Harrison, A., Christopher, M. and van Hoek, R., Creating the Agile Supply Chain, Institute of Logistics
& Transport, UK, 1999.
Hatton, John, “Lessons in Lean.” Supply Management | The Procurement and Supply Website. 14 Mar.
2013. NEED URL.
Hofman, Debra, “The Top 25 Supply Chains: Leadership in Action.” Supply Chain Management Review,
10 Oct. 2011.
Kauffman, Ralph, and Thomas Crimi, “Supply Chain Cost Reduction Strategies.” Institute for Supply
Management. Institute for Supply Management, 1998.
Lu, Clara, “Incredibly Successful Supply Chain Management: How Does Walmart Do It?” Tradegecko, 8
May 2014.
Mack, Stan, “Explain the Term “Supply Chain” and Its Importance to Cost Management.” Small Business.
Demand Media. Accessed 5 June 2015.
Manrodt, Karl, Thompson, Richard and Vitasek, Kate, “Benchmarking Your Lean Journey.” Logistics
Management. Jones Lang LaSalle, 2008.
Manuj, I. and Mentzer, J. T., “Global supply chain risk management strategies,” International Journal of
Physical Distribution & Logistics Management, vol. 38, no. 3, pp.192-223, 2008.
Mercier, Pierre, Sirkin, Harold and Bratton, Jennifer, “Eight Ways to Boost Supply Chain Agility.” Supply
Chain Management Review, 7 Jan. 2010.
O’Keeffe, P., Understanding supply chain risk areas, solutions, and plan, 2004. Accessed from http://
www.protiviti.com/en-US/Documents/Surveys/SupplyChainRiskAreas.pdf.
Sankar, Ravi, “Five Ways to Optimize Supply Chain Management.” Industry Week, 31 Oct. 2011.
Strong, James, “Customer Focused Supply Chain Management.” The ACA Group, 2011.
“The 2015 MHI Annual Industry Report Supply Chain Innovation—Making the Impossible Possible,”
2015.
“Timeline of 50 Years of Supply Chain at Walmart,” Supply Chain Digest. 26 July 2012.
Veinott, Arthur, “Lectures in Supply-Chain Optimization.” Department of Management Science and
Engineering Stanford University. Stanford University, Stanford, CA, 1 Jan. 2005. Lecture.
404
 Supply Chain Management for Engineering Managers

Werling, Chris, “Top 10 Supply Chain Best Practices.” Cornerstone Solutions, Inc., 2007.
“What Is the Importance of Supply Chain Management?” University of San Francisco Online. University
Alliance. Accessed 6 June 2015.
Zsidisin, G., “A grounded definition of supply risk.” Journal of Purchasing and Supply Management, vol. 9,
no. 5-6, pp. 217-224, 2003. DOI: 10.1016/j.pursup.2003.07.002.

405
406
AUTHOR BIOGRAPHIES

Mary Bone, Stevens Institute of Technology

Mary Alice Bone has worked as a Systems Engineer for GE Transportation, BAE Systems, Dell and Rockwell Collins.
She holds a B.S. in Aerospace Engineering from the Missouri University of Science & Technology, a M. Eng.
in Systems Engineering from Iowa State University, and a Ph.D. in Systems Engineering from Stevens Institute
of Technology. Her research interests are reference architectures, model based systems engineering (MBSE),
architecture entropy & complexity, evaluating requirements risk and systems effort estimation.

Donna Brazil, United States Military Academy

Donna Brazil is a retired Army Colonel who directed the Psychology Program in the Department of Behavioral
Sciences and Leadership at the United States Military Academy at West Point, New York. She holds a Bachelor’s
degree from the United States Military Academy, as well as Masters and Ph.D. degrees in Social Psychology
from the University of North Carolina at Chapel Hill. Dr. Brazil’s research and teaching activities include applied
leadership, leader development, social psychology, positive psychology, and resilience. She is currently working
as an independent contractor on various leader development initiatives.

Behnido Calida, Virginia Tech Transportation Institute

Behnido Y. Calida is a Senior Project Associate at the Virginia Tech Transportation Institute (VTTI). He holds a PhD
and a Master of Engineering Management degree from Old Dominion University’s Engineering Management and
Systems Engineering Department in 2013 and 2009, respectively. He also holds a BS in Applied Physics from the
University of the Philippines, Diliman, Quezon City in 2000. After some years in the high-tech semiconductor and
electronics industry and while pursuing graduate studies, he is an adjunct faculty with undergraduate/graduate
level engineering/project Management course in live, online and televised mediums for Old Dominion University
and the Florida Institute of Technology. He is actively engaged in multiple research threads in the areas of system
of systems engineering, critical infrastructures, complex adaptive systems, model-based engineering, and
system governance, complex systems engineering and data preparation, standardization, mining, and analysis in
transportation systems.

Robert Cloutier, Stevens Institute of Technology

Dr. Robert Cloutier is a Professor and System Engineering Program Chair at the University of South Alabama. He
also holds a concurrent Professor II appointment at Høgskolen i Sørøst-Norgein, Kongsburg, Norway. He recently
served on the Scientific Advisory Board for the National Science Foundation Engineering Research Center
for Compact and Efficient Fluid Power. Dr. Cloutier’s research interests are focused on composable systems
architecting and patterns, model based systems architecting, and quantifying system architectures.
Prior to his current appointment, he was Program Director for Systems Engineering Programs and Deputy Dept.
Head of Systems and Software Division in the School of Systems and Enterprises at Stevens Institute of Technology.
Dr. Cloutier’s industry experience includes over twenty years’ experience in systems engineering & architecting,
software engineering, and project management. Past positions includes Principle Engineer at Lockheed Martin
Mission Systems & Sensors where he worked on the US Navy Aegis and Littoral Combat Ship combat systems, and
Associate Technical Fellow and lead avionics engineer for a V-22 Osprey variant at Boeing Helicopters. Dr. Cloutier
has created and delivered a wide variety and scope of education and training materials. Topics include Systems
Engineering Fundamentals, Systems Architecture and Design, Model Based Systems Engineering, Engineering
Design, Project Management, Quantitative Decision Making, Technical Application to Business, and Managing IS/
IT Organizations to name a few. He has taught and conducted systems engineering workshops for Sandia National

407
 Labs, Lockheed Martin, Technical University of Munich, Baker Hughes, Nokia, IBM, INCOSE (International Council
on Systems Engineering), and many others. Dr. Cloutier received Product Development Management Association
Visions Award, 2010, the Stevens Provost Award in Recognition of Outstanding Achievements in Research and
Scholarship, 2010-2011, and the 2009-2010 Alexander Crombie Humphreys Distinguished Associate Professor
Teaching Award at Stevens. Dr. Cloutier is a member of INCOSE and an active member in their Architecture Working
Group, and in the INCOSE Model Based Systems Engineering Working Group. He served as Chapter President of
the Delaware Valley Chapter of INCOSE. Dr. Cloutier holds a Ph.D. in Systems Engineering from Stevens Institute of
Technology, an MBA from Eastern University, and a BS from the United States Naval Academy. He served in the US
Navy as a Machinery Officer, and an Anti-submarine Officer.

T. Steven Cotter, Old Dominion University

T. Steven Cotter is a Lecturer with the Engineering Management and Systems Engineering department at Old
Dominion University. He earned a Ph.D. in Engineering Management and Systems Engineering from Old Dominion
University, a Master of Science in Engineering Management with a concentration in quality/reliability engineering
from the University of Massachusetts at Amherst, a Master of Business Administration with a concentration
in finance and a Bachelor of Science both from the University of South Carolina, and a diploma in Electronic
Technology from Graff Area Vocational and Technical School (now Ozarks Technical Community College). He is
a certified Quality Engineer and Reliability Engineer with the American Society for Quality. His research interests
are in engineering design analytics, human-machine intelligent decision governance, quality systems design, and
statistical engineering.

William Daughton, Missouri University of Science and Technology

Dr. William Daughton is Professor Emeritus and former chair of the Engineering Management and Systems
Engineering (EMSE) Department at the Missouri University of Science and Technology. He most recently served
as Program Director of the online graduate programs in Engineering Management, Systems Engineering, and
Space Operations at the University of Colorado at Colorado Springs before retiring in January of 2015. Prior to
joining Missouri S&T, Dr. Daughton was the Lockheed Martin Professor of Engineering Management and Director
of the Lockheed Martin Engineering Management Program at the University of Colorado – Boulder for nearly 10
years. He also has over 15 years of experience in technical and business unit management in the semiconductor
industry at Texas Instruments and NCR Microelectronics. Dr. Daughton holds a BS degree from Illinois College, an
MS degree from the South Dakota School of Mines and Technology, and a PhD from the University of Missouri –
Columbia. Dr. Daughton was recognized by the Engineering Management Division of the ASEE with the Bernard
R. Sarchet Award for Lifetime Achievement in Engineering Management Education in 2007. He also serves as the
Executive Director of the American Society of Engineering Management and was recognized by ASEM in 2009 for
his leadership in the society with its Bernard R. Sarchet Award.

Gene Dixon, East Carolina University

Gene Dixon is an Associate Professor at East Carolina where he teaches aspiring engineers at the undergraduate
level. Previously he has held positions with Union Carbide, Chicago Bridge & Iron, E.I. DuPont & deNemours,
Westinghouse Electric, CBS, Viacom and Washington Group. His work experience includes project engineer,
program assessor, senior shift manager, TQM coach, and production reactor outage planner, remediation
engineer. He gives presentations as a corporate trainer, a teacher, and a motivational speaker. He received a
Ph.D. in Industrial and Systems Engineering and Engineering Management from The University of Alabama in
Huntsville, a Masters of Business Administration from Nova Southeastern University and a Bachelor of Science
in Materials Engineering from Auburn University. He has authored several articles on follower component of
leadership and is active in research concerning capstone, engineering education, and leadership processes. He
has served as newsletter editor/secretary, program chair, division chair and awards chair in both the Engineering
Management and Engineering Economy Divisions of ASEE. He is a fellow of the American Society of Engineering
Management and served as the 2015 ASEM President. Dixon also serves on the Eugene L. Grant Award Committee
for the Engineering Economy Division of ASEE. He has served a board member of the ASEE Design in Engineering
Education Division and Secretary for the ASEE Industrial Engineering Division. He also serves as a board member
for the IIE Engineering Economy Division.

Chris Edmonds, CEO, Roddie’s Code, LLC and Roddie Edmonds Foundation
Mr. Edmonds is the son of WWII hero Master Sergeant Roddie Edmonds who’s fearless bravery saved the lives
of more than 200 Jewish soldiers in a prisoner of war camp in Germany in January 1945. In January 2016,
408
Mr. Edmonds received the Righteous Among the Nations award on behalf of his father from the Nation of Israel.
He is an inspirational speaker and executive leader with twenty-five years of success in developing people
that supports business values and objectives. He has been a member and instructor for American Society for
Engineering Management since 2011. He has an undergraduate degree in Human Resources Management from
the University of Tennessee and a Masters in Religion and Counseling from Liberty University. He is also certified
as a Senior Professional in Human Resources (SPHR) and serves as Pastor of Piney Grove Baptist Church in
Maryville, Tennessee.

Marina Lemos Fajardo, Universidade Federal de Juiz de Fora

Marina Lemos Fajardo is Industrial Engineering Undergraduate student at Universidade Federal de Juiz de Fora.
She is studying Industrial Engineering in Brazil but has studied for parts of her undergraduate degree in the
United States at New Mexico State University and Arizona State University. Marina has experience working in
various companies in an entrepreneurial and technological environment, strategy, quality control, marketing,
ISO 9001, project management, and leadership positions. She has also worked in a Junior Enterprise of Industrial
Engineering in Brazil, where she developed two projects, a sustainability project, and a project focused
on Facilities Planning. She has also been the Director of the Marketing Department and has certifications in
Interpretation of NBR ISO 9001:2008, on the Project Management Body of Knowledge (PMBOK), Internal Quality
Audits and Lean Six Sigma.

John V. Farr, United States Military Academy

Dr. Farr is a Professor of Engineering Management and Director of the Center for Nation Reconstruction and
Capacity Development at the United States Military Academy at West Point. Prior to returning to West Point
in 2010 he was a Professor of Systems Engineering and Engineering Management in the School of Systems and
Enterprises at Stevens Institute of Technology. He was the founding Director of the Department of Systems
Engineering and Engineering Management at Stevens, which he led from 2000 to 2007. He served as Associate
Dean for Academics from 2007 to 2010. He taught at West Point from 1992 to 2000, and achieved the rank of
Professor of Engineering Management. Dr. Farr was also the first permanent civilian professor in engineering at
the Academy. He is a past president and Fellow of the American Society for Engineering Management, a Fellow
of the American Society of Civil Engineers, former member of the Army Science Board and the Air Force Studies
Board of the National Academies, Fulbright Scholar, and currently serves as a Commissioner for the Engineering
Accreditation Commission of the Accreditation Board of Engineering and Technology. He is a former editor of
the Journal of Management in Engineering and the founder of the Engineering Management Practice Periodical.
He has authored over 160 technical publications including three textbooks. He is a registered Civil Engineer in
New York and Mississippi, certified Project Management Professional (PMP) and holds an undergraduate degree
from Mississippi State University, a master’s from Purdue University, and a Ph.D. in Civil Engineering from the
University of Michigan.

Brian J. Galli, Long Island University

Brian works as an Assistant Professor of Management Engineering at Long Island University – Post. Brian is also
the President of Apex Strategies, Ltd, an firm that specializes in training and consulting services for process
improvement and operational excellence. He holds a doctoral degree in Engineering Management from Old
Dominion University, earned December 2013. He also holds a Bachelor’s of Science in Industrial Engineering,
earned May 2007, from Binghamton University (SUNY Binghamton), as well as Masters of Science in Engineering
Management, earned July 2009, from Missouri University of Science & Technology. He is a licensed professional
engineer in New York State and holds a certification as a Lean Six Sigma Black Belt. Brian has been teaching part
time for NYIT and LIU for the past 8.5 years while working in the field of Lean and Six Sigma for Telephonics
Corporation, North Shore LIJ Health System and most recently EmblemHealth. His research interests include: Six
Sigma, Lean, Continuous Improvement, Leadership Development, Change Management, Project Management,
and Quality Improvement/Quality Management.

S. Jimmy Gandhi, California State University, Northridge

Dr. S. Jimmy Gandhi is an assistant professor of Engineering Management at California State University,
Northridge. He has also served as an adjunct professor at Stevens Institute of Technology, Hoboken, NJ as
well as at Baruch College, which is part of The City University of New York. He has received his B.S., M.S. and
PhD degrees in Engineering Management from The Illinois Institute of Technology, California State University,
Northridge and The Stevens Institute of Technology, respectively. Dr. Gandhi’s primary research focus is in the
409
 areas of innovation and entrepreneurship, quality management, sustainability, supply chain management and
engineering education. Within these areas, he has led a variety of funded projects and has been an invited
speaker at several international conferences and institutions. He is a co-author of over 50 peer reviewed
conference and journal publications and is a member of several professional societies including The American
Society of Engineering Management (ASEM) as well as The American Society of Engineering Education (ASEE).

Anirban Ganguly, O. P. Jindal Global University

Anirban Ganguly holds BSc and MBA degrees from the University of Calcutta, and also MS and PhD from
Stevens Institute of Technology, USA. He is currently an Assistant Professor in Operations Management with
the Jindal Global School of Business at O. P. Jindal Global University, India. Prior to joining Jindal Global Business
School, he has held faculty positions at Hofstra University, City University of New York and Stevens Institute
of Technology. He has several years of academic experience, both in the domain of teaching and research. Hi
research interest include operational and supply chain management, technology and innovation management,
risk analysis and knowledge management. His work has been published in International Journal of Production
Economics, International Journal of Knowledge Management, Engineering Management Journal IEEE Aerospace
& Electronics Systems Journal and International Journal of Innovation and Technology Management, among
others. In addition to research and teaching in academia, Dr. Ganguly is also involved as an advisor at Superior
Business Results in North Carolina, USA where he was involved with projects related to business analytics in
retail and healthcare sector. He also has industry experience in India prior to moving to USA. He serves as a
reviewer for a vast number of journals like International Journal of Production Economics, European Journal of
Operational Research, Engineering Management Journal, International Journal of Supply Chain Management
and International Journal of Innovation Management, among others.

Abhijit Gosavi, Missouri University of Science and Technology

Dr. Abhijit Gosavi is an Assistant Professor of engineering Management and Systems Engineering at Missouri
University of Science and Technology. Prior to joining Missouri S & T, he had worked for many years in academia,
including as an assistant professor in Colorado State University-Pueblo. Dr. Gosavi received a Bachelor’s degree
in Mechanical Engineering from the Jadavpur University in 1992. He obtained a Master’s degree in Mechanical
Engineering from the Indian Institute of Technology, Madras in 1995, and was awarded a Ph.D. in industrial
engineering in 1995 from the University of South Florida. His research interests are in simulation-based
optimization, applied operations research, and engineering metrology. He has published numerous articles
in archival journals, including journals like Management Science, the INFORMS Journal on Computing, and
Automatica. He is the author of a research monograph, Simulation-based Optimization, published by Springer
in 2003. He is a member of the Institute of Industrial Engineering (IIE), the Institute for Operations Research
and Management Science (INFORMS), American Society of Engineering Management, American Society of
Engineering Education (ASEE), the Institute of Electrical and Electronics Engineers (IEEE), and the Production and
Operations Management Society (POMS). He has served/is serving on committees for the conferences of ASEE
and INFORMS.

Scott E. Grasman, Rochester Institute of Technology

Dr. Scott E. Grasman is Professor and Department Head of Industrial and Systems Engineering at Rochester
Institute of Technology. He previously spent 10 years in the Department of Engineering Management and
Systems Engineering at Missouri University of Science and Technology. He has served as Adjunct Professor
of Operations and Manufacturing Management in the Olin Business School at Washington University in St.
Louis. He completed a sabbatical in Statistics and Operations Research at the Public University of Navarre in
Spain and a two month appointment as Visiting Research Scholar at IN3 – Universitat Oberta de Catalunya. He
received his B.S.E., M.S.E., and Ph.D. degrees in Industrial and Operations Engineering from the University of
Michigan. In addition to academia, he has relevant industrial experience, in addition to industrial collaborations
on research and curriculum activities. His research, teaching, and service have led to many international
relationships, including student/faculty exchange agreements and scholarly visits. His primary expertise relates
to the application of operations research models to manufacturing and service systems, as well as engineering
education. Within these areas, he has led a variety of funded research projects, which have resulted in publicity
in national media and numerous international speaking invitations. His work has resulted in being the author or
co-author of over 100 technical papers, including multiple best conference paper awards, as well as reviewer/
editorial roles for various technical journals and books. He served as an ASEM Regional Director from 2005-
2008, and in other service capacities for ASEE, IIE, and INFORMS.
410
Ra’ed Jaradat, Mississippi State University
Dr. Ra’ed Jaradat is an Assistant professor of Industrial and Systems Engineering at Mississippi State University
and a research affiliate with the National Center for Systems of Systems Engineering (NCSOSE). Raed received
a PhD in Engineering Management and Systems Engineering from Old Dominion University in 2014 and his
B.S. in Business Administration and M.S. in Operations Management from Hashemite University in Jordan in
2003 and 2005, respectively. His main research interests include engineering management, systems engineering
and management systems, systems thinking and complex system exploration, systems simulation, risk and
vulnerability in critical infrastructures with applications to diverse fields ranging from the military to industry.
Dr. Jaradat’s publications have appeared in journals such as the Requirements Engineering Journal, International
Journal of Critical Infrastructures Protection, International Journal of System of Systems Engineering, and
Administrative Theory and Praxis. He has also published numerous conference proceedings as well as a book
entitled ‘Operational Risk Management.’ He is a topic leader in systems thinking, including systems theory
and complex systems for the Society for Engineering and Management Systems (SEMS). Dr. Jaradat is a past
proceedings chair of the American Society for Engineering Management and is currently a member of the
Academy of Management and Institute of Industrial Engineers (IIE). Prior to his academic career, Jaradat worked
as a systems analyst and operations officer at the Ministry of Industry & Trade in Jordan/Chamber of Commerce.

Polinpapilinho F. Katina, National Centers for System of Systems Engineering

Polinpapilinho F. Katina is a Postdoctoral Researcher with the National Centers for System of Systems Engineering
(NCSOSE) within the Department of Engineering and Systems Engineering at Old Dominion University (ODU),
Norfolk, Virginia, USA. His areas of research include engineering management, critical infrastructure protection,
decision-making under uncertainty, complex system governance, infranomics, systems engineering, systems of
systems engineering, systems thinking, and transportation of hazmat. Dr. Katina is a co-editor of a critical textbook
on topic of Infranomics. His research appears in a number of international journals including the International
Journal of Critical Infrastructure Protection, International Journal of Critical Infrastructures, International Journal
of Decision Sciences, Risk and Management, International Journal of System of Systems Engineering, and Journal
of Requirements Engineering. Prior to engaging in graduate studies, Dr. Katina worked in energy, hospitality,
sports, and television industries. Dr. Katina received his Ph.D. in Engineering Management at Old Dominion
University, Norfolk, Virginia, USA. He also holds a graduate degree in Systems Engineering and a bachelor’s
degree in Engineering Technology with a minor in Engineering Management both from Old Dominion University.
He received training from various institutions including Politecnico di Milano, Milan, Italy.

Charles Keating, Old Dominion University

Charles B. Keating is Professor of Engineering Management & Systems Engineering and Director for the National
Centers for System of Systems Engineering at Old Dominion University. He received a B.S. in Engineering from
West Point, an M.A. in Management from Central Michigan University, and a Ph.D. in Engineering Management
from Old Dominion University. His research focus in on system of systems engineering, complex systems analysis,
and R&D management.

Timothy Kotnour, University of Central Florida

Tim Kotnour, Ph.D., is a Professor in the Department of Industrial Engineering and Management Systems at
the University of Central Florida. He is the Director of the Engineering Leadership and Innovation Institute.
He completed his doctorate in Industrial & Systems Engineering with an emphasis in Management Systems
Engineering from Virginia Tech. Dr. Kotnour partners with senior management teams to develop solutions for
sustained excellence for their organization. During his career, he has delivered performance solutions through
technical assistance, training, and research with industry, government, and universities. He focuses on strategic
management, change management, organizational transformations, performance measurement, and strategic
project management. He provides strategic conversation process development and facilitation to leadership
teams. Past and current partners include NASA, Kennedy Space Center, Launch Services Program, Electronic Arts,
DOD/Tardec, Walt Disney Company, The Boeing Company, Lockheed Martin, Siemens Power Generation, Harris,
SAIC, Dynacs Engineering Inc., U.S. Air Force, Department of Energy, Orlando Healthcare System, and Carilion
Healthcare System. He teaches Strategy, Technology Strategy, Project Engineering and Engineering Management
both on and off campus for industrial partners.

Patrick Kush, Metropolitan State University

Patrick Kush earned a Bachelor of Science in Astrophysics from the University of Minnesota in 2004. In addition,
Patrick earned a Masters of Engineering Management from St. Cloud State University in 2010 and a Masters of
411
 Business Administration from Metropolitan State University in 2012. Patrick is the North Central Regional Director
for the American Society for Engineering Management and is a certified Associate Engineering Manager. Patrick
Kush taught Quality Management for Metropolitan State University. At the University of Minnesota Crookston,
Patrick was an online instructor for Operations Management. Patrick lives in Minneapolis with his wife Tricia and
two feline associates.

Luna M. Magpili, Washington State University

Luna M. Magpili is an associate professor of engineering management and technology at Washington State
University. She earned her doctorate degree in Systems Engineering from the University of Virginia and a Bachelor
and Master degrees in industrial engineering from the University of the Philippines. While at the University of
Virginia, her research focused on critical infrastructure of water, waste water, and solid waste management.
She also served as program officer for International Relief and Development managing disaster operations and
rebuilding efforts around the globe. Dr. Magpili currently supports various programs at NSF, NASA, and DoD as
panel reviewer. She also serves as referee to various journals, such as Risk Analysis, Environmental Science and
Technology, and Environmental Monitoring and Assessment. She is currently a member of ASEE, ASEM, TOCICO,
and INCOSE.

Katie McConky, Rochester Institute of Technology

Dr. Katie McConky, Assistant Professor in the Industrial Engineering Department at Rochester Institute of
Technology, has seven years of industry experience working in the fields of information fusion and predictive
data science. As a research scientist at CUBRC, Inc. she worked on a variety of projects from Big Data analytics
intelligence applications to automated voice recognition projects for battlefield event reporting. Most recently
Dr. McConky has applied her data fusion and analytics skills to the Big Data world of the smart grid while
working as lead data scientist for TROVE Predictive Data Science. By fusing smart meter data with customer
demographic, customer premise level data, and weather information she has developed patented technologies
to perform data driven theft detection, demand response event forecasts, energy efficiency marketing campaign
optimization, demand disaggregation, and generation level forecasts. Currently Dr. McConky’s research work
focuses on the optimization of hybrid energy systems and energy driven scheduling applications.

Kenneth W. McDonald, United States Military Academy

Dr. McDonald is currently an Associate Professor of Engineering Management and Associate Director of the
Center for Nation Reconstruction and Capacity Development, Department of Systems Engineering, United States
Military Academy, West Point. Dr. McDonald earned a BS degree from the United States Military Academy in Civil
Engineering (ABET), an MBA–Information Systems (Meinders School of Business, Oklahoma City University); an
MS degree in City and Regional Planning (Western Kentucky University); an MS degree in Geography (Western
Kentucky University); an MS degree in Environmental Engineering (Missouri University of Science and Technology);
and a PhD in Geological Engineering (Missouri School of Mines – MS&T). He is a registered Civil Engineer in the
states of Virginia and Wyoming; a Certified Planner with the American Institute of Certified Planners (AICP);
and a registered Project Management Professional (PMP) with the Project Management Institute (PMI). Dr.
McDonald is a member on the National Board of Governors of the Order of the Engineer and has authored and
co-authored over 20 technical publications to include book chapters and refereed publications on infrastructure,
capacity development, geotechnical engineering, engineering management, and value modeling. Dr. McDonald
is also a member of Gamma Theta Upsilon and Phi Kappa Phi honor societies. He is a member of the American
Planning Association (APA), ASEM, the Engineer Regimental Association (ERA), the Order of the Engineer (OE),
the Project Management Institute (PMI), and the Society of American Military Engineers. In recognition for
his experience and achievements, Dr. McDonald has received numerous awards and recognitions such as the
Federal Executive Board’s Award for Valor (New York City), 2002 Federal Engineer of the Year (National Society
for Professional Engineer), the Silver and Bronze DeFluery Medal (US Army Engineer Regiment), and the 2001
Engineer of the Year (US Army Training and Doctrine Command). He also was awarded the 2013 Bliss Medal
which is given once a year to recognize excellence in engineering education and student mentorship (Society of
American Military Engineers). He is also earned the Legion of Merit, Bronze Star, Purple Heart and Joint Service
Commendation medals for numerous military deployments and achievements.

Donald N. Merino, Stevens Institute of Technology

Donald N. Merino is the Alexander Crombie Humphreys Chaired Professor of Economics of Engineering
Emeritus at Stevens Institute of Technology. He had been a tenured full Professor and taught Engineering
Economy, Financial Management, Decision Analysis, Total Quality Management, and Strategic Planning. He is
412
Founder Emeritus of the undergraduate Bachelor of Engineering in Engineering Management (BEEM) and the
Executive Master in Technology Management (EMTM) Program at Stevens. He was the Editor of the ASEM
Engineering Body of Knowledge (EM BoK) published in 2008. He won the Morton Distinguished Teaching
Award for full professors at Stevens. John Wiley published his book, The Selection Process for Capital Projects.
Dr. Merino received two Centennial certificates from the ASEE in Engineering Economics and Engineering
Management. He is past Chair of the Engineering Management Division and Engineering Economy Division of
ASEE. Dr. Merino was awarded the ASEM and ASEE Bernard Sarchet Award. He is an ASEM and ASEE Fellow and
past president of ASEM. Dr. Merino has 25 years of industrial experience in positions of increasing managerial
/ executive responsibilities. Since joining academy 32 years ago, he has published 52 refereed journal articles
and conference papers and over 50 research reports.

Donald W. Merino, Transpacific Advisors

Donald W. Merino is based in Taipei and leads the licensing and advisory business at Transpacific Advisors.
He develops programs to work with inventors, companies and universities to help them to understand value
and paths towards monetization. Additionally, Dr. Merino advises companies on IP strategy to develop plans,
procedures and benchmarks. Dr. Merino has extensive global experience in developing and building patent
portfolios. He is one of the world leaders in buying, selling and licensing intellectual property. He has successfully
negotiated hundreds of patent licenses and patent acquisitions, including more than 500 deals during his time as
head of acquisitions at Intellectual Ventures. Over his career he has acquired technologies and patents totaling
over $1 billion and also completed deals that both sold and licensed technologies and patents in aggregate
of over $2 billion. Additionally, Dr. Merino has been a damages expert on a number of litigations. Dr. Merino
spent nine years at Intellectual Ventures, where he was responsible for building IP acquisition and investment
programs, including business development and evaluation. He built the operation from scratch and managed
a team of over 50 professionals across eight countries. Later as SVP for licensing at IV, responsible for Asia IP
licensing, where he drove over $1 billion in licensing revenue. Before Intellectual Ventures, Dr. Merino was
co-director of licensing at Intel Corp, where he generated royalty revenue of $250 million a year. He was also
responsible for IP strategy, all cross-licensing negotiations and major IP litigation, strategy and settlements.
Before Intel, Dr. Merino was director of licensing for General Instruments and was a founding board member of
MPEG-LA. Dr. Merino is a Certified Licensing Professional and has a MEng in mechanical engineering and a Ph.D.,
from Stevens Institute of Technology. For six years he served as an officer in the US Navy after graduation for the
US Naval Academy in 1984.

Gregory S. Parnell, University of Arkansas and Innovative Decisions Inc.

Dr. Gregory S. Parnell is a Research Professor in the Department of Industrial Engineering at the University
of Arkansas and Director of the M.S. in Operations Management program, the university’s largest graduate
program. He is also a principal and board member with Innovative Decisions Inc. His research focuses on
decision and risk analysis. He was lead editor of Decision Making for Systems Engineering and Management,
(2nd Ed, Wiley and Sons, 2011), lead author of the Handbook of Decision Analysis, Wiley Operations Research/
Management Science Series (Wiley and Sons, 2013), and editor of Engineering Trade-off Analysis: Identifying
Value and Risk, (forthcoming, Wiley and Sons, 2016). He is a fellow of the International Committee for Systems
Engineering, the Institute for Operations Research/Management Science, the Society for Decision Professionals,
and the Military Operations Research Society. He has won numerous awards including the 2014 Frank P. Ramsey
Medal for distinguished contributions to the field of decision analysis. He previously taught at the West Point,
the U.S. Air Force Academy, the Virginia Commonwealth University, and the Air Force Institute of Technology. He
has a PhD from Stanford University and is a retired Air Force Colonel.

C. Ariel Pinto, Old Dominion University

Ariel Pinto joined the Department of Engineering Management and Systems Engineering at Old Dominion
University in 2004. Previously, he was a research fellow at the Software Industry Center at Carnegie Mellon
University, and at the Center for Risk Management of Engineering Systems at the University of Virginia. His
research interests are in the areas of risk management in engineered systems, including project risk management,
risk valuation, risk communication, analysis of extreme-and-rare events, and decision-making under uncertainty.
He earned his doctorate degree in Systems Engineering from the University of Virginia and master and bachelor
degrees in Industrial Engineering from the University of the Philippines. In 2009, he co-founded the Emergent
Risk Initiative at Old Dominion University (ERI@ODU) with the vision to create the next generation body of
knowledge in risk management for current and future systems and organizations characterized by uncertainty,
emergence, complexity, and interdependence.
413
 Darcy Schnack, United States Military Academy
Lieutenant Colonel Darcy Schnack graduated from the United States Military Academy in 1996 and was
commissioned as a second lieutenant in the Transportation Corps. She later earned her Master’s degree from
Boston College in 2006 and is currently working on her PhD in Sociology. Darcy has served at various levels
of leadership in the U.S. Army, two tours in Iraq as an Army logistician, and two tours as instructor and later
as assistant professor at West Point. Her husband, Troy, recently retired from the Army and they have three
children: Ainsley (9 yrs), Avery (7 yrs), and Rowan (2 yrs). Darcy is currently serving as the Director of the Center
for Enhanced Performance at West Point.

Nakul Sharma, California State University, Northridge

Nakul Sharma is a graduate student assistant at California State University, Northridge. He is also pursuing his
Master’s degree in Engineering Management at California State University, Northridge. He holds a Bachelor’s
degree in Mechanical Engineering from Laxmi Devi Institute of Engineering & Technology (India). Before pursuing
his Master’s degree, he worked for five years in India in different sectors like construction, heavy machinery and
Oil & Gas. Most recent position he held was of Channel Manager – Sales at Zavenir Daubert India Pvt. Ltd, where
he was responsible for primary and secondary sales for four of the company’s 27 designated channel partners.

Andreas Tolk, The MITRE Corporation

Andreas Tolk is Associate Professor for Engineer­ing Management and Systems Engineering at Old Do­minion
University, Norfolk, Virginia. He is also a Senior Research Scientist at the Virginia Modeling Analysis and Simulation
Center (VMASC). He holds a M.S. in Computer Science (1988) and a Ph.D. in Computer Science and Applied
Operations Research (1995), both from the University of the Federal Armed Forces of Germany in Munich. He
published over 150 contributions on modeling and simulation specific topics as journal articles, book chapters,
and conference papers, more than 30 of them have been awarded as outstanding contributions. He is a member
of ASEM, ACM SIGSIM, SCS, SISO, MORS, and NDIA.

Jerry Westbrook, Professor Emeritus, University of Alabama at Huntsville

Dr. Westbrook has served the American Society for Engineering Management in a variety of positions. He is
a past President of the society and past Executive Director. He founded ASEM’s program to certify master’s
degree programs that meet ASEM program standards. He was instrumental in the founding of a master’s
program in EM at the University of Tennessee and the master’s and Ph.D. in engineering management at the
University of Alabama in Huntsville. His research and teaching focuses on behavioral concepts in management
and the challenges of managing knowledge workers. Dr. Westbrook received his Ph.D. degree from Virginia
Tech in Industrial Engineering and Operations Research, while minoring in Management. His master’s degree is
from the University of Tennessee in Industrial Engineering with a minor in Labor Economics. He received a B.E.
from Vanderbilt in Electrical Engineering. In addition to ASEM, he is also a member of: ASEE, IIE, and NSPE. Dr.
Westbrook authored or co-authored 20+ refereed papers on engineering management topics. Dr. Westbrook
has developed a series of seminars on managing knowledge workers. He and a team of talented professionals
have delivered these seminars to a variety of clients in several states.

Li Da Xu, Old Dominion University

Li Da Xu is an IEEE Fellow, Founding Chair of IFIP TC8 WG8.9, Founding Chair of the IEEE SMC Society Technical
Committee on Enterprise Information Systems, and Founding Editor-in-Chief of the engineering journals entitled
Journal of Industrial Information Integration (Elsevier), Journal of Industrial Integration and Management (World
Scientific), Enterprise Information Systems (Taylor & Francis) and Founding Co-Editors-in-Chief of Frontiers of
Engineering Management. He is an endowed Changjiang Chair Professor by the Ministry of Education of China.
His affiliations include the Institute of Computing Technology, the Chinese Academy of Sciences, the University of
Science and Technology of China, Shanghai Jiao Tong University, the China State Council Development Research
Center, and Old Dominion University, USA. He participated in early research and educational academic activities
in the subject of systems science and engineering. Professor Xu collaborated and worked extensively with
pioneering scholars such as West Churchman, John Warfield, and Qian Xuesen. Furthermore, he spearheaded
early research and educational academic activities in the subject of information systems and enterprise systems,
which started in early 1980s. He is the author of the recent book entitled Enterprise Integration and Information
Architecture and the co-author of the book entitled Systems Science Methodological Approaches published by
Taylor & Francis Group. His work has been cited by Qian Xuesen and other well-known scholars.

414
Index

A
Accounting xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Asset xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Balance Sheet xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Cash Flow Statement xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Income Statement xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Owner’s Equity xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Stakeholder’s Equity xiii, 199, 200, 201, 204, 205, 219, 220, 222, 223, 243, 244
Advanced Stochastic Models 122
After Tax Analysis 217, 218, 242, 248
American Society of Engineering Management i, 149, 182, 223
Analytical Hierarchy Process 171, 182, 250
Architectural Design 274

B
Balance Sheet xxiii, 202, 205, 206, 207, 209, 210, 211, 212, 217, 218, 223, 242, 243
Benefit Cost Analysis 168, 232, 235
Bottom-Up Approach xxi, 277
Brownian Motion 124

C
Cash Flow Patterns 230
Complexity 280, 290, 300, 301, 308, 314, 315, 329
Consequence Estimation 326
Consumer Price Index 240
Contribution Margin 221, 222
Contribution Margin Ratio 221, 222
Copyrights 24
Culture 22

D
Decision Analysis xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Additive Value Model xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Advantages xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Dialog Decision Process xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Disadvantages xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Imperfect Information xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Influence Diagram xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Multiple Objective Decision Analysis xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Perfect Information xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Risk Profile xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Single Attribute Utility xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Swing Weights xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Uncertainty xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Value Functions xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Value of a Test xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Values and Outcomes xi, 8, 151, 152, 153, 162, 165, 166, 167, 248
Decision Theory School 34, 35
Depreciation xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
Book Value xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
Depreciable Cost xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
Depreciation xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248

415
 Double Declining Balance Method xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
First Cost xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
Modified Accelerated Cost Recovery Systems xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247,
248
Straight Line Depreciation xxiv, 212, 213, 214, 215, 216, 217, 218, 242, 243, 244, 246, 247, 248
Disposal 215, 217, 218, 245, 270, 279

E
Empirical School 30, 34, 35
Engineering Management i, ii, vii, xix, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 132, 143, 149, 170, 182, 223,
282, 286, 290, 309, 315, 335, 414
Definition of Engineering Management i, ii, vii, xix, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 132, 143, 149,
170, 182, 223, 282, 286, 290, 309, 315, 335, 414
Knowledge Roles i, ii, vii, xix, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 132, 143, 149, 170, 182, 223, 282,
286, 290, 309, 315, 335, 414
Related Conferences i, ii, vii, xix, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 132, 143, 149, 170, 182, 223, 282,
286, 290, 309, 315, 335, 414
Related Journals i, ii, vii, xix, 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 132, 143, 149, 170, 182, 223, 282, 286,
290, 309, 315, 335, 414
Ethical Decision-Making 20
Ethics vii, 17, 18, 24
External Environment 36, 367

F
Figures of Merit 232
Annual Worth 232
Capitalized Cost 232
Capital Recovery 232
Future Worth 232
Present Worth 232
Financial Accounting 201, 222, 223
Financial Condition 202, 206
Foreign Corrupt Practices Act 22

H
Hard and Soft Systems Thinking xxiv, 288, 289
Herzberg’s Motivators and Hygienes 40, 44
Holism xxiv, 285, 289, 295, 308, 314
Human Behavioral School 35

I
Income Statement xxiii, 202, 204, 205, 206, 207, 209, 211, 212, 214, 217, 218, 223, 242, 243
Intellectual Property 18, 23, 24
Interest xx, xxiv, 213, 214, 219, 226, 227, 228, 229, 230, 232, 233, 234, 243, 244, 245, 246, 247, 289
Compounding xx, xxiv, 213, 214, 219, 226, 227, 228, 229, 230, 232, 233, 234, 243, 244, 245, 246, 247, 289
Effective Interest Rate xx, xxiv, 213, 214, 219, 226, 227, 228, 229, 230, 232, 233, 234, 243, 244, 245, 246, 247,
289
Simple xx, xxiv, 213, 214, 219, 226, 227, 228, 229, 230, 232, 233, 234, 243, 244, 245, 246, 247, 289
Internal Environment 37
Internal Rate of Return 232, 235, 248
International Council on Systems Engineering 266
Invention Disclosure 23
Investment Tax Credit 218, 243, 244, 247
ISO/IEC 15288 xx, 269, 270, 279, 280

416
J
Justice Rule 20, 21

L
Likelihood Estimation 326

M
Markov Chains 115, 117, 118, 122, 124
Absorbing 115, 117, 118, 122, 124
Continuous Time 115, 117, 118, 122, 124
Discrete-time 115, 117, 118, 122, 124
Maslow’s Hierarchy 39, 40, 44
Mathematical School 30, 34, 35
McClelland’s Need to Achieve 41
McGregor’s Theory X and Theory Y 39, 44
Minimum Attractive Rate of Return 226, 245, 249
Moral Rights Rule 20
Multi-Attribute Analysis 170, 179
Multi-Criteria Analysis xii, 169, 170
Analytical Hierarchy Process xii, 169, 170
Analytic Network Process xii, 169, 170
Multi Attribute Analysis xii, 169, 170
Utility Theory xii, 169, 170

N
National Society of Professional Engineers 18

O
Operation Research 182

P
Patents 23
Practical Rule 20, 21
Price Indices 241
Project Management xv, 7, 8, 9, 149, 307, 315

Q
Queuing Theory 118
Little’s Rule 118
Single Server - Single Channel 118

R
Requirements xxiv, 269, 270, 273, 280
Requirements Analysis 269, 273
Risk xvi, xx, xxi, xxiv, 157, 162, 167, 168, 249, 317, 318, 319, 320, 321, 322, 326, 327, 328, 331, 332, 333, 335
Risk Management xvi, xxi, 317, 319, 320, 321, 335
Risk Ranking 328
Risk Scenarios xxi, xxiv, 322, 326, 328

S
Sarbanes-Oxley Act 23
Scenario Identification 321
Simulation xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150, 270, 313, 414
417
 Agent Based Modeling xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150,
270, 313, 414
ARENA xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150, 270, 313, 414
Continuous Simulation xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150,
270, 313, 414
Discrete Event Simulation xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149,
150, 270, 313, 414
Monte Carlo Simulation xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149,
150, 270, 313, 414
Optimization xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150, 270, 313,
414
Simulation Applications xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149,
150, 270, 313, 414
Simulation Engineering xi, xix, 125, 126, 129, 131, 132, 133, 134, 135, 136, 139, 140, 141, 143, 145, 149, 150,
270, 313, 414
Social Systems School 34, 35
Stakeholders xix, 20, 270, 284, 286, 334, 335
Stochastic Models 122, 130
Stockholder’s Equity xxiii, 209, 210, 211
Strategic Intent 362, 366, 368, 370
Strategic Management xvii, xxi, 8, 14, 15, 38, 361, 362, 363, 364, 365, 378
Strategic Management Process xxi, 363, 365
Deploying Resources xxi, 363, 365
Deploying the Strategic Intent xxi, 363, 365
Performance Evaluation xxi, 363, 365
Systemic Framing 310
Systems Thinking xv, xvi, xxi, xxiv, 281, 285, 286, 287, 288, 289, 290, 291, 292, 293, 297, 299, 300, 301, 304,
305, 308, 309, 310, 312, 313, 314, 315, 316

T
Target Net Profit 222

U
Use Cases 271
Utilitarian Rule 20
Utility Theory 168, 174, 180

V
Validation 270, 276, 278
Verification 270, 276, 277

418
419
420