Archive for April, 2018

Why formalize root cause analysis?

Posted on: April 30th, 2018 by admin No Comments

8D Root Cause Analysis

8D Root Cause Analysis

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:

  1. Controls jumping to conclusions and just working on the symptom
  2. Repeatable
  3. Coordinates effort / focus
  4. Documents actions so we know what have tried and what is next
  5. Traceable for future events


A3 Root Cause Analysis Example

A3 Root Cause Analysis Example


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 any period of time, know that we are a big fan of aircraft disasters.  If you really want to understand what solving complex problems is really like, check out that show.  It is seldom that the first thing we think is the problem, is in fact the problem. There is also a significant chance that the root cause is not in fact a single thing, and very likely not the single thing we may immediately believe to be the problem often based upon our biases and experiences.


If we have done the work well enough, we have documentation that would make it possible to recreate our exploration in as much as it could possibly be replicated.  This gives us a sense of really understanding the nature of this problem.  If we are able to replicate the problem, we are theoretically better able to solve the problem, or more importantly, we are able to be able to see if we have solved the problem. The solution should prevent the problem from recurring.

Coordinates effort / focus

The diversity of perspective can help us uncover the nature of the problem and methods for us to  explore these beliefs.  With a team, we may get a multitude of ideas as to the root cause, and without some level of formalism, we may all charge off in many directions pursuing our own agenda or thoughts on the matter.  Our goal is to quickly understand and solve the problem.  With team members going off in many and unknown or uncoordinated directions, we are not efficiently making use of the organization’s resources, time and talent.  A formalized approach helps keep the team connected to each other and to the objective and ensures the opportunity for team learning.

Documents actions so we know what have tried and what is next

Without a formalized approach we would not know what things have been explored, what has been discovered, and what has been learned. We are able to build upon what has been tried and what has been learned. We can consider our next actions in the context of our past actions in the course of resolving this problem.

Traceable for future events

The formalized process, will have some measure of recording the actions that are under taken and the results of the exploration and the final solution.  This information can be fodder or future work. We can capture this information in a searchable database that will make recovery of these activities possible rather than accidental by other people in the organization. One such tool is


There are some times, maybe, when our approach to finding the root cause of the malady that we are facing is a single event and perhaps it is obvious or easy to determine.  However, based upon my experience, and looking at things like aircraft disasters, this situation is very very very rare.  It is far more likely that what you think it is, is not really the only reason for the problem.  Team work will benefit from coordination and keeping track of what has been tried, along with prioritization of what needs to be explored now.  Root cause requires more than one person, and coordination of effort, to that end, some measure of formalism is required.


Communication and distribution of work

Posted on: April 22nd, 2018 by admin No Comments

Communication and Project Team Distribution

There are times when our business does not have all the requisite talent within the walls of the organization. It is nearly impossible to be fully prepared for every opportunity available, and the business and time investment in expertise that is only transitory seldom passes muster. However, when we build this network of internal and external or numerous external sites, we must also consider the communications that will vary depending upon the scope of the project. Let’s consider a company is building the network that consist of three companies:

  1. The development
  2. Test and verification
  3. Our organization (UAT)

Immediately after the articulation of the project scope, we need to identify the players and areas of responsibility. Our communications planning should account for the distribution of the work, and so too our schedule. We must account for the transitions between the organizations, who needs what information and what constitute good quality of information as well as good product during these exchanges.

Communication and Coordination

These three entities need will need to communicate and our project communications plan must understand what each entity within this project will need for information. The development group will need input from the customer organization (the same organization doing the UAT). The test organization, will need information and material from the development organization. The UAT in this instance, is scheduled to happen after the test and verification. Let us consider that this schedule, has these in the sequence of 1>2>3, or Development, Test and UAT. Let us also consider that the schedule is set up as a single pass, that is, the sequence 1>2>3, will only go through one time. Those things found in testing, will need to go back to the developers, and after testing, the UAT testing will begin, and the results of that UAT must also go back to the developers. All that feedback to the developers must be coordinated and directed. This is anticipated to be a single pass through the process. That means those things found in testing and UAT will need to be quickly corrected and another iteration of the product delivered. What do we think the probability of a single pass working out well?

When you find yourself in a hole, the first thing you need to do is stop digging.


Posted on: April 2nd, 2018 by admin No Comments

Wire Harness

Wire Harness

Learning and Product Development

By now, we should all understand the need for speed when it comes to product development, but not just any speed, it is the need for speed of learning.  This is one of the benefits of an agile approach, but this benefit is not restricted to a development methodology, unless of course, the development methodology precludes or runs contrary to fast learning cycles.

You might think that this learning is only associated with complicated or complex systems, perhaps categories of projects that we have no familiarity. It is true that learning is especially required when we are working on things we have little or no experience.  However, in product development, we can ill afford to believe we know things that are simply not true or follow unvetted assumptions.  For example, we can model and simulate, but neither of these are true parts.  If we do this methodically, we can certainly reduce the need for some prototype parts, but that does not mean exclude them. This is especially true when we have many parts, interfaces and subsystems coming together.

Wire harness and Models

Consider for example, a collection of physical parts such as a wire harness for a vehicle.  This may seem like a simple product that consists of a variety of connectors, and wire lengths that are used to connect sensors, solenoids, and the myriad of electronic control units on the vehicle together.  It is in fact more of a subsystem for the vehicle.  Let us consider the lead time for prototype wire harnesses are 8 – 12 weeks.

The mechanical attributes of this product can be modeled in CAD to learn things about fitment.  Assuming the entire vehicle components are also modeled, then fitment issues can largely be relegated to the CAD exploration.  Right?  There is nothing wrong with making that assumption.  Right?  We likely all know the saying about AssUMe.  I have personally witnessed cases where key elements of the system’s components were not modeled or modeled but all models were not imported so an entire model of the physical system is available.  There are a number of ways learning from models can be tainted:

  • Some of the system is modeled
  • Some parts of the individual components are modeled
  • The models are not up to date
  • The configuration management of updated models is errant (can’t tell which model is the valid model)

12 week prototype parts

12 week prototype parts

Learning and Physical Elements

Even when we do have every key physical element of the system modeled, and all those models are accurate and up to date and imported to see how every part of the system fits together, we still have a need for prototype parts.  There is much to learn through having the physical parts in hand for exploration of the design and interfaces that can not be explored entirely digitally.  For example, models may have unknown (missing) elements that will only rear their ugly head when the parts come together.  Additionally, the physical parts will be required to perform testing.  For modeling that includes environmental simulation, these parts and tests will be the feedback to the environmental components of the model.  This feedback provides information on the quality of the simulation. That is, what we learn in the testing should uncover the range of stimuli to which the product will be subjected (such as vibration profile) that may not be congruent with what we suppose the stimuli to which the product will be subjected.  What happens if the time for this learning is 8 – 12 weeks? What does this do for your ability to learn and speed the speed of that learning?

6 week lead time for prototype parts

6 week lead time for prototype parts


It is possible to move toward fewer prototype parts, but not zero.  The prototype parts are used to understand the real product in ways that the models alone cannot.  The prototype parts are also used to learn more about the impact of the environment upon the product.  If our simulations are sophisticated enough to allow for the environmental stimulus to which the product will be subjected, our prototype parts can help us learn about the variety and ranges of these stimulus and if we have made some mistakes in the model.  A long gap between the design and the availability of physical part does not facilitate learning about the product.  We are not able to quickly adapt the product based upon what is learned, since nothing is effectively learned for months on end, including the implications of the environment on the product.  In this case, the learning about the product is stalled for weeks to months on end.

Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO