top of page
Dependability builds on reliability by accounting for real-world uncertainty. JD Solomon Inc. provides practical solutions for facilities and infrastructure.
Dependability builds on reliability by accounting for real-world uncertainty.

We often use “dependable” and “reliable” interchangeably. Both words describe consistency, trust, and confidence. Yet in both people and systems, there’s a subtle but critical distinction between the two. Understanding that difference can transform how we lead teams, manage assets, and build trust in our organizations.

 

Dependability: The Human Side of Trust

Dependability begins with trust. It’s not just about doing something well; it’s about doing what you said you’d do. A dependable person doesn’t make promises lightly, and when they do, they follow through—even when it’s inconvenient. They’re the people you want beside you when things go wrong.

 

Dependability has a distinctly human dimension. It’s about integrity, accountability, and resilience under pressure. A dependable team member delivers not only consistent results but also demonstrates character and commitment when the stakes are high.

 

In leadership and management, dependability is the foundation of confidence. Colleagues and clients trust a dependable leader to make sound decisions and communicate honestly, especially when uncertainty looms. Dependability builds the kind of professional relationships that endure — the kind that carry teams through change, challenge, and crisis.


 

 

Reliability: The Technical Measure of Performance

Reliability, on the other hand, is about consistency of performance — not necessarily about trust or emotion. When we describe a system, process, or product as reliable, we’re saying it performs predictably, time after time, under specified conditions. It’s measurable. It’s objective.

 

Engineers and asset managers think in terms of failure rates, uptime, and mean time between failures (MTBF). Reliability is the backbone of operational excellence. A reliable pump performs within tolerance every day; a reliable process meets its target 99.9% of the time.

 

Reliability focuses on the technical probability that something will do what it's supposed to do. Dependability extends that notion into the human and organizational domain, where trust, communication, and responsibility matter as much as mechanical consistency.

 

Why the Difference in Reliability and Dependability Matters

This distinction between dependability and reliability is more than academic — it affects both human performance and technical systems.

 

A reliable employee shows up on time and meets deadlines. A dependable employee is the one you trust to manage a crisis when the unexpected happens. Reliable systems perform well under expected conditions. Dependable systems are designed to perform even when conditions aren’t ideal — when something breaks, when input changes, or when human intervention is required.


 

 

That’s why dependability often includes additional factors like resilience, redundancy, and recoverability. Reliability keeps things working as planned; dependability ensures they keep working when plans fail.

 

The People Implications

In teams and organizations, reliability and dependability often show up together, but they don’t always mean the same thing.

 

A reliable team member completes tasks on time, follows procedures, and meets quality expectations. But when the situation becomes complex or ambiguous, you look for the dependable person — the one who steps up, communicates clearly, and get the job done no matter what.

 

Think of the dependable coworker as the one you trust with the keys when you’re away. They’re the person who keeps their word, protects the team, and doesn’t look for shortcuts when pressure mounts. Dependability is about judgment and character; reliability is about predictability and process.

 

Good organizations cultivate both. They set up systems that promote reliable performance and hire or develop people who can be counted on when reliability alone isn’t enough.

 

The System Implications

In asset management and engineering, reliability is the measurable attribute that defines how well systems perform over time. Dependability, by contrast, is a broader concept that includes reliability but also adds dimensions such as availability, maintainability, safety, and integrity.

 

A reliable system operates without failure for a given period. A dependable system continues to deliver safe and acceptable outcomes even when part of it fails.

 

For example, an aircraft's engine system must be reliable (i.e., the engines should operate predictably within their design limits). But the aircraft as a whole must also be dependable (able to complete a safe flight even if one engine fails). Dependability builds on reliability by accounting for real-world uncertainty.

 

Dependability incorporates measures such as redundancy, fault tolerance, and monitoring. It’s the combination of design, maintenance, and human oversight that keeps systems functioning in complex environments.


As asset managers, we use data, metrics, and models to improve reliability. But it’s our judgment — our dependability as decision makers — that ensures those systems stay safe, sustainable, and resilient.


 

 

Practical Examples That Illustrate the Difference

A few simple examples highlight the distinction.

 

The Car Example

A reliable car rarely breaks down. A dependable car starts every morning when you need it most, even in the cold or after sitting idle for a week. Reliability is about performance; dependability is about trust.

 

The Coworker Example

A reliable coworker meets deadlines and follows procedures. A dependable coworker steps up during a crisis, keeps commitments, and protects the project’s success.

 

The Restaurant Example

A reliable restaurant consistently serves quality food and provides good service. A dependable restaurant makes sure your meal is right, even when the kitchen is slammed and something goes wrong.


In each case, dependability extends reliability into the realm of trust and response. It’s what turns “good enough” performance into true confidence.


 

 

The Broader Lesson: Systems Reflect People

In the end, dependable systems come from dependable people. Reliability is achieved through design, discipline, and data. Dependability is achieved through leadership, communication, and accountability.

 

