The organization I work for requires an ID card to enter the network of buildings that make up our campus. I am a person of routine. My wife often refers to it as OCD, but I prefer to think of it as routine. To some degree, we are creatures of habit.
At any rate, on this particular morning, my commuter vehicle was in the garage for maintenance, so I had to drive another vehicle. I forgot to transfer my parking pass from the commuter vehicle to the one I was temporarily using. I had to stop at the front gate and ask for a temporary parking pass.
"Could you please show me your ID?" the security guard politely asked.
"Sure, hang on a minute," was my reply as I started digging my wallet out of my back pocket. No sooner had begun search for my wallet, that I became painfully aware that my morning routine had somehow been disrupted and I had left my wallet on my dresser. I commute an hour each way and I plead with the guard, now somewhat suspicious, that I for me to run back home for my wallet, would constitute and additional two hours of drive time for me, and two hours of lost productivity for the organization.
Suspicion had evolved to impatient indifference and I was waved on to the security desk at the main entrance. Once I got there, it took nearly an hour to get through all the red tape that would allow me to get to my desk and grind out value for the organization. But I made it. Finally.
What does this have to do with investigations? As you build your Fault Tree Analysis, you need to give each hypothetical cause in your growing tree a value. This value is called a Fault ID. The Fault ID helps investigative team members, approvers and stakeholders understand the relationships of the various faults hypothesized to be potential root cause, as well as potential relationships they may have one with another.
Top line, or First Order hypotheses have a value represented as a whole number beginning with zero or one and progressing from there. Secondary or Second Order hypotheses have a decimal value of one place, such that any hypothesis subordinate to a First Order hypothesis would be as 1.1 for the first hypothesis, 1.2 for the second and so on. Tertiary, or Third Order hypotheses are separated by decimal as a delimeter and follow the same convention as the Second Order hypotheses. In other words, Fault ID subordinate hypotheses to Fault ID 1.1 above, would be 1.1.1, for the first tertiary hypothesis, 1.1.2 for the second tertiary hypothesis, and so forth. This convention is true also for Quaternary and Quinary subordinate hypotheses.
For an example of a partial Fault Tree showing Fault IDs, look at the image below.
When you think of order of magnitude, as you build your Fault Tree, it can become very large and quite cumbersome. This is where the Fault IDs of the various hypotheses becomes most important. Keeping track of these hypotheses, and seeing the potential Interactions that exist are key a successful investigation. Particularly if it is a large scale investigation.
The Fault ID has additional value I'll save for a later post. The point of this post is to explain what, exactly, a Fault ID is and how it is used. Below, you can see an image of what a Fault ID looks like. Just remember that when you are building your Fault Tree Analysis, someone interested in your investigation, perhaps an Investigative Team member, a Stakeholder or an Approver, may ask you...
Could you please show me your ID?
At any rate, on this particular morning, my commuter vehicle was in the garage for maintenance, so I had to drive another vehicle. I forgot to transfer my parking pass from the commuter vehicle to the one I was temporarily using. I had to stop at the front gate and ask for a temporary parking pass.
"Could you please show me your ID?" the security guard politely asked.
"Sure, hang on a minute," was my reply as I started digging my wallet out of my back pocket. No sooner had begun search for my wallet, that I became painfully aware that my morning routine had somehow been disrupted and I had left my wallet on my dresser. I commute an hour each way and I plead with the guard, now somewhat suspicious, that I for me to run back home for my wallet, would constitute and additional two hours of drive time for me, and two hours of lost productivity for the organization.
Suspicion had evolved to impatient indifference and I was waved on to the security desk at the main entrance. Once I got there, it took nearly an hour to get through all the red tape that would allow me to get to my desk and grind out value for the organization. But I made it. Finally.
What does this have to do with investigations? As you build your Fault Tree Analysis, you need to give each hypothetical cause in your growing tree a value. This value is called a Fault ID. The Fault ID helps investigative team members, approvers and stakeholders understand the relationships of the various faults hypothesized to be potential root cause, as well as potential relationships they may have one with another.
Top line, or First Order hypotheses have a value represented as a whole number beginning with zero or one and progressing from there. Secondary or Second Order hypotheses have a decimal value of one place, such that any hypothesis subordinate to a First Order hypothesis would be as 1.1 for the first hypothesis, 1.2 for the second and so on. Tertiary, or Third Order hypotheses are separated by decimal as a delimeter and follow the same convention as the Second Order hypotheses. In other words, Fault ID subordinate hypotheses to Fault ID 1.1 above, would be 1.1.1, for the first tertiary hypothesis, 1.1.2 for the second tertiary hypothesis, and so forth. This convention is true also for Quaternary and Quinary subordinate hypotheses.
For an example of a partial Fault Tree showing Fault IDs, look at the image below.
When you think of order of magnitude, as you build your Fault Tree, it can become very large and quite cumbersome. This is where the Fault IDs of the various hypotheses becomes most important. Keeping track of these hypotheses, and seeing the potential Interactions that exist are key a successful investigation. Particularly if it is a large scale investigation.
The Fault ID has additional value I'll save for a later post. The point of this post is to explain what, exactly, a Fault ID is and how it is used. Below, you can see an image of what a Fault ID looks like. Just remember that when you are building your Fault Tree Analysis, someone interested in your investigation, perhaps an Investigative Team member, a Stakeholder or an Approver, may ask you...
Could you please show me your ID?
No comments:
Post a Comment
Appropriate comments are both welcome and invited. Please feel free to share your thoughts on this post. Thank you.