- Subject Matter Experts and Process –
Problem Solvers are often asked to facilitate a root cause analysis session because the problem owner is of the view that the problem is complex. This article will focus on “how to process/facilitate a root cause analysis for a complex technical problem,” and the use of Subject Matter Experts (SMEs).
Firstly, a problem can be regarded as a complex problem when:
- Divergent opinions exist in respect of the actual problem statement.
- The problem in hand has a large number of information/data pieces.
- Information Knowledge and Quality of information/data may be low.
- The analysis of the problem is dependent on inputs from a number of subject matter experts.
Facilitating the process to resolve such a complex problem revolves around the management of the foregoing issues. Unless these complexity parameters can be addressed and managed, finding cause will be almost impossible.
A good point of departure is to start by selecting the appropriate subject matter experts and information sources who are key to the observed problem. Typically ask the following questions to form a core team of 4 to 6 persons:
- Who, from a customer perspective, experiences the negative consequences of the problem?
- Who can provide knowledge about the technical functioning of the area in which the problem is present?
- Who was in control of the operating environment (actual shop floor operations) when this problem occurred/recurred?
- Who has an integrated systemic view of the operating environment in which the problem occurred?
The answers to these questions will enable you to identify candidates for a core team to start the root cause process with. As a second tier, identify all those who has “skin in the game” and keep them informed every step of the way.
An initial meeting of the team should have as its purpose to ensure that the correct problem statement is decided as a point of departure for the RCA to follow. An initial agreement should be sought in respect of the problem in respect of (a) object/s, (b) fault/s, (c) location/s, (d) time and (e) any specific unique features. Once the foregoing is available the team can work on a core problem statement that will state, “What is Wrong? With What?”, i.e. an object and fault statement.
Instead of jumping in to a facilitation session, it is advised that a core of approximately 2 people be tasked to build the “problem specification” from both known information and new information. This problem specification need to contain 2 factual groupings (a) what the actual problem is, and (b) what the problem could be but is not, in order to build a base for comparison. In addition, it is important to capture all intuitive thoughts and suggestions re cause in parallel as they may occur, but care should be taken that this not be misconstrued as facts. Once a draft provisional problem specification is available using KEPNERandFOURIE CauseWise ™, a facilitated session can now be used to move the process forward.
At the outset of this session, it is important that those present review the problem specification and agree factual correctness of what the problem is and also what it could be, but is not. It is critical at this juncture that every single piece of information in the problem specification is clearly captured as “fact” or “intuition” or “unknown”. Once information gathering has been completed, it would now be appropriate to open the floor to an open session, for participants to list all possible causes that they might think could be the cause.
Possible causes listed should firstly be screened for causes that are (a) duplicates [combine these] and (b) those possible causes that form a cause and effect hierarchy. In the case such a hierarchy exists, display it and mark the elements in the hierarchy that within the operating environment may have been the cause of the problem. Formulate a new list of possible causes.
In the case of very complex problems, the list of possible causes list may be quite extensive. It is therefore appropriate to reduce this list by removing the possible causes that conflict with the fact base in respect of what the problem IS and what it could be BUT IS NOT. This paper testing exercise normally reduces the possible causes to handful of possible technical causes that could be verified either through an inspection/observation in the operating environment or from a technical knowledge perspective by a subject matter expert.
