Risk Associated with     Having a System ProblemHow to prevent your program from producing a  lot of expensive parts – but...
Three roles required for anysystem oriented program to succeed        Design &                     Management       Integr...
No one individual can execute these roles       – it takes a multi-disciplinary team to do so --Design and Integration Rol...
Controlling Program Risk is a Key   Management Team Responsibility                          Program Risk StrategyManagemen...
The Management Team breaks program risk into areas                  COST    • Can labor and material profiles be          ...
The Management Team breaks program risk into areas              SCHEDULE    • Are work tasks generating                   ...
The Management Team breaks program risk into areas          PERFORMANCE     • Can it jump high enough ?                 Ov...
The Management Team breaks program risk into areas           TECHNOLOGY     • Does technology provide a solution          ...
The Management Team breaks program risk into areas            PRODUCTION     • Do we understand how to                    ...
The Management Team breaks program risk into areas- Many Times One Risk Area is Overlooked –        The Risk of Having a S...
Controlling system problems is a key SystemEngineering & Integration Team responsibility                       Does the Sy...
The focus of a SE&I Team is to make     -- “the Whole greater than the Sum of Its Parts**” --                             ...
What generates system problems ?   When the “Whole” is not greater than the “Sum of Its Parts” **                         ...
The SE&I Team must properly engineer interfaces to        reduce the likelihood of a system problem    Subsystem definitio...
Tag Line       “The Whole greater than the sum of its parts”          The right interfaces” for “The right subsystems”    ...
What does a System Problem Look Like?System Problem # 1 -- A system problem exists when …The behavior of the whole (Syst...
What does a System Problem Look Like?System Problem # 1 -- A system problem exists when …The behavior of the whole (Syst...
What does a System Problem Look Like?System Problem # 2 -- A system problem exists when …The parts (subsystems) interfac...
What does a System Problem Look Like?System Problem # 3 -- A system problem exists when …The implemented parts (subsyste...
What does a System Problem Look Like?System Problem # 3 -- A system problem exists when …The implemented parts (subsyste...
System Problems (many times)        drive the other risk areas within a program !                                   n     ...
The cost impact of having a System Problem risk                                     ChassisTotal Cost of Subsystems$ 400M ...
Cost of a design change to fix a                                              System Problem (automotive)** (Paul Ranky De...
Cost of design change (simplified)                               -- Many Times –$$$                       System Problems ...
The Management Team can abate       program impact from System ProblemsTreat system problems as a major area of program r...
John Thomas is the Chief Systems Engineer and a Senior Vice President at Booz Allen Hamilton. He has worked on space colle...
BACKUP    27   27
Example of generic pert network patterns            Design, Build, Test; and Assembly, IntegrateGeneric Standalone Patter...
Generic pert network from templatesNote:Errors found at subsystem & system integration (far right) are fixed at the compon...
These skills/experience of a System Engineer with Moxie                                                            Problem...
Upcoming SlideShare
Loading in …5
×

Gen sessionthomas.riskofsystemproblemfinal23feb12

15,351 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
15,351
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Similar chartsEKHO InstituteConrad HuangKen BeckScott Antler
  • Gen sessionthomas.riskofsystemproblemfinal23feb12

    1. 1. Risk Associated with Having a System ProblemHow 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. 2. Three roles required for anysystem oriented program to succeed Design & Management Integration Role Role Build Component Role 2 2
    3. 3. No one individual can execute these roles – it takes a multi-disciplinary team to do so --Design and Integration Role Management RoleExecuted 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. 4. Controlling Program Risk is a Key Management Team Responsibility Program Risk StrategyManagement Role 4 4
    5. 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. 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. 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. 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. 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. 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 RiskCost Schedule Performance Technology Production System ? Problem 10
    11. 11. Controlling system problems is a key SystemEngineering & Integration Team responsibility Does the System Fit Together? Does it Behave as Expected? Design & Integration Role 11 11
    12. 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. 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. 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. 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 SystemI/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. 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. 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. 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. 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. 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. 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. 22. The cost impact of having a System Problem risk ChassisTotal 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. 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. 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. 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. 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 forsystems engineers and development of the science of system engineering 26 26
    27. 27. BACKUP 27 27
    28. 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. 29. Generic pert network from templatesNote:Errors found at subsystem & system integration (far right) are fixed at the componentlevel (far left) and then pass through each integration step 29 29
    30. 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 UnderstandingDepth 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

    ×