Price: $4,999.00

Length: 4 Days
Print Friendly, PDF & Email

Systems Engineering Lessons Learned | A Case Study Course by Tonex

Systems Engineering Management Certificate | Master SE Certificate

Systems Engineering Lessons Learned is a TONEX Case Study Problem-based training course  that challenges participants to learn through engagement in real problems by analyzing and discussing the case studies and performing Failure Analysis Workshops.

TONEX course format using case study simultaneously develop both problem solving strategies and disciplinary knowledge bases and skills by placing participants in the active role of problem-solvers confronted with an ill-structured situation that simulates the kind of problems they are likely to face as future leaders, program/project managers and systems engineers in complex environments.

Engineers and Project Managers will learn by analyzing, investigating and discussing design successes and failures both internal and external to your organization. The case study course  will illustrate the methods to uncover the causes of engineering design failures either as technical flaws , human judgment, decision making and lack of understanding about certain fundamental issues in the analysis and design process. At the last day of the training, the participants will create a framework and methodology to practice in innovation and critical thinking. Using practical set of collaborative tools and methods for planning and defining successful new programs and projects. Strategists, managers, designers, and researchers who undertake the challenge of innovation, despite a lack of established procedures and a high risk of failure, will find this an invaluable resource.

The process is aimed at using the power of authentic problem solving to engage participants and enhance their learning and motivation:

  • Learning takes place within the contexts of authentic tasks, issues, and problems–that are aligned with real-world concerns.
  • Participants  and the instructor become colearners, coplanners, coproducers, and coevaluators as they design, implement, and continually refine the curricula.
  • Learning and on the best practices that promote it. This approach stimulates participants to take responsibility for their own learning, since there are few lectures, no structured sequence of assigned readings, and so on.
  • Our unique approach fosters collaboration among participants, stresses the development of problem solving skills within the context of professional practice, promotes effective reasoning and self-directed learning, and is aimed at increasing motivation for life-long learning
  • Participants will enhance their decision-making, critical thinking, problem-solving and systems thinking competencies and capabilities by reviewing and analyzing case studies.

Case Study Lessons Learned 

This proposal describes the development of a crash course focused on case studies that investigate engineering design successes and failures both internal and external to NASA.

TONEX’s case study course includes  industrially-derived case studies showing  success engineering, failures, failure analysis, and  forensic engineering focusing on:

  1. Design Failures
  2. Organizational and Planning Failures
  3. Leadership and Governance Failures
  4. Judgment Failures
  5. Underestimation and Analysis Failures
  6. Quality Failures
  7. Risk Failures
  8. Skills, Knowledge and Competency Failures
  9. Edgemont, Teamwork and Communications Failures
  10. Strategy Failures

The learning objectives include a number of applications of some techniques widely used in industrial success and failure analysis with examples are chosen and presented so as to guide the learner through the analytical steps and thought processes used in solving such problems.

  • Guidance on the interpretation of information
  • Multi-choice intermediate steps in the analysis
  • Opportunities for the learner to explore decision making choices, critical thinking, problem solving and system thinking.
  • Opportunities for the learner to explore other decisions in the analysis tree, and their possible consequences.
  • These particular examples have been chosen from real industrial work, undertaken over the last two decades or so, to illustrate successful and failed projects, unusual, interesting or potentially misleading aspects of failure and failure investigation.
  • The context of these aspects is related to the impact of engineering decisions on assessment of responsibility, realizing insufficient knowledge and underestimations corrective actions on design flaws or materials failures, system thinking and improvement ,communications and  collaboration and design/manufacturing modifications.

Learning through Case Studies – Presentation of Alternatives for Case Studies

Day 1, 2 and 3

NASA Engineering Design Successes  Case Studies (Choices need to be discussed and picked)

  1. Voyager
  2. Chandra
  3. Hubble Space Telescope
  4. James Webb Space Telescope Project

Engineering Design Failures both internal and external to NASA Case Studies (Choices need to be discussed and picked)

  1. Titanic (1912)
  2. Francis Dam flooding (1928)
  3. Hindenburg disaster (1937)
  4. Tacoma Narrows Bridge collapse (1940)
  5. Cleveland East Ohio Gas Explosion (1944)
  6. Hyatt Regency Hotel Walkway Collapse (1981)
  7. Space Shuttle Challenger disaster (1986)
  8. Chernobyl disaster (1986)
  9. Concorde Air France Flight 4590 crash (2000)
  10. Space Shuttle Columbia disaster (2003)
  11. Boeing 787 Dreamliner

Topics Discussed  and Enforced in the Case Studies

Primary Causes of Engineering Disasters

  • Background and visual observations
  • Summary and conclusions, recommendations
  • Further investigations, impact testing
  • Famous engineering disasters
  • Primary Causes of Engineering Disasters
  • Chronology of Events
  • Example of failure analysis reports
  • Examination of What failed
  • Why it failed
  • Possible corrective actions (How to make it not fail)
  • Who was at fault, and why
  • human factors (including both ‘ethical’ failure and accidents)
  • Design flaws (many of which are also the result of unethical practices)
  • Materials failures
  • Extreme conditions or environments, and, most commonly and importantly combinations of these reasons

