Tracking the Constant of Change

Tracking the Constant of Change
The Delta Forum 2003 Operating within a Risk Averse Aerospace Environment – Coping with the Unknown Engineering Technology Management Tracking the Constant of Change Systems History Society Legal Aspects Economics Logistics Supply Chain Risk Technical Information Multidiscipline Design Product Development Sponsored by the AIAA Engineering & Technology Management Group Session Chair: JoAnne Rocker

Overview Introduction – Carolyn Griner, ETM Director
Risk Acceptance and Society at Large Tim Howard, Society & Aerospace Technology TC Balancing Technology Risk and the Return on Investment Paul Collopy, Economics TC Legal Considerations Affecting Risk Acceptance Scott Johnson, Legal Aspects TC Risk Mitigation through Knowledge Management Joanne Rocker, Technical Information TC Risk Mitigation and System Integration Peter Rutledge, Systems Engineering TC Multidisciplinary Design Optimization as a Powerful Risk Mitigation Tool Achille Messac, MultiDisciplinary Design TC Integrating Risk Management Richard Raiford, ManagementTC Panel Discussion – All Speakers

Introduction Our Group’s TCs examine the issues affecting the aerospace industry in the areas of Engineering and Technology Management Our disciplines include: Economics History Legal Aspects Logistics Management Multidisciplinary Design Optimization Product Development Risk Management Societal Aspects Supply Chain Management Systems Engineering Technical Information

Introduction Our purpose today is to examine a single issue affecting the aerospace industry, from the several perspectives of the various disciplines within the Group This year’s theme addresses the change in how the aerospace industry accepts the risks inherent in our technologies, to develop, integrate, and deliver goods and services in a global marketplace Our speakers come from across the industry to address topics in Risk and Society Intellectual Property Investment Knowledge Management Systems Engineering Mutlidisciplinary Design Aerospace Management Our panel at the end will draw together the separate perspectives in response to your questions

Society & Aerospace Technology TC
Topic 1 Risk Acceptance And Society at Large Tim Howard Society & Aerospace Technology TC

Historical Perspective of Risk Society’s Response to Risk
Overview Historical Perspective of Risk Society’s Response to Risk Society, Risk and Aerospace Aerospace, Risk and Society Against the Gods; The Remarkable Story of Risk by Peter L. Bernstein

Risk “The word ‘risk’ derives from the early Italian risicare, which means ‘to dare.’ (Bernstein)

A Historical Perspective of Risk
Before 1200s - Gambling, Arabic numbers & Fibonacci (1, 2, 3, 5, 8) The Renaissance 1500s – Cardano, gambling & probability 1600s – Pascal & Fermat – Probability; Graunt & statistical sampling – London population tables 1700s Daniel Bernoulli: information quality & utility value De Moivre – normal distribution & standard deviation (The Bell Curve) Insurance & the coffee houses – Lloyd’s 1875 – Galton & Regression to the Mean (sweetpeas) 1900s –The Rationality Debate Uncertainty & failure of invariance – same problem presented differently results in different choices

Society’s Response to Risk
Until 1960s, prevailing idea is that individuals are naturally risk averse 1960s - Loss aversion more powerful motivation than risk aversion – we hate to lose, and will take the gamble to avoid a sure loss Aerospace losses often more catastrophic, and more sensational than other technology or system losses Risk tolerance increases in relation to our attitudes about the future Issue presentation key to the acceptance or rejection of risk and hence loss Need to identify society’s level of acceptable loss Version A: $30 to start; Choices are coin flip with heads = wins $9, tails = lose $9; no flip = keep the $30 Possible outcomes are $21, $30, $39 70% choose to flip coin Version B: $0 to start; Choices are coin flip with heads = wins $39, tails = wins $21; no flip = given $30 Possible outcomes are $21, $30, $39 43% choose to flip coin

Society’s Response to Risk
Society needs risk to grow; historical outlets are exploration and commerce Exploration & development of old frontiers driven by commercial needs for new markets The Phoenicians, Columbus, The British Empire 10,000 years of maritime technologies enabled exploration and commerce <500 years of risk management to improve probability of success Insurance, economic forecasting, investment strategies

Society, Risk and Aerospace
The first century of flight made us the new risk outlet for societal growth Air travel, cargo movement, satellite systems and information transport fundamental to the success of the new global economy We enable exploration and development Shackleton, Byrd, & the 19th century frontier Space is the new frontier for human exploration & commercial development 100 years of aerospace technologies available to support the need to grow New fields use risk management to improve probability of success (National defense, air traffic control, space launch) We develop new technologies and new applications of existing technologies to provide social growth

Aerospace, Risk and Society
Our industry was founded by risk takers; now we operate in a risk-averse mode Societal growth stunted, or turned inwards; not the natural process We need to place our mean to the right of where we are, and start regressing – we need to take more risks Rejuvenate our industry Rekindle interest in our profession Reclaim technology leadership role society needs us to play IT can only give us a virtual frontier; we have already delivered the real thing We need to embrace our role as the new enabler of societal growth It’s time for a fresh deck of cards…

Risk … if we dare

Economics Technical Committee
Topic 2 Risk and the Return on Investment Paul D. Collopy Economics Technical Committee

Managers: Embrace Risk Eliminate unnecessary downside risk
Two Messages Managers: Embrace Risk Eliminate unnecessary downside risk Know what you are signing up for Use strategies like hedging to improve risk+return Analysts: Don’t lose sight of the Fundamentals E[NPV] is the basic metric (return) Adjust for risk aversion when  > 4% Equity otherwise never trade E[NPV] for 

Great idea, if there is no cost in product performance
Risk Mitigation Everybody loves but Great idea, if there is no cost in product performance in development time Risk free development  Sunset Industry Performance > SoA = Technical Risk

Low Risk Program Risk = Uncertainty Risk Combat Range Combat Range
What is Risk? Risk = Uncertainty Low Risk Program 400 500 600 Risk Combat Range 400 500 600 Combat Range

