• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Gen sessionthomas.riskofsystemproblemfinal23feb12
 

Gen sessionthomas.riskofsystemproblemfinal23feb12

on

  • 9,920 views

 

Statistics

Views

Total Views
9,920
Views on SlideShare
9,920
Embed Views
0

Actions

Likes
0
Downloads
24
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Similar chartsEKHO InstituteConrad HuangKen BeckScott Antler

Gen sessionthomas.riskofsystemproblemfinal23feb12 Gen sessionthomas.riskofsystemproblemfinal23feb12 Presentation Transcript

  • 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
  • Three roles required for anysystem oriented program to succeed Design & Management Integration Role Role Build Component Role 2 2
  • 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
  • Controlling Program Risk is a Key Management Team Responsibility Program Risk StrategyManagement Role 4 4
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Cost of a design change to fix a System Problem (automotive)** (Paul Ranky Dept Mechanical and Industrial Engineering, NJIT New Jersey ) 23 23
  • 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
  • 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
  • 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
  • BACKUP 27 27
  • 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
  • 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
  • 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