1. Risk Associated with
Having a System Problem
How to prevent your program from producing a
lot of expensive parts – but no system
John A. Thomas
President INCOSE (2012-2014)
Senior Vice President & Chief System Engineer
Booz Allen Hamilton
NASA PM Challenge
23 February 2012
1

2. Three roles required for any
system oriented program to succeed
Design &
Management
Integration
Role
Role
Build Component
Role
2 2

3. No one individual can execute these roles
– it takes a multi-disciplinary team to do so --
Design and Integration Role Management Role
Executed by a SE&I Team
• System Engineer Executed by a Management Team
• Subject Matter Experts • Program Manager
• Engineers & Scientists • System Engineer
• Sociologists. • Stakeholders
• Anthropologists • Users
• Economists • Policy Makers
• Builder Representatives • Cost Lead
• Policy Makers • Schedule Lead
• Users • Contracts Officer
• … • …
Design &
Integration Mgt Role
Role
Build Component Role
Executed Implementation Teams
• Component Builders
• Management Team
Representatives (Program
Build Manager. Stakeholders, …)
Component Role • SE&I Team Representatives
(System Engineer, SME’s)
• …
3 3

4. Controlling Program Risk is a Key
Management Team Responsibility
Program Risk Strategy
Management
Role
4 4

5. The Management Team breaks program risk into areas
COST
• Can labor and material profiles be Overall
maintained within the existing Program Risk
budget profile?
• Can funding sources be maintained
across life of program ?
Cost
5

6. The Management Team breaks program risk into areas
SCHEDULE
• Are work tasks generating Overall
unnecessary dependencies that Program Risk
propagate impact across program ?
• Are critical path tasks planned with
adequate contingency ?
Cost Schedule
6

7. The Management Team breaks program risk into areas
PERFORMANCE
• Can it jump high enough ? Overall
• Will it go far enough ? Program Risk
• Does it go fast enough ?
• Is it going to be tough enough ?
Cost Schedule Performance
7

8. The Management Team breaks program risk into areas
TECHNOLOGY
• Does technology provide a solution Overall
that meets SWaP constraints ? Program Risk
• Can technology implement design
within cost and time constraints ?
Cost Schedule Performance Technology
8

9. The Management Team breaks program risk into areas
PRODUCTION
• Do we understand how to Overall
manufacture parts/components ? Program Risk
• Can we sustain production rates of
the parts/components ?
Cost Schedule Performance Technology Production
9

10. The Management Team breaks program risk into areas
- Many Times One Risk Area is Overlooked –
The Risk of Having a System Problem and
it’s impact on other Risk Areas
Overall
Program Risk
Cost Schedule Performance Technology Production System ?
Problem
10

11. Controlling system problems is a key System
Engineering & Integration Team responsibility
Does the System Fit Together?
Does it Behave as Expected?
Design &
Integration
Role
11 11

12. The focus of a SE&I Team is to make
-- “the Whole greater than the Sum of Its Parts**” --
n
The Whole Parts j Delta
(System) j=1
(Subsystems) j (Interfaces)
The System
I/F # 1 I/F # 3 I/F # 2
Subsystem # 1 Subsystem # 3
I/F # 4 I/F # 5
Subsystem # 2
I/F # 7
I/F # 6
** -- Adapted from Allen Fairbairn remarks, Chief Systems Engineer of the Chunnel Project)
12 12

13. What generates system problems ?
When the “Whole” is not greater than the “Sum of Its Parts” **
n
The Whole Parts j Delta
(System) j=1 (Subsystems) j (Interface)
The System
I/F # 1 I/F # 3 I/F # 2
Subsystem # 1 Subsystem # 3
I/F # 4 I/F # 5
Subsystem # 2
I/F # 7
I/F # 6
** -- Adapted from Allen Fairbairn remarks, Chief Systems Engineer of the Chunnel Project)
13 13

14. The SE&I Team must properly engineer interfaces to
reduce the likelihood of a system problem
Subsystem definition is tightly coupled to it’s I/F
n
The Whole Parts j Delta
j=1 (Engineered
(System) (Subsystem) j
Interfaces # 2)
1)
3)
The System
I/F ## 1
I/F 1 I/F # 3 I/F # 3 I/F ## 2
I/F 2
Subsystem # 1 I/F # 4 Subsystem # 3
I/F # 4
I/F # # 3
I/F 4 I/F # 5
I/F # 1 Subsystem # 2
I/F # 7
I/F # 6 I/F # 5
I/F # 5
I/F # 6
** -- Extended from Allen Fairbairn remarks, Chief Systems Engineer of the Chunnel Project)
14 14