Military Aerospace Development
5 10 15 20 Years Concept Studies Tech Development Dem / Val E & MD Production Entry into Service Careful Risk Mitigation ensures the system will achieve obsolescence and military irrelevance upon entry into service

Venture Star

Hope for Success / Plan for Failure Do not Bet the Company
Caveats Choose your Battles Hope for Success / Plan for Failure Do not Bet the Company

Development Cost or Schedule
Choose your Battles Risks Interact: ~ 5 Technical Risks can be managed at once Use Spiral Development for more ambitious programs 1 Average Probability of Failure Development Cost or Schedule Diseconomy of Scale

Hope for Success / Plan for Failure
Quote expected performance Plan backup designs Low risk Prepare to take a performance hit There is always next time

  Typical Business Value of Money Neutral Attitude to Risk 16 u $ .
Betting the Company 0% 4% 8% 12% 16% 20% % of Equity Value / Equity Typical Business Value of Money Neutral Attitude to Risk 16   u $ .   e       1 Risks < 4% equity: value = avg. return For Risk = 20% eq. business is strongly risk averse

Using the Value of Money Curve
0% 4% 8% 12% 16% 20% % of Equity Value / Equity + 8% Arbitrary Base Point p Upside = 3% 1 - p - 8% Downside =5% Value of deal = 3%p + 5%(1-p) Downside Upside

Risk has upside and downside
Summary Risk has upside and downside Risk-free designs condemn the industry to mediocrity Good risks need to be managed not mitigated

Affecting Risk Acceptance R. Scott Johnson
Topic 3 Legal Considerations Affecting Risk Acceptance R. Scott Johnson Legal Aspects of Aerospace TC McKee, Voorhees & Sease, LLP

liability Potential for What is risk?
People use PowerPoint to outline their speeches/presentations Quicker, less expensive than posterboard, transparencies, flip charts, less time to create in advance, also saves presentation time too. Flow and control - can store it and retrieve it, faster than transparencies or posers. Don’t have to get up to mess with things.

Negligence Duty Breach of Duty Injury Causation

Generally: Exercise Reasonable Care Breach of Duty Injury Causation
Negligence Duty Generally: Exercise Reasonable Care Breach of Duty Injury Causation

Specifics: Statutes, Rules, and Regulations Breach of Duty Injury
Negligence Duty Specifics: Statutes, Rules, and Regulations Breach of Duty Injury Causation

Specifics: Statutes, Rules, and Regulations
Federal Aviation Act of 1958 49 U.S.C. Provides regulatory authority for: Department of Transportation Aviation Economic Regulations or AERs 14 C.F.R. § Federal Aviation Administration Federal Aviation Regulations or FARs C.F.R. § National Transportation Safety Board 49 C.F.R. § 830, 31, and 45

Specifics: Statutes, Rules, and Regulations
State products liability laws “liability of a manufacturer or seller of a chattel which is defective and/or unreasonably dangerous and causes” injury. William R. Prosser, Handbood of the Law of Torts 641 (4th ed. 1971) Three theories of recovery: Warranty (contract remedy) Strict liability (tort remedy) Negligence (tort remedy) Vary by State

Negligence Duty Breach of Duty Injury Causation liability

Create broad range of compliance duties Create investigation bodies
The Bad Create broad range of compliance duties Create investigation bodies NTSB determines “probable cause” for all aircraft accidents in the U.S. Create Enforcement Procedures Civil and criminal penalties

Other Sources of Liability Contract provisions
The Bad Other Sources of Liability Contract provisions Other Federal and State Statutes and Regulations Environmental Intellectual Property Employment Corporate International Treaties

The Good Statutes can be good?

General Aviation Revitalization Act of 1994 (42 U.S.C. § 40101)
The Good General Aviation Revitalization Act of 1994 (42 U.S.C. § 40101) 18 year statute of repose prohibits any legal action for any aircraft, engine or part at issue Applies to all general aviation aircraft

The type certification components airworthiness
The Good General Aviation Revitalization Act of 1994 (42 U.S.C. § 40101) - Exceptions Manufacturer “knowingly misrepresented or concealed or withheld” from the FAA information relating to: The type certification components airworthiness

The Good General Aviation Revitalization Act of 1994 (42 U.S.C. § 40101) - Exceptions claimant was a passenger for purposes of receiving emergency or medical care

suit is brought under the manufacturer’s written warranties
The Good General Aviation Revitalization Act of 1994 (42 U.S.C. § 40101) - Exceptions suit is brought under the manufacturer’s written warranties

State statute of limitations International Treaties Warsaw Convention
The Good State statute of limitations International Treaties Warsaw Convention Other liability limiters Sales contract provisions shift liability away limit liability Insurance agreements cover yourself

x Risk Management Programs By whom? Government Initiated NTSB or FAA
The Beautiful Risk Management Programs By whom? Government Initiated NTSB or FAA Insurance Company In-house x

Risk Management Programs Evaluate loss potential
The Beautiful Risk Management Programs Evaluate loss potential Use established risk management techniques Put a plan in action

The Beautiful Risk Management Programs Evaluate loss potential Total potential loss X % Chance loss will occur Account for “all” losses (Economic & Social) Use established risk management techniques Put a plan in action

The Beautiful Risk Management Programs Evaluate loss potential Use established risk management techniques Eliminate (Don’t Do It) Reduce (Rapid Response) Transfer (Insurance) Retain (Savings Plan) Put a plan in action

The Beautiful Risk Management Programs Evaluate loss potential Use established risk management techniques Put a plan in action Identify the risks Maintain database of accidents, lawsuits, liability situations Create contingencies and risk reducing methods Example: British Airways BASIS program

Thank you! R. Scott Johnson McKee, Voorhees & Sease, PLC
801 Grand Avenue, Suite 3200 Des Moines, Iowa 50309