When we design for reliability but neglect dependability, we risk building systems that work well until something unexpected happens. When we lead for dependability without attention to reliability, we create teams with good intentions but inconsistent outcomes.

 

Both are essential. Reliability gives us performance. Dependability gives us trust. And together, they create systems and organizations that stand the test of time.

 

 

 JD Solomon Inc. provides solutions for program development, asset management, and facilitation at the nexus of facilities, infrastructure, and the environment. Visit our Asset Management page for more information related to reliability, risk management, resilience, and other asset management services.

JD Solomon writes and speaks on decision-making, reliability, and communication for leaders and technical professionals. His work connects technical disciplines with human understanding to help people make better decisions and build stronger systems. Learn more at www.jdsolomonsolutions.com and www.communicatingwithfinesse.com

Using the Capital Improvement Program to validate your asset data quality is a practical and useful exercise. JD Solomon Inc. provides practical asset management solutions.
Using the Capital Improvement Program to validate your asset data quality is a practical and useful exercise.

How reliable is the asset data in your enterprise asset management system? There’s a good chance the people in charge of the system will say it’s 90 to 95 percent populated and accurate. Experience bears out that it’s not that good, but you will never know until you test the data in a real-world application. The capital improvement plan provides a meaningful opportunity.


So, What Are the Steps?

A capital improvement plan (CIP) is a multi-year framework that outlines planned investments in infrastructure, facilities, and major assets, including project priorities, funding strategies, and timelines. Projects are developed through a structured process of needs assessment, prioritization, cost estimation, and alignment with strategic goals, funding availability, and external input.


Asset inventories support the development of capital projects by providing detailed data on asset condition scores, asset type, location, lifecycle stage, and performance. This further enables data-driven prioritization and forecasting of infrastructure investment needs.


These three steps describe how to test the quality of your asset data through the capital plan development process.


1. Sort By Asset System and Subsystem

The key issue is whether everything is “in” the system or subsystem that needs to be in. Capital projects are most often implemented to expand or enhance a function.


For example, a wastewater pump station is a vertical asset that lifts wastewater from lower elevations to the collection system using pumps and motors. It includes valves and piping to control flow, electrical and control systems for power and automation, and structural elements like wet wells and control buildings for containment and access. Safety and support systems, such as ventilation, gas detection, and odor control, ensure reliable and secure operation of the station.


Similarly, a chemical feed system typically includes mechanical assets such as chemical storage tanks, dosing pumps, and piping to deliver precise amounts of chemical. It also has electrical and control assets, including motor controllers, flow meters, level sensors, and PLCs for automated operation. Safety and support assets, such as containment basins, ventilation systems, and leak detection systems, protect personnel and the environment.

 

Vertical assets

Vertical assets are physical structures or facilities that extend primarily upward, housing systems, equipment, or operations, and that are managed as discrete, contained entities. They include buildings and the systems within them (such as HVAC, electrical, plumbing, elevators, and control systems).


The key to vertical assets is to distinguish between their location (i.e., chemical building) and their functions (systems and subsystems like polymer feed system). Many enterprise asset management systems are rooted in work management, so location is often the focus rather than the function. In many cases, the nomenclature bounces around depending on who is in charge of the operation and the data.


For capital projects, association with the system or subsystem is how renewal and replacement projects are implemented. The first test of data quality is whether the assets are functionally defined in a meaningful way.

 

Tip: Assets like electrical, instruments, safety equipment, and piping are often dropped into a generic “bucket” classification and not associated with the subsystems they support. Make sure to include another field that associates them with their subsystems.

 

Key question: Can all assets related to a function be identified from the data?

 

Horizontal assets

Horizontal assets are linear infrastructure systems that extend across a geographic area and are typically continuous or networked in nature. They include assets such as pipelines, roads, sewer and water lines, storm drains, and transmission or distribution networks that connect multiple facilities or service areas.


The trick with horizontal assets is to determine how to break them into specific projects since they are spread across large geographies. In this case, systems or subsystems can be identified by watersheds, pressure zones, or service areas. Usually, valves, manholes, circuit breakers, or switches are good break points.


Similar to vertical assets, the first test of data quality is whether horizontal assets can be associated with systems or subsystems in order to group readily into projects.

 

2. Verify the Condition Score

Condition scores are a helpful way to estimate remaining useful life. For capital projects, one of our normal objectives minimize stranded asset value. In other words, we’re only replacing what needs to be replaced.


After associating the assets with their functions and then with a capital project, the test is whether we have too many 1s (newer assets) versus 5s (assets overdue for failure).


Making sure we are not stranding asset value means

  1. There is a condition score for every asset.

  2. A consistent framework was used for all condition scores

  3. Condition is frequently updated (or know when the condition score was developed)

  4. The condition score was applied to the correct, in-service asset.

 

Tip: Look at the asset description and install year for signs that the asset condition score may be questionable. I have seen things like PVC pipe installed in 1921 (before PVC was manufactured) or an electrical motor control center from 1951 (maybe, but they became most common in the 1970s and probably rebuilt several times if so), which are red flags that the condition score may not be applicable to the in-service asset.

 

