Why formalize root cause analysis?
There are many approaches to determining the root of our problems. In the automotive world, there are two typical approaches, the 8D or the 8 Discipline, or the A3 (named for the paper size). We will not go into the details of either of these approaches but you can find the templates for these by clicking the links above.
There are some benefits to a formalized root cause analysis. We can think of 6 reasons as listed below:
Controls jumping to conclusions and just working on the symptom Repeatable Coordinates effort / focus Documents actions so we know what have tried and what is next Traceable for future events
Controls jumping to conclusions and just working on the symptom
A formalized approach to root cause analysis in such a way that will keep us from jumping to conclusions about the nature of the failure. Those that have read this blog for … Continue reading
There have been some twitter discussions going on about the validity of the term end-to-end (E2E) testing. I have been around this concept for many years and still see the validity in the term and the approach. To that end, I will describe as quick and briefly as I can since this is a blog post and not a book.
The various devices being developed (Device Under Test)
Vehicles are comprised of a myriad of subsystems. In this case we are going to look at the vehicle electrical / electronic architecture that consists of embedded electronic control units (ECU). These are component such as:
Instrument cluster Engine ECU Transmission ECU Antilocking Brakes System (ECU) Door control modules Telemetry systems
Each of these consists of many analog and digital inputs and outputs, along with data link communications. Each have specific expectations under certain conditions and the developers will work to deliver these algorithms and software that will ensure the system works … Continue reading
by: Shawn P. Quigley & Jon M Quigley
Measurements and Bias
Solely by the process of observing something we can alter the thing which is being observed. This is a known as the observer-expectancy effect. This effect is born out of conscience and subconscious biases of the observer. In the case of observing people, we have noted in earlier blog posts that the act of observation, taking an interest, may alter the outcome or performance as well (consider The Hawthorne study). To make an effective measurement we must work to account for these impacts. We also must know the goal we have set for collecting the information, that is the measurement is context based. Having a specific goal, informs the type of data and methods of data collection. Both of these are rife with opportunity for bias to creep into the measurements, and delude our team. This bias can creep in not only, what we identify … Continue reading
Many of you who have read our blog know we are fans of the show Aircraft Disaster on the Smithsonian Channel. We do not like the show for the disaster part, but the root-cause analysis aspects. These things are intriguing for engineers. Root cause analysis is an important skill for design engineers, process engineers, and even project management people. The latest one I have watched was about Northwest 85, in which the plane suffered a hard over lower rudder in a Boeing aircraft. On the television show, the root cause was never really determined, though a design modification eliminated the possibility of that incarnation of the failure from coming to pass was introduced. This is not really something we can really take away from this show and apply to our work lives. However, there was a compelling argument made on the show was that cockpit resource management helped ensure the safe handling and landing of the aircraft.
All along … Continue reading
I have a mental exercise for you project management type people out there. In this exercise, we are going to explore the possible interactions and results of the various knowledge management areas as defined by the Project Management Institute or PMI. In this exercise, we will start with an Ishikawa or fishbone diagram. In this exercise, we will label the diagram differently than the typical 5 or 6 M approach. For this exercise, we will label the diagram with the 10 knowledge management areas:
Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Procurement Management Stakeholder Management
Now, visualize a project management failure, and put it at the head of the Ishikawa diagram as the symptom for which you want to uncover the reasons, for example, late delivery to the schedule as the symptom. Now see how many of items you can generate, at least … Continue reading
Imagine you are an executive and you are sitting down to your early morning breakfast with the daily paper. As you read the paper, you find an article about your company and you are stunned to find it is not a flattering article but a description of a traumatic event that has come to a customer using your product. You are shocked and embarrassed and it is not even 0600 yet.
When you get back to the office, you find out this situation was known by the line management and workers of the company. They have been wrestling with whether the problem is, in fact, a problem and the magnitude of the problem if it is a legitimate event. The line personnel wants to determine if it is a problem how to correct rather than make this situation aware and bring the entire company’s resources to bear on the problem. I have seen this situation a number of … Continue reading
Risk and Time Management
In keeping with our last post, we discuss risks due to insufficient time management that often result in project failures. As is with many things, the symptom of the failure has roots much earlier. In other words, when we witness the failure, it was due to some event(s) or activities much earlier.
Risk and Time Management Taxonomy
We provide a brief list of some of the miss-steps we make along the way that will influence our probability of success.
formal time reporting organizations time reporting processing overly optimistic task scheduling no accounting for task variance (point source task duration estimates) missing tasks and task dependencies poorly identified and quantified metrics for monitoring poor data collecting for metrics insufficient or lack of monitoring of metrics little or no follow up on the schedule lack of proactive actions taken when the schedule appears to be slipping poorly defined activities including what constitutes success for activity missing … Continue reading
Qualitative tests look for a change in a quality; for example, a color might change. Qualitative tests always involve the use of attributes rather than variables values (e.g., temperature). Consider the Kastle-Meyer test for the presence of blood–an archetype for qualitative forensic testing. The test is impressively quick and functions as a decision support tool by letting us know whether we move on to the much more involved, time-consuming, and expensive testing in a full-featured laboratory. What we see here is exactly what we want out of a good qualitative test!
Applied to Root Cause Analysis
This testing approach can help us understand probable areas of concern for additional investigation. Consider a poly-carbonate part that fails in a particular real world application. A review of failed parts shows cracking or surface crazing. In the field, the part develops fractures along mounting locations. It might be obvious to assume that the over torque of the screws may … Continue reading
The project whose scope includes delivery through manufacturing will include some quality assurance steps from the previous blog post to ensure we are able to produce the designed product to the quality expected by the sponsor.
Trial Production Run and Problem Discovery
The manufacturing team reviews the development of the manufacturing line with the TPR or Trial Production Run. The TPRs happen before the run at rate or PPAP reviews, and is a mechanism for preparing the line for these two events. The team uses these trial runs to identify problems in the production line undiscovered during design. The team gathers data from the exercising of the line to adjust the line.
Trial Production Run
During the TPR, there are reviews of the tools and equipment created for the line and those that are still in progress. The review will also include the work instructions for the line. The quality assurance engineer leads these reviews, but inclusion … Continue reading
In our last blog post, we referred to the APQP (Advanced Product Quality Planning) activity of DFMEA. The post was about the attempt to perform late in a project. The point to the DFMEA in that instance was lost; at best, if we found a serious problem, would be to abort the launch. The post was mostly about asking the stakeholder for more money and time when that effort would largely be wasted.
More Quality Activities
The DFMEA is not the only activity prescribed by APQP for the design and development effort. That was but one example of the actions we take to secure the product quality. The entire list of quality assurance actions may look more like:
Design Failure Mode Effects Analysis Design for Manufacturability and Assembly Design Verification Other design reviews such as code reviews Prototype parts (iterations and control plan) Engineering and Material Specifications Demonstrated change control and control over engineering drawings Design Verification … Continue reading