Risk Mitigation through Knowledge Management
Topic 4 Risk Mitigation through Knowledge Management JoAnne Rocker NASA Scientific and Technical Information Program Chair, AIAA Technical Information Committee

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Discussion Topics Risk mitigation Knowledge management Communities of practice Lessons Learned Portals Technology and cultural change Conclusion

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Risk Mitigation Risk Management (RM) is an organized, systematic decision-making process that efficiently identifies, analyzes, plans (for the handling of risks), tracks, controls, communicates, and documents risk Purpose: increase the likelihood of achieving program/project goals Risk mitigation depends upon risk analysis Many useful sources of information should be compiled to provide input for risk analysis, for example: Test data Expert opinions Hazard Analyses, Failure Modes and Effects Analyses Lessons learned data and historical information from other programs/projects Software verification and validation Risk data generated in other steps in the process Risk mitigation is a process involving information analysis from a variety of data sources Risk Management Procedures and Guidelines, NPG

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Knowledge Management Knowledge management refers to strategies and structures for maximizing the return on intellectual and information resources Tacit form (human education, experience and expertise) Explicit forms (documents and data) Creates new value by improving the efficiency and effectiveness of individual and collaborative efforts to organize and use information resources Increases innovation and improves decision-making From: “Defining Knowledge Management”, destinationKM.com,

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Why does the aerospace industry need KM? Aerospace is a competitive knowledge-based industry Continual learning and re-using information to be competitive, respond to change, stay innovative, and discover new products and processes Long-term life cycle for technology development and knowledge can be lost or forgotten if no KM process is in place (KM provides continuity as information is captured, stored, and made available for use) Virtual workforce (national and internationally located) need to share resources and information for collaborative work Cyclical hiring practices hinders knowledge sharing between experienced employees and new hires

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Knowledge management strategies and structures Communities of practice Lessons learned databases Portals

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Communities of Practice “Definitions of community of practice vary somewhat, but are usually taken to mean a group of practitioners who share a common interest or passion in an area of competence and are willing to share the experiences of their practice.” Communities of practice can also be known as: Thematic groups (World Bank) Learning communities or networks (Hewlett Packard) Best practice teams (Chevron) Communities exist within companies and as well as across company boundaries From: “Communities for knowledge management,” by Stephen Denning, article found at

Ultimately, all companies seek sustainable competitive advantage -- in processes as well as in products and services. Many people see this as tied to a process of continuing innovation. In turn, innovation depends on human qualities such as curiosity, insight, ideas and determination. In the last analysis, innovation depends on people applying knowledge in ways that yield new solutions to old and new problems. Much of what people do in organizations occurs in the context of Communities of Practice. There is where best practices and innovations first emerge and where the solutions to shared problems are first identified. For this reason, many companies are determined to encourage, promote, and support CoPs, especially in areas, processes and functions where an edge in performance provides a competitive advantage (whether it be financial, operational or in the eyes of the customer). It takes time for CoPs to emerge, to flourish and to become productive. More important, they can't be mandated or managed in a heavy-handed way. CoPs, then, are an investment in the organization's future, not a quick fix to be applied for the sake of short-term gain. Most important, many will exist whether or not management chooses to encourage and support them; they are a natural part of organizational life. And that means they require a minimal investment on the part of the organization. The business case for CoPs is this: for a quite modest investment in terms of today's resources, organizations can reap huge rewards in terms of tomorrow's results. Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Common traits of communities of practice (CoP) Strong sense of identity with the group - members often from the same line of work (salespeople, technicians, engineers, webmasters, etc). Practice is not captured in formal procedures – people learn how to do the work and are seen as competent or not based on working with others Use the same the same tools, methods, techniques Express themselves in a common language Cross-disciplinary not attached to organizational chart Differ from projects or teams Groups are self-selecting Emphasis sharing knowledge and experiences Source: Fred Nickols, “Communities of Practice: Definition, Indicators & Identifying Characteristics,”

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Lessons Learned “Lessons learned is a narrative account of an actual experience providing an analysis of what happened, what was expected to happen, an understanding of why there were differences, and what was learned.” Source: Schlumberger

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Portals “A portal is a site featuring a suite of commonly used services, serving as a starting point and frequent gateway to the Web (Web portal) or a niche topic (vertical portal). Web portal services often include a search engine or directory, news, , stock quotes, maps, forums, chat, shopping, and options for customization.” From: Marketing Terms.com,

