Putting a Face on Theatre
Root Cause Failure Analysis, also known as “The Blame Game”, getting down to the basics of what caused an equipment and/or operations failure can get messy. It involves looking at the motivations behind the decisions.
NASA’s Apollo 11 Flight Controller, Christopher Craft, is famous for saying: “Failure is not an option.” Agreed. Especially when peoples’ lives are at risk. Reality, or maybe Brother Murphy, would have it differently. Failures do happen. Unfortunately, all too often. We need to make Failure Analysis a part of our work process, just like we would make Near Miss Analysis a part of our training to prevent ‘Almost’ from becoming ‘Oh Sh*t’.
We will all experience failure at some point. We are imperfect. It is minimizing the damage done as a result of our failure(s) that we are seeking. In our attempt to thwart failure, we should always keep good records of our decision process. A good decision / design process starts with a set of goals and parameters.
Start with: What does this need to do? Starting with your end results is better than starting with a preconceived notion of how the problem will be solved. It leaves more options to explore, some of which may be better than the one involving a particular product, tool, or method,
Set your constraints: Budget, weight, dimensions, color(s), time to build, power consumption, etc.
Look at your options: Build, Buy, Rent, etc.
“There is more than one way to skin a cat.” Consider the different ways there are to achieve the end result you are looking for.
A good example of this is selecting a method to display an image:
You could use a flat screen TV, a video projector, an LED wall, a gobo holder, an overhead projector, a slide projector, or maybe a back-lit image printed on an opaque film.
Each solution has implications of cost, sightlines, resolution, and image wash-out.
Projection sources have further complications: Do it from the front or back? From on-axis or off-axis? Short-throw lens or long-throw lens. An depending upon the screen size, screen gain, and ambient light you have to overcome – how powerful of a light source do you need?
Once a solution path is identified, then each of the components within the solution need a similar assessment. In situations involving structural loads, you don’t just grab a bolt off the shelf and say: “Oh, that’ll do.” Instead, you look at the loads involved, check the bolt strength tables, and make a selection that provides the design factor to assure that everything will stay assembled given the worst-case scenario.
Keep a record of those notes either on the drawing or in the project folder. There should be a consensus agreement that the solution is appropriate. A decision made by one person can be much more difficult to justify that one that involved a group and was peer-reviewed.
Root Cause Analysis is the inverse of the Decision Tree – you are deconstructing an event that went wrong. You (and your team) are trying to look back and discover what was the single most likely thing that was misjudged that, when taking all the other factors into consideration, was probably the thing to have triggered the failure.
Something as simple as an injury suffered by a worker that tripped over an extension cord on the floor is a good example:
Embrace the opportunity to review failures, however minor, so that the entire project team can learn from it. There is no need to assign blame to people or offices, instead, focus on the ways you can avoid the problem from occurring again by refining the decision process. Decisions that are well informed produce better options for solutions. Make you hindsight 20-20.