Layers in Project Success

  • Product Success
  • Project Management Success
  • Project Execution on Schedule and Budget
  • Scope
  • Meet Quality Requirements
  • Satisfy Quality Expectations
  • Meet Safety Requirements
  • Meet Non-Functional Requirements
  • Meet Organizational Needs
  • Achieved Desired Outcomes
  • Engineering Ethics

Layers in Project Failures

  • Dysfunctional and Ineffective Decision Making
  • Misaligned Goals
  • Communications Problems
  • Corporate Culture
  • Lack of Situational Awareness
  • Cognitive Biases
  • Political issues
  • Lack of Trust or Openness

What Makes a Failure Into an “Engineering Disaster”?

  • Primary Causes of Engineering Disasters
  • The primary causes of engineering disasters are usually considered to be
  • human factors (including both ‘ethical’ failure and accidents)
  • design flaws (many of which are also the result of unethical practices)
  • materials failures
  • extreme conditions or environments, and, most commonly and importantly
  • combinations of these reasons
  • Insufficient knowledge
  • Underestimation of influence
  • Ignorance, carelessness, negligence
  • Forgetfulness, error
  • Relying upon others without sufficient control
  • Objectively unknown situation
  • Definition of responsibilities
  • Choice of bad quality

Drivers and Contributing Factors

  • Trigger Events
  • Individual Actions
  • Group Actions
  • Mistakes or events trigger or contribute to failure
  • Behavioral Problems
  • Broad Pattern of behavioral or structural issues

Symptoms of a Failed or Failing Project

  • Schedule Slippage
  • Quality Problems
  • Budget Overruns
  • Products don’t meet the needs
  • Requirements can’t be verified
  • ConOps is missing or not complete

The Common Characteristics of Design Failures

  • Understanding the problem
  • Critical thinking
  • making good decisions
  • Good design
  • Engineering failures
  • Faulty decisions and judgments
  • System interdependencies
  • Elements of iconic designs
  • Reasons for successful designs
  • Lessons Learned for Design of a New Product
  • Know what the customer wants and needs, not what they tell you
  • Reasonable calculated risk
  • Balance between verification, testing and analysis/design
  • Lessons Learned for Product Development on a Limited Schedule/ Budget
  • Avoid technology push projects
  • Emphasis on simple solutions
  • Superior interpersonal and teambuilding
  • Techniques for avoiding design failures

Techniques for Avoiding Design Failures

  • Understanding the problem
  • Elements of iconic designs
  • Lessons learned
  • Critical thinking
  • Making good decisions
  • Good design
  • Understanding system interdependencies
  • Reasons for successful designs
  • Know what the customer wants and needs
  • Evaluating and promising what customer says and wants
  • Reasonable calculated risk
  • Balance between verification, testing and analysis/design
  • Lessons learned for System/Product Development on a Limited Schedule/ Budget
  • Tools to avoid technology push projects
  • Simple solutions
  • Interpersonal and team building
  • Identify and explain the classical types of design errors and how to avoid them
  • Extract key decision-making aspects associated with the engineering process from case studies
  • Explain how to incorporate lessons learned into everyday design processes.

Day 4: Failure Analysis Workshop Topics

  1. Participants will pick an example of a management or engineering failures or disaster (multiple alternative projects as described below)
  2. Describe it in some detail, and discuss what issues might have been at least partly responsible for the failure

In other words, create a failure analysis report for this failure that includes:

  1. What failed
  2. Why it failed
  3. Possible corrective actions (How to make it not fail
  4. Who was at fault, and why

Describing the cases: Failure as a Design Criterion

  1. Structural Failures
  • Unforeseen Loads & Consequences
  1. Human System Interaction Failures
    • Flawed Decision Making
    • Flawed Safety culture
  2. Failure of Design Management
    • Visionary Management Style
    • Inaccurate Assessment of Market Needs
  1. A) Structural Failures: Unforeseen Loads & Consequences

A.1 Tacoma Narrows Bridge

  • Case Description
  • Technological Outcome
  • Design Failure
  • Lessons Learned

A.2 Comet Airlines

  • Case Description
  • Technological Outcome
  • Design Failure
  • Lessons Learned
  1. B) Analyzing Human System Interaction Failures: Flawed Decision Making

B.1 Challenger Space Shuttle

  • Causes
  • Engineering Factors
  • Management Decision Factors
  • Human Factors
  • Organizational, political and economic factors
  • Decision making failure
  • Lessons Learned
  • Design Failures
  • safety culture
  • operational goals
  • A flawed ‘group decision support system’.

B.2 Analyzing Human System Interaction  Failures: Flawed Safety Culture

  • Chernobyl Nuclear Power Station
  • Causes
  • Engineering Factors
  • Human Factors
  1. C) Failures of Design Management

C.1 Analyzing Failure of Design Management: Visionary Management Style

  • De Lorean Motor Company
  • Causes
  • Design Failure
  • Human Factors

C.2  Inaccurate Assessment of the Needs

  • Causes
  • Design Failure:
  • Technological problems and a perfectionist attention to detail

Request More Information

Please enter contact information followed by your questions, comments and/or request(s):
  • Please complete the following form and a Tonex Training Specialist will contact you as soon as is possible.

    * Indicates required fields

  • This field is for validation purposes and should be left unchanged.

Request More Information

  • Please complete the following form and a Tonex Training Specialist will contact you as soon as is possible.

    * Indicates required fields

  • This field is for validation purposes and should be left unchanged.