Example: aerospace portal (http://aerade.cranfield.ac.uk/)

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Technology but part of process to implement knowledge management but changing culture is essential to KM success Gartner Inc. conducted a survey on how well organizations utilize knowledge management and found: Survey participants scored from high of 78% to low of 2% Worst offender was the government with 2% Government workers didn’t understand what knowledge management was and how to use it Effective knowledge management means information sharing and collaboration and agencies are not used to doing that French Caldwell, Gartner Research Director, "Knowledge management is a business process that has to be approached with discipline. It is not a technology. You can't buy it in a box." Source: William Matthews, “Knowledge management's 'worst‘” Federal Computer Week, April 25, 2002,

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product No KM technology or tool will be successful without a fundamental paradigm shift in corporate culture KM initiatives need acceptance and be seen as a way to do things differently Means user training, emphasizing the benefits of the new way of working KM is not a one-time investment but rather an ongoing process Top level management are the champions of KM initiatives Success or failure depends on a company's ability and willingness to make real cultural changes Source: Henry Newberry, “Knowledge Management and Corporate Culture,” Lotus Advisor Magazine, November 2002, p6,

Engineering Technology Management Tracking the Constant of Change History Society Legal Aspects Logistics Supply Chain Systems Economics Risk Information Technical Multidiscipline Design Development Product Conclusion Risk Mitigation and knowledge management Purpose of managing risk is to increase the likelihood of achieving program/project goals Way to mitigate risk is through process of risk analysis which draws upon many different types of data and information sources Knowledge management provides the structure for collecting, organizing, and making information available for use (communities of practice, lessons learned, portals) Leverages corporate knowledge and creates a collaborative work environment Business process - not a technology - that needs top-level support to be effective Knowledge management should be a business practice in the aerospace industry Knowledge-based industry Highly specialized technologies and processes making it vital to capture and retain corporate knowledge Innovation and knowledge creation are keys to survival in competitive marketplace and knowledge management is about getting the right information to the right people at the right time

and Systems Engineering Office of Safety & Mission Assurance
Topic 5 Risk Management and Systems Engineering Pete Rutledge, Ph.D Office of Safety & Mission Assurance NASA Headquarters Washington, DC Systems Engineering Technical Committee

Risk Management & Systems Engineering: Many Common Attributes
Both are concerned about mission success. Both deal with uncertainty. Both must work the entire life cycle. Both need the “Big Picture.” Both must deal with all system elements. Both are concerned about interfaces and dependencies. Both are threatened by complexity and tight coupling. Both can help help with trade-offs to optimize cost-effectiveness. Both benefit from many of the same tools. Both can provide valuable support to decision-makers.

Mission Success: What Can Go Wrong?
Hardware can fail Software can contain errors Humans can make mistakes There is a lot at stake! Human life Hardware Software Facilities Scientific knowledge Time Money Challenger: 7 lives Orbiter Payload Fleet grounded $2 Billion+ Mars Climate Orbiter: Spacecraft Science Program delayed $250 Million

Uncertainty: Probabilities & Consequences
What can go wrong with this project? How likely is it to go wrong? What would be the consequences if something does go wrong? How soon do we need to act? What can be done to prevent things from going wrong, or at least reduce the probability or severity of the consequences? What risk mitigation would be effective? Risk = Probability X Consequences

System Life Cycle: From Cradle to Grave
Risk originates and impacts system in all phases of the system life cycle. Formulation Advanced Studies Preliminary Analysis Definition Implementation Design Development Operations (including disposal) 70-90% of safety-related decisions (good & bad) are made early. Early decisions are cheap to make but have big effect on life cycle cost. Design process errors are the root cause of many failures. Systems Engineering & Risk Management need to begin early for maximum effectiveness.

The “Big Picture”: All Elements, Interfaces, & Dependencies
All system elements contribute to risk: Hardware Software Human Systems Engineering & Risk Management must deal with all: Elements Interfaces Dependencies System Software People Hardware

Confounding Combinations & Complications
The Hardware element Behavior and failure modes are relatively well understood Modeling and analysis is routine The Software element Systems are increasingly dependent on large, complex codes Difficult to exhaustively test large, complex code Often failures trace back to the errors in the requirements Many models for predicting reliability—but which one to use? The Human element Human error is said to contribute to 70-90% of accidents Human performance is difficult to model, analyze, and predict Interfaces & Dependencies Confounding combinations of complex and tightly coupled elements Demands a Systems Engineering & Risk Management approach

Complexity & Tight Coupling
Practically limitless, unforeseeable combinations of failures. System “unravelings” with an intelligence of their own; exposing hidden connections, neutralizing redundancies, bypassing firewalls, and exploiting chance circumstances for which no engineer could reasonably plan. Cascading failures can accelerate out of control, confounding human operators and denying them a chance for recovery. Systems Engineering & Risk Management become essential. Mouse Trap—a game by Milton-Bradley Accidents are inevitable -- “normal.” Charles Perrow, Normal Accidents

Optimizing Cost-Effectiveness: Risk as a Resource

Tools of the Trades Hazard Analysis (PHA, SHA, SSHA, O&SHA)
Reliability Analysis (for HW, SW, Human; RBD, prediction) Fault Tree, Success Tree, Event Tree Analysis Cause & Effect Diagrams (“Fishbone” Diagrams) Probabilistic Risk Assessment (PRA) Probabilistic Structural Analysis Failure Modes & Effects Analysis (FMEA) Pareto Analysis Monte Carlo simulation Cost and schedule analysis Data, trend, and statistical analysis And more…. Common to both Systems Engineering and Risk Management.

Systems Engineering & Risk Management for Decision Support
Given the common attributes just discussed, the Systems Engineering function is ideally suited employ Risk Management methodology to provide valuable support to aerospace engineering decision-makers.

Dr. Achille Messac Multidisciplinary Design Optimization
as a Powerful Risk Mitigation Tool Dr. Achille Messac Multidisciplinary Design and Optimization Laboratory Mechanical, and Aeronautical Engineering Department Rensselaer Polytechnic Institute

Five underlying questions will be addressed at the conference.
Presentation Outline 1- Multidisciplinary Design Optimization What is it? A bit of history… 2- Aerospace and other MDO Applications 3- Multiobjective reality -- Physical Programming 4- Venturing into the nondeterministic environment of RISK – The role of MDO 5- Optimization in Conceptual Design 6- Concluding Remark Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

From Early Timid Optimization Applications to MDO
From 50’s to 70’s, engineering optimization is - Primarily Uni-disciplinary Aerospace >> Structure – min. mass - Computationally Challenged - Of Timid Problem Scope - Heavily reliant on the defective MO method weighted sum Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

From Early Timid Optimization Applications to MDO -- Cont.
In early to mid eighties - Computers become faster, and start decreasing in cost - Optimal Control grows in popularity - Large Space Structures research grows - Concurrent Engineering becomes a cherished word - Bi-disciplinary optimization: Control-Structure (Messac, Hale) - NASA, Air Force, and JPL initiate MDO, CSI programs - Government financial resources relatively abundant (human, computer – however slow) - First Pre-MDO conference is held at Langley (Sobieski – 1984) Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

Mid 80’s to Mid 90’s - Computers are much faster and cheaper - AIAA MDO TC is born (Transition from Bi- to Multi-disciplinary) - MDO is still largely Deterministic - MDO is still implemented in later stages of design Not at Conceptual Design Stage - MDO is still largely addressing traditional disciplines Aero, Structure, Control – Neglecting Cost, Management, etc. While… - MDO’s popularity and use grows many-fold (e.g. GE heating element) - MDO research enjoys strong international growth - MA&O Conference grows more and more successful Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

Mid 90’s to Present MDO is still implemented in later stages of design Not at Conceptual Design Stage -- New Conceptual Design optimization method emerged (s-Pareto based Conceptual Design – Mattson-Messac) Optimization is still often used using the defective weighted sum paradigm - Computer cost and speed are dramatically reduced - MDO grows within government AND industry MDO begins to address non-traditional disciplines Cost, Management, Manufacturability, Profit, Safety, Risk, etc. - MDO becomes more appropriately treated as Multiobjective - MA&O Conference continues to prosper: Atlanta; Sept Near Saratoga Springs NY Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

Multidisciplinary Design Optimization (MDO)
Performance Conventional Feasible Trades Design Space Suboptimal Design MDO Search Discipline 2 Multidisciplinary Optimum Aero Loads Optimal Design CFD Structures Deformations Aero Loads Str. Weight Discipline 1 Mach Number Optimum TOGW Design space discipline 1 Performance Design space discipline 2 Design Variables Effective Integration of Individual Disciplines/Subsystems to Capture the Interactions Novel Solution Procedures to Enable Improved System Solutions: - Account for Interdisciplinary Couplings & Integrated Product Team (IPT) settings. MDO = { Design Optimization, Design Exploration, Cross-Attribute Optimization, InterDisciplinary Optimization, System Synthesis }

Ford-SGI - Vehicle System MDO Project
HPC/MDO for NVH & Safety on the Origin 3800 Minimize: Vehicle Weight Subject to: NVH design targets Frequency Bending Displacement Torsion Displacement Frontal crash design targets Dummy HIC Dummy Chest G Probability of severe injury Roof crush design targets Maximum resistant force 50% Frontal Offset crash design targets Intrusion Side Impact design targets Displacements Viscous Criterion NVH Everything influences everything else! Frontal Crash Roof Crush Safety Side Impact Offset Crash

In Vehicle Everything Couples to Structure
Controls Aerodynamics Electrical system Fuel system AIRFRAME STRUCTURE Hydraulics Avionics In vehicle design, structure is a core that everything else, susbsystems, disciploines are hanging on. It is also involved in all the phenomena. Structural analysis is mostly linear, and has developed well and early enough - hence the structural optimization was there first and became a root from which sprang MDO. 82 Structural optimization is at MDO roots Propulsion Landing gear

Car Body Optimization for Noise, Vibration, Harshness, and Crash
Vehicle Roof Crush is a federally mandated requirement to enhance passenger safety during a rollover event. • NVH must be constrained for passengers comfort Courtesy: Ford Motor Co./R-J. Yang Modified NVH Model with a Square Ram to Perform Roof Crush as specified by regulations Finite Element Model of 390,000+ dof, boundary conditions; 20 design variables • Optimization executed using Response Surface approximations to crash analysis and sensitivity-based approximations to NVH • Implemented on a computer with 256 processors • Single processor computer would need 257 days to do this optimization • It was condensed to 1 day on the multiprocessor machine. // computing + RS enables what was impractical before.

Air Borne Laser System Design
12 Air Borne Laser System Design System Level Design Boeing CDR April Beam Control System Turret Assembly Large Optics Four Axis gimbals Transfer optics Beam Transfer Assembly Sensor Suite Active Mirrors Illuminators Electronics Software/Processors 747F Aircraft - Boeing CDR 29 Feb - 3 Mar Chemical Oxygen Iodine Laser (COIL) TRW 21-23 March BMC4I Boeing 8-10 March

Supersonic Business Jet Test Case
Application to a supersonic business jet - conceptual design level to capture the trades between aero-struct-propuls. 7

Examples of applications that will need all that
Configuration “A” Configuration “B” MDO necessary to protect very small payload margin Massively computational problem Candidate MDO method : design data bases for subsystems and disciplines precomputed off-line using multiprocessor computing This approach is now a candidate for our new application at LaRC: design studies of launch vehicles to replace the space shuttle. Courtesy: NASA LRC/Troutman

Obtaining an effective objective function is difficult in practice.
Prevailing Practice Obtaining an effective objective function is difficult in practice. Weighted-Sum (WS) method for optimization has its inherent significant drawbacks. It is incapable of capturing a large class of potentially desirable Pareto solutions. It is also the most popular! Compromise Programming (CP) method can be used to generate a complete set of efficient solutions, but its reliance on meaningless weights is a serious problem. Pareto ... Etc. The Weighted-Sum approach to forming the objective function holds the dubious distinctions of being the easiest to apply, the most popular, and among the most deficient. Importantly, the ways in which the Weighted-Sum methods is deficient do not represent special or rare cases (See several publications herein referenced). The ease of use of this method is largely responsible for its pervasive adoption. Unfortunately, these deficiencies have significant practical consequences. (i) For nonlinear problems with more than three to four design metrics, it is difficult to identify correct weights. (ii) For problems with a non-convex Pareto frontier, this method fails to yield a potentially large fraction of the desirable solutions. (iii) The pervasive resulting failures do not show the endeavor of optimization in a good light, particular to the novice in the art. Substantively similar comments can be made regarding several popular methods.

Optimal Solution Using Weighted-Sum
Obj. Fun. Line

Pareto Solutions Using Weighted-Sum

Weighted-Sum in Non-Convex Pareto Frontiers
Obj. Fun. Line

Weighted Compromise Programming for Non-Convex Pareto Frontiers
Obj. Fun. Line

Physical Programming (cont.)
Quantify Preference for Each Design Metric Ex: Mass of Beam Highly Desirable < 250 (kg) Desirable Tolerable Undesirable Highly Undesirable Unacceptable > 350 In a friendly human optimization infrastructure, the designer should have the ability to express his/her preference relative to each generic design metric in physically meaningful terms. All the information available to the designer regarding the artifact of process being designed should be exploitable. The information stated above is generally available to a designer as his/her first vague statement of preferences regarding the artifact being designed. No knowledge of optimization is needed to state the above. If, instead, the designer has to specify physically meaningless weights as a way to express preference, a good bit of luck, patience, and understanding of optimization become useful.

Expressing Designer Preference During the Optimization Process

Behavior of the PP Class Function for Change in Preferences

Numerical Example 1 (of 2)
Minimize Behaviors of different objective functions for a convex frontier Subject to Results WS CP PP

Example 2 Behaviors of different objective functions for a concave frontier Results WS CP PP

The Reality of Uncertainty and Risk
1- Non-Deterministic Forum -- SDM 2- Traditional Factor-of-Safety approach is rapidly becoming an anachronistic relic of the past 3- Development of probabilistic design optimization methods 4- New MDO methods emerge to model risk and uncertainty 5- Profit as a design metric gains acceptance 6- Growing recognition that optimization in Conceptual Design is a necessity 7- TC has moves to Engineering & Technology Management Group to explore expanded collaboration Five underlying questions will be addressed at the conference. 1) What is the state-of-the-art reflected in the optimization / information science literature with respect to using your work (or optimization) in industry? 2) What are road-blocks / hurdles in implementing your work (or optimization) in industry? 3) What research needs to be undertaken that will promote the use of your work (or optimization) in industry? 4) What are the elements of a design theory necessary to support distributed design with High-Speed Computing at its core? 5) What new developments in analysis and optimization methods are needed to exploit full potential of the new hardware/software architectures for High Speed Computing that offer massively parallel processing in a heterogeneous, distributed computing environment?

