iTest Quality Partners: Maximizing stratic value.
Thursday, 09 April 2020 Jump into the neural pool. The water's fine.
HomeCustomer Q & ASelected Engagement SummariesiTQP PrincipalsDownloadsContact Us
iTQP Services: Strategy
iTQP Services: Process
iTQP Services: Training and Seminars
How We Add Value
iTQP How We Add Value: Cost of Quality
iTQP How We Add Value: Glue—Value-Driven Risk-Adjusted Solution Delivery
iTQP How We Add Value: Requirements Based Validation
iTQP How We Add Value: Enterprise Architecture
iTQP How We Add Value: Project Progress Reporting
iTQP How We Add Value: Quality Metrics and Sizing
iTQP How We Add Value: Important Strategic Thinking Ideas
iTQP How We Add Value: Transformational Changes
iTQP How We Add Value: Business Processes and Continuous Improvement
iTQP Webinar: See our new Webinar: Drive High Impact Business Results By Improving Technology Quality
See our new Webinar: Drive High Impact Business Results By Improving Technology Quality.
Watch ...
iTQP Tools: Doormat
DOORMAT: A Framework for Requirements Maintenance.
Read more ...
iTQP Tools: ValidationBench
The key to the power of many of iTQP’s software quality and validation offerings can be directly traced to our overall project delivery philosophy. Read more ...
iTQP Tools: AFTA
The Automated Fault Tree Analysis (AFTA) facility, originally developed to support missile failure analysis for the defense industry, assists project teams in identifying, organizing, managing, analyzing, and validating the root cause(s) of any type of system failure. Read more ...
iTQP Tools: PRAC
The Project Risk Assessment Calculator (PRAC) is a self-assessment tool designed to help project managers, IT leaders, and their business customers understand the various risks their project is facing and to offer suggestions on mitigating those risks. Read more ...
iTQP Books: Technology, Strategy, and Leadership
A set of convergent forces is challenging fundamental assumptions about the role of organizations and how they deliver value to their customers.
Read more ...
Request copy of book ...
White Papers
iTQP White Papers: Maximizing Strategic Value
Ideas matter, but an organization aligned for execution is what delievers the value.
Read more ...
iTQP White Papers: Project Management
Project management bridges the gap between strategy and tactics. It’s the difference between having a good idea, and actually being able to execute on that idea.
Read more ...
iTQP White Papers: Value Driven Performance Ethic
In our experience high-performance organizations tend to share a set of recurring management and leadership characteristics. While each organization may actually choose slightly different tools or implementation approaches, successful companies nevertheless tend to operate in very similar ways. Read more ...
Automated Fault Tree Analysis (AFTA)
Download the Automated Fault Tree Analysis (AFTA) tool.
The Automated Fault Tree Analysis (AFTA) facility, originally developed to support missile failure analysis for the defense industry, assists project teams in identifying, organizing, managing, analyzing, and validating the root cause(s) of any type of system failure.
A system failure is any discrepancy between the system in actual operation (whether test or live use) and its expected results.
Moreover, the AFTA facility also permits the examination of potential patterns that may exist in root causes across systems and their failures.
AFTA consists of a database, a set of forms for operating on this database, and a set of reports that provide analytical windows into the content of that database.
There is one AFTA database for each system failure. The name of the AFTA database identifies the particular system failure under investigation.
The observation database is the primary analytical repository within the AFTA facility. It consists of a collection of individual observation records. All the relevant information about the system failure is contained in this collection.
Each observation record in the database defines a specific fact or conclusion related to the system failure that the project team deems important to the investigation. These facts—individual observation records—are entered, defined, enhanced, clarified, elaborated, and refined throughout the investigation by the project team.
There are three classes of information contained in each observation record:
  • Descriptive, the primary information and analytical content related to this observation instance
  • Direct Causes, the set of observations that the project team believes are direct causes of this observation; an observation with no direct causes is called a root cause observation
  • Project Management, the information regarding an observation’s analytical progress and completion status
In addition, certain observations can be classified as failure observations. A failure observation is that observation that the project team believes is the most macro or coarse manifestation of the system failure. A project team will typically identify several failure observations during a given system failure investigation.
Each failure observation becomes the head (or top) of a specific fault tree. A fault tree is simply a hierarchical arrangement of individual observation records in which the fault tree hierarchy itself defines the cause-effect relationships among those observation records in the tree.
From a project management view point there are two pieces of information within an observation record that are considered vital to the successful analytical progress of the investigation:
  • Classification, the relative likelihood that the given observation is, in fact, a direct cause of the observation(s) it is linked to in the fault tree; there are four possible values each implying an increasing likelihood: None (this is the default value and indicates that the project team has not yet assigned a classification to this observation), Not Probable, Possible, Likely
  • Status, an indication of the confidence that the project team has regarding this classification; there are four possible values each implying increasing confidence: None (the default value), Open, Pending Review, Pending Closure, and Closed
The goal of the system failure investigation is for the project team to sufficiently understand the meaning and context of these observations so that the actual underlying root cause(s) of the system failure are revealed, and thus can be corrected and the corresponding relevant requirements, design, engineering, construction, and deployment processes improved so that these failures never recur.
This goal is accomplished by carrying out the following activities:
  • Identifying and defining all the observations necessary to fully understand the system failure and thus its potential root cause(s)
  • Identifying those particular observations that are considered to be failure observations
  • Arranging the other observations in the database so that they are contained in one or more fault trees, or are discarded as not being relevant to the system failure under investigation
  • Closing each observation in the database
As can be seen, the ability of the project team to fully populate the fault trees with the relevant observations that yield insights into its root causes is a vital element of any system failure investigation. Further, the success of this aspect of the project team’s work is largely a function of utilizing a data gathering and analysis process that is organized, rigorous, and complete. Ishikawa, who invented these fault tree diagrams (also known as Ishikawa or fishbone diagrams, see Guide to Quality Control, Kaoru Ishikawa, 1982, Quality Resources, White Plains, NY) suggested three different approaches for carrying out this important work. These three ideas are paraphrased below:
  • Variation source, this approach organizes observations by the five resource categories that define every process: People, method, material, equipment, and environment. The project team starts with a failure observation and asks: Why does this failure occur? The answers are arrayed under their appropriate resource category. For example, all the observations related to people (lack of training, improper skills, etc.) are placed under the people branch, all the observations related to the method or practices (out-of-date manual, too general procedures, etc.) are placed under the method branch, etc. The key to its effectiveness lies in continually asking the question: Why did this occur?
  • Process classification, this approach organizes observations by the relevant steps in the engineering, manufacturing, and support processes that were used to actually deliver the system under investigation.
  • Cause enumeration, this approach seeks to take an open and unrestricted view of the system failure and to ask the project team to free-associate on the possible causes without regard to their source or likelihood. In this approach, observations are noted and identified first in an attempt to get all the key thoughts and ideas captured, and then are organized into cause-effect sub-trees.
The key is to select an approach that is compatible with the skills, background, and working relationships of the project team. Note the AFTA categories table can be used to capture this information for each observation.
Back to top