15. Tag Line
“The Whole greater than the sum of its parts”
The right interfaces” for “The right subsystems”
to produce “The right system behavior” within
“The users environmental constraints”
The System
I/F # 1 I/F # 3 I/F # 2
Subsystem # 1 Subsystem # 3
I/F # 4 I/F # 5
Subsystem # 2
I/F # 7
I/F # 6
** -- Adapted from Allen Fairbairn remarks, Chief Systems Engineer of the Chunnel Project)
15 15

16. What does a System Problem Look Like?
System Problem # 1 -- A system problem exists when …
The behavior of the whole (System) is misaligned with the
users vision of how to use that system within their environment
User - Envisioned Behavior Delivered Behavior
and Actual Environment and Assumed Environment
16 16

17. What does a System Problem Look Like?
System Problem # 1 -- A system problem exists when …
The behavior of the whole (System) is misaligned with the
users vision of how to use that system within their environment
Delivered Behavior
User - Envisioned Behavior and Assumed Environment
and Actual Environment
17 17

18. What does a System Problem Look Like?
System Problem # 2 -- A system problem exists when …
The parts (subsystems) interface together, each works! – but
do not produce the expected behavior of the whole (system)
Interfaces
Subsystems
Expected Behavior
18 18

19. What does a System Problem Look Like?
System Problem # 3 -- A system problem exists when …
The implemented parts (subsystems) fail to interface with each
other and cannot produce something that even looks like a
whole (system)
Interfaces
Subsystems
Expected Behavior
19 19

20. What does a System Problem Look Like?
System Problem # 3 -- A system problem exists when …
The implemented parts (subsystems) fail to interface with each
other and cannot produce something that even looks like a
whole (system)
Interfaces
Subsystems
Expected Behavior
20 20

21. System Problems (many times)
drive the other risk areas within a program !
n
The System Subsystems j Interfaces
j=1
Chassis Super Light
Car Strong
3
Engineered
j=1
Body Interfaces
• 200 miles per hour
• 0 to 60 in 4 seconds
• 50 miles per gallon
• 24 hour sustained operation Light
• All terrain Strong
Engine
Low Drag
Light
High Temp
High Power
21

22. The cost impact of having a System Problem risk
Chassis
Total Cost of Subsystems
$ 400M (80% of Program)
Dev Cost = $ 110M
Body
3 Engineered
Interfaces
How many
j=1 Dev Cost = $ 90M $$$ to
$ 500M abate Impact ?
Development Engine
Dev Cost = $ 200M
22

23. Cost of a design change to fix a
System Problem (automotive)
** (Paul Ranky Dept Mechanical and Industrial Engineering, NJIT New Jersey )
23 23

24. Cost of design change (simplified)
-- Many Times –
$$$ System Problems are often
Discovered in this Timeframe 100’s X
$$ 10’s X
$ 1’s X
X
PDR CDR Unit Subsystem System Deployed
Testing Testing Testing
24 24

25. The Management Team can abate
program impact from System Problems
Treat system problems as a major area of program risk
Get the best SE&I team that is available
– Analytically strong
– Possessing a mindset of collaboration
– Demonstrating an inclusive leadership style
– Experienced in get the most out of multi-disciplinary teams
 Give the SE&I team the resources and time to do their job
– Don’t short use of simulation and prototyping for design
– Ensure the design goes through an independent, robust
verification and validation
 Use a testing strategy that pushes aspects of subsystem
and system test early into system lifecycle
25 25

26. John Thomas is the Chief Systems Engineer and a Senior
Vice President at Booz Allen Hamilton. He has worked on
space collection and ground processing programs for the
defense and security communities.
John is also the President of the International Council on
Systems Engineering (INCOSE), which advocates for
systems engineers and development of the science of system
engineering
26 26

27. BACKUP
27 27

28. Example of generic pert network patterns
Design, Build, Test; and Assembly, Integrate
Generic Standalone Patterns
Component Assembly Integrate
Design Build Test Assembly
Test XY
X with Y
Integrate
XY with ST
Assembly
Test ST
S with T
Generic Coupled Pattern
Component A
Assembly
Design Build Test A with B
Test AB
Component B Integrate Test
AB with C AB with C
Design Build Test
Component C
Design Build Test
28 28

29. Generic pert network from templates
Note:
Errors found at subsystem & system integration (far right) are fixed at the component
level (far left) and then pass through each integration step
29 29

30. These skills/experience of a System Engineer with Moxie
Problem Solver
Craftsman
Critical Thinker,
Processes, System Thinker,
Methods, Associative Thinker
Techniques, Ability for Abstraction
Tools Skills of a
System Engineer with Moxie
Environmental
Functional Understanding
Depth as well as Tailor Development Lifecycles,
Multidisciplinary Knowledge of Technologies,
Breadth Knowledge of Mission,
Knowledge of Domains
Programmatic Leadership
Understanding
Presence under Stress,
Acquisition Planner, Conflict Manager,
Contract Planner, Decision Maker,
Cost Estimator, Communicator,
Schedule Estimator Team builder,
Visionary,
Mentor
30 30