A Challenge? INJECTING MDO INTO INDUSTRIAL PRACTICE:
12’44” Remember The End is next • Not Primarily a Technical Problem Critical Issues are: EDUCATION, MANAGEMENT, AND ORGANIZATION “CULTURE”

Concluding Remarks The picture is somewhat muddied! Much of good news; yet much to be desired. MDO’s power is evident. Yet its strongest influence can be felt in this decade if -- its application in a holistic setting comes to pass, and -- key methodological developments take place in collaboration with non-traditional participants MDO is a unifying indispensable glue, if we are to effectively design the ultra-safe, profitable, and effective design of the future For more information:

Integrating Risk Management AIAA Management Technical Committee
Topic 7 Integrating Risk Management The Integrated Management Framework (IMF) Systems Engineering Applied to Program Management Richard Raiford, Chair AIAA Management Technical Committee

Integrating Risk Management Integrated Management Framework (IMF) Agenda
What is IMF? Where Is IMF Applicable? What does IMF Look Like When Implemented? How Do I Implement IMF on An Existing Program?

Integrated Management Framework (IMF)
IMF Is a Scalable Program Infrastructure That Uses System Engineering Principles To Implement an Executable Program Proactive Boundary Spanning Integrated Processes Controlled Baselines

The System - An Executable Program
Apply SE Techniques to Everything Relevant to an Executable Program Geo-Political Customer’s Program Political Enterprise Executable Program Operational Capability Assessments Operating Environment Operational System(s) Suppliers Product Elements Project Elements