Key question: Can we determine from the data whether we are replacing too many assets that don’t need to be replaced?

 

3. Verify the Asset Value

Asset values provide a helpful approach for estimating the preliminary budget for a capital project. The asset values in nearly every enterprise asset management system I have seen are highly suspect; nonetheless, it is an approach for evaluating asset data quality.


The big caveat is that most enterprise asset management systems use replacement asset value (RAV) as good practice because many maintenance and operations metrics can be tied to it. Replacement Asset Value (RAV) is the estimated cost to replace an asset with a new one of similar capacity, function, and efficiency at current prices. It normally includes the asset cost plus estimated labor install costs.


Unlike insurance Replacement Value, which reflects the cost to cover losses for claims purposes, or Book Value, which reflects historical cost minus depreciation, RAV focuses on current functional replacement for asset management and planning purposes. RAV is also different than asset values taken from competitive contractor bid tabs, which include project costs such as legal, permitting, engineering, and bidding.

 

The test is whether we have too wide a range for assets of the same class or type. Sort assets by class and type, review descriptions and install years, like for condition scores, to make sure there is an apples-to-apples comparison. Then, make sure:

  1. There is an asset value for every asset

  2. The values are in a consistent range

  3. The values were developed consistently (RAV, Replacement Value, etc.)

  4. Asset values are frequently updated (or know when the asset value was developed)

  5. The asset value was applied to the correct, in-service asset

 

Tip: Be content with a fairly wide range of values (i.e., $30,000 to $60,000) that approximately doubles the free-on-board (FOB) asset costs normally quoted by equipment vendors for this type of asset. The sign that different methods were used for asset value is orders-of-magnitude differences (i.e., $1000 versus $10,000).

 

Key question: Are we using the appropriate asset values in our base project estimates?


The Typical Results

For mature operations, I usually see between 15 and 25 percent of the assets missing at least one field of data, or that we simply know an asset needs to be added or deleted.



When we test the data, either through the capital improvement plan shared here or by developing a renewal and replacement forecast (forecasting future needs), we usually find that another 10 to 20 percent of the data contains an incorrect attribute. Those wrong attributes are important and include items such as incorrect location, subsystem, asset type (or material), condition score, or value. The consequence is that the data becomes untrustworthy as a whole and unreliable for decision-making applications.

 

Validating Asset Data Quality through Capital Plan Development

Using the Capital Improvement Program to validate your asset data quality is a practical and useful exercise. The quality of your asset data will always be overstated, and quality is more than simply having all attributes populated. You will never know how good the data is or where it needs improvement until it is tested in a decision-making application.



JD Solomon Inc. provides solutions for program development, asset management, and facilitation at the nexus of facilities, infrastructure, and the environment. Visit our Asset Management page for more information related to reliability, risk management, resilience, and other asset management services.



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©. He is the author of Communicating Reliability, Risk & Resiliency to Decision Makers: How to Get Your Boss’s Boss to Understand and Facilitating with FINESSE: A Guide to Successful Business Solutions.

Reliability earns confidence when things go right. Dependability earns trust when things go wrong. JD Solomon Inc. provides practical solutions for reliability, risk, and asset management.
Reliability earns confidence when things go right. Dependability earns trust when things go wrong.

In business, leadership, and life, we praise reliability—consistent performance and results. Reliability builds credibility. It’s measurable, predictable, repeatable. Dependability runs deeper. Dependability says, “You can trust me when it matters most.”

 

Reliability is a system trait; dependability is a human one. You can track reliability in a spreadsheet — uptime, cycle counts, or deadlines met. Dependability shows up in moments of pressure, when conditions change, and when others need reassurance that someone will step forward.

 

“A reliable system performs when everything goes right.

A dependable system performs safely when things go wrong.”

 

A reliable team member follows the plan. A dependable one keeps the mission moving when the plan falls apart. Reliable systems perform well when everything goes right. Dependable systems perform safely when things go wrong.

 

Dependability is about confidence and credibility. It is the part of leadership that isn’t measured in metrics. Dependability is seen in actions like staying calm in the face of uncertainty, telling the truth when it’s inconvenient, or owning the result when the data is incomplete.

 

FINESSE reminds us that effective communication depends on both reliability and dependability. The “Structure” and “Synergy” in FINESSE ensure the process runs smoothly. That’s reliability. But the “Empathy” and “Ethics” are what make others trust you when reliability isn’t enough.

 

If you want to endure, don’t stop at being reliable. Reliability makes people listen; dependability makes them believe.



The elements of the FINESSE fishbone diagram® are Frame, Illustrate, Noise reduction, Empathy, Structure, Synergy, and Ethics.



JD Solomon writes and speaks on decision-making, reliability, and communication for leaders and technical professionals. His work connects technical disciplines with human understanding to help people make better decisions and build stronger systems. Learn more at www.jdsolomonsolutions.com and www.communicatingwithfinesse.com.

Experts
bottom of page