Most pipeline safety management systems start with real momentum. A team works through the elements of API RP 1173, writes procedures, assigns owners, and gets leadership sign-off. Then the program settles into the background. A year or two later the manual is still on file, but it is hard to point to anything the program has actually changed.

That pattern usually isn’t a failure of effort. More often it comes down to measurement, and it tends to show up in the part of the program that is supposed to keep everything else moving.

Where Pipeline SMS Came From

In July 2010, a hazardous liquid pipeline ruptured near Marshall, Michigan, releasing crude oil into Talmadge Creek and the Kalamazoo River. The NTSB investigation looked beyond the failed pipe to how the operator identified and responded to risk as an organization, and its 2012 report recommended that API develop a safety management system standard for the pipeline industry.

API RP 1173 was published in 2015 in response. It is a recommended practice, not a regulation. PHMSA has encouraged operators to adopt a pipeline SMS based on a framework such as RP 1173, including in a 2025 advisory bulletin, but it has not made the standard mandatory. Operators who adopt it are choosing to manage safety as a connected system, which only delivers value if it keeps running.

Built Once, Then Left Alone

Consultants who help operators implement RP 1173 point to continuous improvement as one of the most common places programs break down, often because the program was approached as a box to check.

The first pass is usually run as a project, with a kickoff, deadlines, and a finish line. Gap assessments are completed, procedures are written, and documentation is organized for review. When the project wraps up, the program is treated as finished.

RP 1173 isn’t designed to be finished. It follows a Plan-Do-Check-Act structure, so checking and adjusting are meant to feed back into planning on a recurring basis. A program that stops after the first round of doing has a documented plan and little evidence that it works. If the last meaningful update to your program traces back to the original rollout, this is likely the pattern you’re in.

What Lagging Indicators Can and Can’t Tell You

When programs do measure performance, they often measure what is easiest to count, such as incident totals, injury rates, equipment failures, and audit results. These are lagging indicators. They describe what already happened and register nothing until something has gone wrong.

Lagging data has a legitimate role in compliance reporting. What it can’t do is show where risk is building before it becomes an event. A quarter with no incidents may reflect a healthy program or simply good fortune, and lagging data alone can’t tell the two apart. Best practice guidance from the UK Onshore Pipeline Operators’ Association makes the same point, citing the 2005 Buncefield and Texas City accidents as evidence that failure data and audit output aren’t enough to monitor performance.

Leading indicators serve the opposite purpose. They track whether the systems meant to prevent an incident are working, while there is still time to act.

What a Leading Indicator Looks Like in Pipeline Operations

Within RP 1173, Safety Assurance is the element concerned with whether the program is actually working, and each indicator below ties back to a specific element of the framework.

• Training currency (Competence, Awareness and Training). Are qualifications and refresher training current for the roles people hold today? A growing count of overdue items usually means training hasn’t kept pace with turnover or procedure changes.
• Procedure deviation reports (Operational Controls). Rising deviations can point to procedures that no longer match how work is done in the field. A sharp drop deserves a look too, since it can mean people have stopped reporting.
• Corrective action aging (Safety Assurance). When the average time items stay open climbs, the organization is finding problems faster than it is resolving them.
• Near-miss reporting rate (Incident Investigation, Evaluation and Lessons Learned). A declining rate rarely means fewer near misses are happening. More often it means fewer are being reported.
• Management of change cycle time (Operational Controls). If changes take longer to clear review, or are closed out with shortcuts to keep pace, the controls around them are under strain.

Each of these depends on records that can be pulled together in a usable form every month, which is harder than it sounds.

Easy to Count Isn’t the Same as Useful

There is a related trap. It is tempting to pick numbers that are simple to report, such as procedures on file or training sessions held. Those figures tend to trend upward and look good in a presentation, but they say very little about risk.

More useful indicators measure time and direction, such as how long problems sit before they are fixed or whether reporting rates are rising or falling. Those are harder to collect, which is why they need a reliable place to live.

Getting Indicator Data into Management Review

Indicators only matter if they change a decision. Management Review and Continuous Improvement is its own element in RP 1173, so indicator data has to reach the people who can act on it on a regular cadence. A report that gets produced and never discussed doesn’t meet that intent.

What we hear from operators is that programs rarely stall for lack of a framework. They stall because the information needed to run it is scattered. A common picture looks something like this:

• Training records sit in an LMS or HR system.
• Corrective actions are tracked in a spreadsheet.
• MOC history lives in email threads.
• Near-miss reports come in on paper forms or through a separate reporting tool.

Assembling all of that for a monthly review becomes a manual effort that depends on one person, and it tends to stop when that person’s priorities shift or they move on.

Seen that way, this is a data consolidation problem first. ComplyMgr, part of the EnerSys POEMS Program Suite, is designed to give operators a single source for program documents and records. It links policies and procedures to the regulations, FAQs, and inspection questions they respond to, supports gap assessments against those requirements, and produces corrective action plans to address the findings. Having those records in one place gives the check and adjust steps something consistent to work from, rather than whatever can be assembled the week before a review.

Software won’t choose the right indicators or hold the review meeting. What it can do is make the underlying records easier to find and keep current, which removes a common reason the review stops happening.

Measuring PSMS Maturity

A current manual isn’t a measure of PSMS maturity. A better test is whether indicator data changed a decision in the last quarter. A few questions to ask before the next management review:

• Which leading indicators did your team review last quarter, and what did they show?
• Did any of them lead to a resourcing or procedure decision?
• Are corrective actions from your last gap assessment closed, and how long did they take?
• Could the data for that review be assembled without one person rebuilding it by hand?

If the answers point to real decisions, such as a resourcing conversation driven by corrective action aging, the program is working the way RP 1173 intends. If they don’t, the program has probably stopped improving, and the place to start is with what is being measured and where that data lives.

If your team is working out how to keep PSMS records, gap assessments, and corrective actions in one place, contact us to see how EnerSys can help.