Some Fundamental Concepts of IMF
The System is the Executable Program Proactive Boundary Spanning (a.k.a. Integration) Boundaries Are a Fact of Life (Organization, Product, Program) IPTs Don’t Eliminate Boundaries, They Just Re-Arrange Them Top-Down: Event-Based Management Manage Progress Toward Key Program Events Bottom-Up: Requirements-Based Task Accountability Know And Track Requirements “Pull” to Continually Identify the Risks Somewhere, Someone Knows We Are at Risk of Not Meeting A Req’t Control Program Baselines Everyone On the Same Page, Marching in Unison to the Same Objective

IMF – Defined RAA Roles of the Program Mgr
**From the AF Critical Process Assessment Tool (CPATS) for PM Responsibilities of the Program Manager** The 4 Roles Shown May Be In One Person, or Divided Depending on the Type, Phase, and Complexity of the Program. In any case, the PM Has Ultimate RAA for All Roles. 4 Roles of the Program Manager IPTs Consisting of: Business Mgmt Planning Contract Mgmt Subcontract Mgmt Materiel Manufacturing Engineering Logistics Systems Engineering Security Keep the Program Sold Requirements & Functional Analysis and Allocation Synthesis System Analysis and Control Verification (Program Manager)* Manage the Program Integrate the Program Architect the System (Deputy PM)* (SEIT, PIT, SEMT)* (System Architect)* Requirements Mgmt Baseline Mgmt Performance Mgmt Risk Mgmt Analysis and Integration (Boundary Spanning) Planning Integrate Processes and Systems *A Large Program Would Subdivide the Roles 110402

Hierarchy of Program Styles - From Reactive to Proactive
Characteristics Opportunity Management Ongoing, Integrated Assessments of Evolving Program & Environment; Entire Organization Understands Current and Potential Customer Needs; Integrated Strategies Take Advantage of Opportunities 5 Risk Management Ongoing Integrated Assessments of Likelihood of Meeting Objectives in Light of Current Status and Projected Environment Plans Updated as Required; Streamlined by “Checkbook” 4 Performance Management Performance Management Mgmt Has Visibility of Status of Program Performance to Current Plan Issues Related to Predicted Failure to Meet Plan Milestones Surprises as Evolving Environment Overtakes Current Plans 3 Issue Management Mgmt Has Inconsistent Visibility of Performance; Fluid Rating Criteria Teams Resist Quantitative Metrics; No Controlled Perf. Baseline Frequent Problems Due to Failure to Meet Plan Milestones 2 Crisis Management Program AND Enterprise Mgmt Frequently Involved in Cost, Schedule, and/or Performance Problems that Threaten Viability of the Program; Chaos, Frustration, “Finger Pointing” 1

Program Styles Are Based On How We Manage

IMF – Four Program Baselines Structure the Program By Structuring the Information
The Reason for the Program’s Existence; The Product Baseline Evolves from “Back of the Envelope” to “10,000 Parts flying at 50,000 Feet” How Performance to Plan Will Be Measured (Metrics, Thresholds, Formats, Reporting Frequency, Etc.) Project Baseline Product Baseline Performance Baseline Enterprise Baseline The Framework for the Program (Contract, SOW, Schedule, Etc.) What the Company Brings to the Effort (HR, Financial Systems, People, Skills, Processes, Systems, Etc.)

