Facilitating Reliability Block Diagrams: Follow the Drop
A reliability block diagram should make a system easier to understand. In practice, most facilitated sessions make it more confusing. The problem is rarely the software or the math. It is how the team in the room is thinking about the diagram.
There is a simple fix for that. Follow the drop.
Whether You Are a Specialist or Not
This is written for mid- and senior-level technical professionals who are not block diagram specialists but who end up facilitating one anyway, in an asset management workshop, a risk assessment, or a capital planning session. Following the drop is the one mental shift that makes a block diagram make sense to everyone in the room, specialist or not.
From the Real World
There was nothing unusual about the group. We had eight key staff from operations, maintenance, engineering, health & safety, and operations technology. We had all of the systems expertise related to mechanical, electrical, and controls.
The issue was getting everyone to agree on a representative block diagram for how raw water passed through the water plant and became drinking water.
“We’ve got to have a parallel path for the electrical supply to the actuated valve,” explained one of the mechanical engineers. “The valve can’t work without power.”
“So is power supply going to stop a water drop from moving through the valve?” the facilitator asked.
“Yes,” the mechanical engineer confidently responded.
“Only if the valve fails shut,” one of the operators quickly interjected. “Our fails fail open.”
“The answer is that the power supply needs its own block diagram,” the facilitator calmly explained. “The actuator needs a certain amount and quality of power. There’s an input for that and it has the potential to be reduced as it moves through the electrical feed system. We need to understand what success looks like for that."
“But Joe is right about the water flow,” the facilitator continued.
“For success of the water drop moving through the system, the valve has to remain in the targeted position. We care only about that for the primary block diagram. How that valve opens and shuts is something we need to also know, but the valve being open is all we need to have for success.”
What a Reliability Block Diagram Actually Shows
A reliability block diagram, or RBD, is a functional model. It shows how a system accomplishes its mission. It does not show how the system is built, piped, or wired.
Each block represents a component or a subsystem. Blocks connect in series, in parallel, or in combinations of both to trace the path to success. The diagram answers one question: what has to work for the system to do its job?
That is a different question than the one most people bring. A block does not show physical layout. It shows functional dependency, and that distinction is where most facilitation trouble starts.
A fault tree diagram models the same system from the opposite direction. A block diagram starts with the mission and asks what must succeed. A fault tree starts with the failure and asks what must go wrong.
Add probabilities, failure rates, and mission time to a block diagram, and it becomes an RBD. The math is what makes it reliability engineering, not the drawing.
Where Facilitation Sessions Go Wrong
Even experienced professionals struggle to facilitate block diagrams well. The reasons show up in almost every session.
People default to physical thinking. They draw pumps next to tanks because that is how the plant looks on the ground, not because that is how the system depends on itself.
Teams confuse equipment grouping with functional dependency. Two assets sitting in the same room does not mean they belong in the same block.
Hidden dependencies get missed. A parallel path can look redundant on paper, but if both branches rely on the same upstream control, the redundancy is false.
Each of these mistakes slows the session down. Worse, they produce a diagram that looks finished but does not reflect how the system actually works.
Follow the Drop: A Simple Discipline for Facilitators
Following the drop keeps a team focused on function instead of geography. Start with the element that has to move through the system to accomplish the mission. In a water system, that is the water drop. In an electrical system, it is the current. In a data system, it is the information packet.
What has to happen for this element to reach its destination? What equipment must it pass through? What can impede or stop it?
That thought process does the facilitation work. It forces the group out of physical layout and into functional logic. It surfaces where flow can be restricted or stopped. It also reveals which redundancies are real and which are only assumed.
Five Ways to Keep a Team Following the Drop
Name the element before you start and agree on a function statement. Agree as a group on what is moving through the system, whether it is water, current, load, or data. Agree on how much of the input must pass through the system as an output.
Ask what happens to it here at every block, not what the equipment does.
Challenge every parallel path. Ask whether the two branches truly operate independently, or whether they share an upstream dependency that would take both down together.
Redraw before you calculate. Get the functional logic right first. Failure rates and mission time are wasted effort on a diagram that models the wrong system.
Keep the drawing software out of the first pass. A whiteboard or sticky notes surface disagreement faster than software does. Save the software for the version the team has already agreed on.
Why the Discipline Is Worth the Trouble
Block diagrams are essential anywhere a system depends on a defined path to success. Water and wastewater utilities use them to find single-point failures. Electric utilities use them to evaluate feeder and substation performance. Manufacturing plants use them to find production bottlenecks. In every case, the diagram becomes a decision tool, not paperwork.
A reliability block diagram is only as good as the thinking behind it. Follow the drop (the input), and the thinking takes care of itself.
This article is the first of three on tools I rely on in FAST root cause analysis. Work process diagrams and causal factor timelines are next.
JD Solomon is the founder of JD Solomon, Inc., the creator of the FINESSE Fishbone Diagram®, and the co-creator of the SOAP criticality method©.
Comments