Program Integration with IMF
Defined RAA for Everyone Program is a System of Systems Proactive Boundary Spanning 1 Who Integrated Plans & Processes Req’ts Baselines (CM) Performance Risk Integration How What IMF 3 2 Managed Information Product Baseline Performance Baseline Project Baseline Enterprise Baseline

IMF - Four Program Baselines Example Contents
Rate of Change Enterprise = 0 Project = 0/Low Product = Very High The Baselines Evolve! - Defined Ownership - No Data Redundancy Contract WBS Deliverables Integrated Mgmt Plan & Schedule (IMP / IMS) Program Mgmt Plan (PMP) Tailored Processes & Procedures Earned Value Mgmt System SOW Risk Mgmt Plan Stakeholder Mgmt: Communication, Conflict, Etc., Plans  Tech Orders Tech Orders Project Baseline Product Enterprise Product Baseline Requirements Requirements Test Procedures Test Procedures Specs Specs Tool Design Tool Design Analytical Models Analytical Models Shop & Assy Planning Shop & Assy Planning Design Design Risk db Risk db Bill of Materials Bill of Materials Materiel, Suppliers, MRP Systems Human Resource Systems & Databases Facilities Policies, Common Processes Financial/ Accounting Systems Functions & CoEs Analytical Tools IT Systems Data Mgmt Tools & Systems Labs, M&S

IMF – Five Core Processes
Manage Requirements Project: Contract, SOW, IMP/IMS, Financials, Suppliers, etc. Product Life Cycle: (Classical “Systems Engineering”) Manage Baselines Enterprise, Project, Product, and Performance Baselines Identify, Lock Location, Control Configuration, Audit Compliance Manage Performance to Plan Status (Metrics), Risk, Decision Mgmt, Corrective Action Drill-Down Integrated with Req’ts, Baseline, and Risk Mgmt Systems Manage Risk and Opportunity Focus on Risk to Meeting Requirements Multi-Level From Tasks to Major Program Events Integrate the Program Proactive Boundary Spanning Processes, Customer Expectations, Planning, Communication, Information, Systems and Processes, Functions, Technical, Training, and Closeout

Where is IMF Applicable?

IMF and Program Type / Phase IMF Is Most Powerful When Product Baseline is Evolving
Concept Chart The ‘Area’ of the Program Type / Phase Implies the Degree to Which IMF Will ‘Help’ the Effort Technology Upgrade & Insertion Technology Development & Risk Reduction Operational Needs & Requirements Analysis System Concept Selection, Down Select Concept Development / Technology Demonstration System Development & Demonstration Production & Deployment Sustainment & Disposal 1 2 3 4 5 6 7

Questionnaires Guide Tailoring IMF to Program
Type & Phase Complexity Infrastructure Maturity Technology # of People Program Program Described (Road Map, Funding, SOW, Etc) Key Personnel In Place / Trained Qualified System Architect Defined Enterprise Baseline Team Members Co-Located Identification Development # of Skill Sets Insertion Project Req’ts Comprehensive Scope Mgmt System WBS, IMP, IMS Schedules Integrated Vertically & Horizontally & Config. Controlled Length of Program System Other Bus Areas / Sectors on Team Operational Needs & Req’ts Analysis Suppliers on Team Product Req’ts Integrated, Traceable System: Req’ts Analysis, Functional Analysis /Allocation, Trades, Decisions, V&V Concept Selection, Down Select Done Similar Tasks Before Baseline Mgmt Program & Project Info Structured, Configuration Controlled, Audited, Available When Needed Concept Development / Demonstration Worked with Same Team Before Funding Source Internal or External System Development & Demonstration Performance Mgmt Baselines with Rating Criteria Structured Decision Making Corrective Action System Cost Sustainment & Disposal Risk Mgmt Event Based, Look-Ahead System Priority Integration Proactive, Customer Mgmt, Planning, Communication, Information, Systems & Processes Worked with Same Customer Before Production & Deployment

What does IMF Look Like When Implemented? Examples of Some Key Elements of a Program Under IMF

IMF Implementation Matrix
Manage Requirements (What are We Supposed to Do?) Manage Baselines (BLs) (Config. Mgmt) (Write It Down) Evaluate Performance (How are We Doing?) Program Integration (Integrated Program Mgmt Plan) IPT Handbook Or Communication Plan Schedule Tree PIT Assessment Cycle Program Control Board Risk / Opportunity Board Process / System Board Weekly Program Reviews System Integration (System Integration Plan) Analysis/Model ICPs SEIT Cycle Config Control Boards Eng Review Board Design Reviews Element Integration Drawing Tree Interface Control Plans SEIT Meetings BL Mgmt Plan/Proc Des, Build, Supt. Plans JPCB, PCB Process Control Board Four Program Baselines Config Mgmt Plan CCB, SRB, ERB Interface Control Working Group Product Baselines Designs, Anal & Test Plans & Reports Components / Parts, Subsys, SW Interfaces, ICDs Risk Mgmt Plan/Proc Risk / Opp. Mgmt Board Look-Ahead, 90 day & IMP Risk/Opportunity DB Issue/Action DB Technical Risk Mitigation Plans Risk ID Matrices Simulations Waterfall Charts Make / Buy Decisions Part Shortage Mgmt Process Steps Identify Analyze Plan Track Control Identify Customer Req’ts Develop System Req’ts Develop Product Req’ts Analyze & Validate Req’ts Define (Technical) Solution Verify and Validate Product Plan & Identify BLs Publish Manage Change Track Status Audit Integrity Core Process Req’ts Mgmt Plan/Proc Quality & Security Plans Decision Mgmt Process Supplier Mgmt Plan/Proc Process Quality Audits Contract > SOW > Sched > Resources > Budget ORD; MND System Specs (Tree) Specialty Integration Plan Req’ts Anal / Func Anal Integrated Test Plans “VCRI” Slate EDRM Element / Subsystem Specs Standard Parts Process Specs Material Specs Component Acceptance Criteria Baseline Collect Data Integrate Evaluate Report Performance Mgmt Plan CPAR Mgmt Process Wkly Program Review EVMS, Sched Tracking, Issues Traffic TPM Plan(s) & Process Config. Change Traffic Technical Performance Measurands Shortages, Rejects, MRB IPD: Sched Commitment Tracking: Part: Design, Buy, Install, etc. IMF Implementation Matrix Plans, Processes, Documents Meetings, Boards, (Team Interaction) Inputs, Outputs, Tools, etc. Key: Manage Risk / Opportunity (Will we Do It? & Can We Do it Better?) Plans, Documents, Mtgs, Boards, Tools, & Work Products (Examples

Result of Sample Plan for Implementing IMF Situation at End of Month Three
IPMP and IPT Handbook Published Availability of Key Personnel Controlled Regular Meetings Controlled: Agendas, Attendance, Minutes Baseline Documents Indexed and Configuration Controlled IMP In Place Schedule Tree In Place & Schedules Vertically Integrated Horizontal Integration Is In Work Integrating Charters (RAA) In Place Req’ts Mgmt System – Front End Implemented Contract Parsed, Specs Depend on Maturity of Original System Event Based Performance Mgmt Implemented (Still Subjective) Decision Mgmt System – Front End Implemented Program Control Board In Place Corrective Action Board Meeting Monthly Risk Mgmt System Initiated (Depends on Maturity of Original System)

Program Information Systems - Example
Portal Program Mgmt Info System Interface Product Data Mgmt System Interface Design Data C/PIOS Buy, Fab, Build Data Sup-port Req’ts Mgmt System Test Sys Configuration (& Change) Control System Links PMIS Index & Repository Interfaces to Other Systems Project Mgmt Info System Interface Risk Mgmt Information System Interface Project Mgmt Repository / Index Risk Tracking System (eRisk) Risk Decision System Risk Mgmt Reporting System EVMS Staffing Risk Decision Indexing System Schedules Budget Capital Etc Risk Mgmt Reports Repository Risk Analysis / Decision Data Repository Risk Database Req’ts Mgmt Info System Interface Req’ts Mgmt System (SLATE) Design Decision Index System Performance Mgmt Info System Interface Performance Mgmt System Decision Mgmt System Design Decision Data Repository (Trades, Mtgs, Decision Memos, Etc.) Req’ts Reports Repository Project Performance Baselines Tech. Performance Baselines Corrective Action System Design Support Data Repository (Specs, Analysis, Test Req’ts & Reports) Corrective Action Repository Performance Rpts Repository

IMF - Performance Management Model, Procedures, Guides, & Checklists
Program Management and Control Plan Performance Management Plan Define Performance and Reporting Req’ts Procedure Performance Management Checklist Performance Visibility & Database Mgmt System Flowdown of Performance Mgmt Req’ts to Suppliers Metrics Selection Technical Performance Measurement (TPM) Procedure Quantitative Mgmt Measurement Work Instruction Performance System and Metrics Audits Work Inst Performance Analysis Org/Team Level Program Task Metric Task & Resp person Timeline | | | | | | S R # of Events Plan Actual to Plan OR Resp Org - - - Product / Event Resp Sub Org Event / Accom

How Do I Build an IMF on an Existing Program? Create the IPMP, IPT Handbook, and Supporting Docs from Templates That Include Tutorials and Example Formats

IMF Tailored & Implemented By Two Documents
Integrated Program Management Plan (IPMP) Implements/Tailors IMF for the Program Objectives, Schedules, Priorities Mgmt Approaches for Every Area Policy, Procedures, and Authorities Replaces Multiple Independent Plans IPT Handbook Foundation for Program Integration Tells Program Personnel How the Program Will Operate Charters and RAAs Communication & Issue Resolution Meetings – Who, What, When, Where

Interactive Templates Government Regulations
Use Templates to Generate Integrated Program Mgmt Plan and Supporting Procedures Requirements Interactive Templates Contract Plans Procedures Government Regulations Integrated Program Mgmt Plan IPT Handbook Corporate, Sector Shared Services, and Business Area / Homeroom Processes, Policies, and Guides Introduction, Scope, Purpose Executive Summary Program Overview Organization Administration Management Systems Project Req’ts Mgmt System Life Cycle Mgmt Baseline Management Performance Mgmt Risk / Opportunity Mgmt Program Integration Tailored Procedure Templates Business Mgmt Integrates (Combines) Program Management Plan System Engineering Mgmt Plan Risk Management Plan Configuration Management Plan Performance Management Plan Materiel HR EL&T LOQA

Cycle Weekly Program Reviews
Strategic Rhythm / Horizontal Integration Week 1 Week 2 Week 3 Week 4 Process Product Cost & Schedule Risk / Opp. Shortages Staffing Rework Audits Req’ts Volatility Team Reports Accomplishments Customer Satisfaction TPMs Changes EVMS Data & Indicators By Program & by Team Performance to IMP/IMS Top Issues & Risk and Associated Closure/ Mitigation Plans Corrective Action Special Topics / Action Items / Calendar Customer Satisfaction / Top Program Issues and Risks

Integrated Management Framework (IMF) Summary
IMF Is a Scalable Program Infrastructure That Uses System Engineering Principles To Implement an Executable Program Features Proactive Boundary Spanning Four Baseline Categories Five Integrated Core Processes Implemented by Interactive Creation of Integrated Program Management Plan IPT Handbook Integrating Risk Management is Critical for Success

Panel Discussion All Speakers
Topic 8 Panel Discussion All Speakers

Designing and Integrating 21st Century Systems
Next Year Join Us Next Year for The Delta Forum 2004 Designing and Integrating 21st Century Systems Thank You for joining us!

Tracking the Constant of Change

Similar presentations

Presentation on theme: "Tracking the Constant of Change"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Tracking the Constant of Change

Similar presentations

Presentation on theme: "Tracking the Constant of Change"— Presentation transcript:

Similar presentations

About project

Feedback