The Aging Workforce in Energy

Cycles in business

I’ve noticed an interesting trend among my peers lately. They are retiring! I’m not ready to retire, I’m still having a lot of fun. But, as companies change ownership and leadership, others get packages and encouraged to retire.

This could have a huge impact on our businesses!  So many companies that I work with send people just like me to the key decision-making meetings.  Where are the younger staff that are being groomed to take our positions? I was fortunate, 20-plus years ago, to be brought into the heart of some of the big changes that our industry was going through. At that time, the groups were made up of a mix of young business people like myself, who had good experience, though not deep, plus senior executives with deep knowledge. We learned so much from those senior executives, so that when they retired, we were equipped to step up and fill those shoes. But I don’t see most companies, today, sending those more junior staff into the decision-making processes along with their senior staff. They are still sending the senior staff but only sending one person and not growing someone to take that person’s place.

Yes, there is a cost involved to send two or more people instead of one. But there is a longer-term cost in only sending one person – the company isn’t growing a future generation to take the place of these senior staff. This isn’t true of all companies. I have worked with a few who bring the young people into the discussions with the senior staff, but there are still more seniors in the room than there are juniors.

And yes, I agree, that the younger staff of today are not the same breed that we were 20+ years ago. I think some of those people still exist, but they might be a little harder to find and a lot harder to retain. In recent years, I sent one of my employees to NAESB meetings, technical meetings for which he was well prepared. When he came back from the meeting he told me that if he had to go to those meetings again, he would quit!  What? I agree that it is difficult to work in a group such as NAESB because there are such long established procedures in place and so many long term relationships have been established. But don’t give up on the first try! Stick with it and make it work for you. Another associate, through NAESB, picked a successor to be trained up as a replacement upon her retirement. The person kept being a no-show at scheduled meetings and then claimed to not understand the process.

When I got started in NAESB, I already had 10+ years of industry experience and it was a tough organization to be a part of. Any organization that tries to build consensus on business processes among over 100 different companies is going to have some tough discussions! But the process works! During that time of getting started in NAESB, was also at the beginning of NAESB. To get all of the work done, many of us worked multiple 16+ hour days. Some of us even worked some 24-hour days. We did whatever it took to make the process successful. We need a new wave of this type of workforce in the gas industry. People who will work hard and are passionate about doing a good job and creating a better industry. We need to find those people, retain them, grow them, and prepare them for the future of our companies.

The question then becomes – what are these young people looking for in a company and how do we keep them? Is it benefits? Is it “work-life balance”? Benefits in companies are not the same as they were 20 years ago – and when I began in this industry I knew that these companies would grow ME as a person while growing me as an employee. Is this what recruits are looking for today? Or is it something different? We need to know what the current generation requires. We need to plan for succession.

The Aggravation of Nomination Aggregation in the Pathed Non-threaded Nomination Model

Four-score and seven years ago – okay, really – only one score of years ago – when the Pathed Non-threaded (PNT) Nomination Model was created it was an outlier model type used by one company.  Today that model type is used by many companies and is becoming the source of a lot of interpretation.

There are problems with the way the model type is being implemented today and there are two factors contributing to this problem. We’ll look at them individually then pull them back together to find a solution.

Factor 1:

The Service Requester Contract (SrK) is mandatory on the upstream and downstream nominations of the PNT model and it should not be. Kinder Morgan, Boardwalk and Iroquois have submitted a request to have this changed.

When the model type was created, for NGPL, the NGPL representative, Mike Schisler, explained that the shipper contract (NAESB term = Service Requester Contract) had no meaning on the upstream and downstream nominations of the PNT model.  But the data set designers insisted that it remain. The compromise was that NGPL would fill that field with the service requester’s DUNS number.  That solution has worked for NGPL for many years even though many of us in the industry as well as more recent implementers did not understand the real impact of the decision. The solution implemented by other pipelines varies, is inconsistent, and provides for unintended inconsistencies.

Note that I do not believe there is any documentation in the NAESB standards or implementation guides that specifically says the SrK should be filled with the service requester’s DUNS number.  This was only an “understanding” – which adds an additional level of confusion and was not conveyed to other parties attempting to implement the model in the same way.

Factor 2:

The Service Requester (SR) is defined as the shipper or their agent.

There is one field for a Service Requester on a nomination.  My understanding has been that if the shipper is submitting their own nominations then they will provide their own identifier as the service requester.  If the agent is submitting nominations for a shipper then the agent identifier will be used in the service requester field and the service requester contract will be used to distinguish shipper rights for that agent.

Basic Math:

When we add these two factors together in the model type, you would think that we’d get 3 simple variations since both are mandatory.  SrK used + SR Agent, SrK used + SR Shipper, SrK DUNS + SR.  Not so!  What we’ve seen in the industry is that we have 4 (rumor is that there may be a 5th) variations of how pipelines use these fields to define nominations for the upstream and downstream nominations of the PNT model.

Pipeline Scenario 1:

SR = Agent, SrK = agent DUNS


I have to admit – this is the way that I thought that the PNT model should work when an agent was engaged.  I did not initially recognize the implication of this scenario.  If I, idealistically, apply the definition of the SR and then use the rule of putting the SR’s DUNS into the SrK field then the result is this scenario.

However – if you consider a group of upstream nominations at a receipt location where all of them are designated for the agent, then how does the pipeline determine which transactions belong to which shipper and how is shipper-must-have-title rule being followed?  This would be a plausible solution if the agent has asset-manager rights but not for a traditional shipper agent.  This forces the agent into what I would call an agent-level aggregation where all of the agent’s transactions at a location are aggregated under that agent and not distinguishable by shipper.

Pipeline Scenario 2:

SR = Agent or Shipper, SrK = shipper DUNS


This scenario works the way that I believe the model type was originally intended but it has to abuse the data elements in order to make the model type work.  In this scenario, all of the quantities for one shipper are aggregated at a location so that they can then be distributed among the threaded, contract-specific nominations on the other side of that same location.

If the shipper is the SR then this scenario is clean and easy, though the pipeline is still forced to repeat the shipper DUNS in the SrK field.  When the agent is the SR is where the information becomes muddy and where it becomes obvious that an additional data element, to distinguish the agent from the shipper, is necessary.

Some pipelines have solved this scenario by using the EDI enveloping to identify the agent and, then, identifying the shipper in the SR field.  This works, but it is another forced use of the data elements in a way they were not intended to be used.

Pipeline Scenario 3:

SR = Agent or shipper, SrK = shipper contract


If the pipeline has chosen to use the shipper contract on the upstream and downstream nominations then the issue of whether the party identified in the SR field is nullified.  The level of nomination aggregation has been taken to a lower, contract level, and the contract for aggregation has been identified.  This contract-level aggregation does not provide as much flexibility for the shipper, but all of the data needed to accomplish the task is included.

However, even though the SrK solves the problem, the solution should be consistent across all of the nomination models and model usages.

Pipeline Scenario 4:

Any of the above plus Threaded Nomination association


I am including this scenario because I have seen several companies implement the PNT model in this way even though the data in the transaction does not support this implementation! In this scenario, the upstream and downstream nominations are directly tied to a threaded nomination.  This is essentially a pathed-nomination in most examples where a single upstream is tied to a single threaded nomination and a single downstream, but the implementation does allow for two or more upstream or downstream nominations to be tied to that middle threaded nomination.  There is no aggregation at the contract or shipper level in this scenario because the upstream and downstream nominations are tied to an individual threaded nomination.

Again – the data in the dataset does not support this implementation.  The implementer has to create an artificial connection to tie the various nominations together. The artificial solutions that I have seen are through tracking id’s, package id’s or through the use of a pipeline-managed database internal id that is not maintained by the shipper.  This scenario would be impossible to implement using EDI in the existing dataset.

So where does this leave us?

We need a solution so that shippers know what to expect. We need a solution so that the implementations of the model type can be clean and consistent. We need to add and define the data in the dataset so that it fully supports the model type. We can continue to perpetuate some of our incorrect decisions, but, ultimately that does not buy any efficiency, it allows us to continue with bandaids as solutions.

Here are my suggestions:

1              Split the current “Service Requester” data element into two fields:

Service Holder or Shipper and


Service Holder/Shipper could either be mandatory in all cases, or conditional with a condition that it is mandatory except where a pipeline supports agent-level aggregation and the nominating party has provided an Agent DUNS. I would prefer mandatory and let the pipeline implementation determine how the shipper information is used.

Agent would be conditional – either an agent or service holder must always be provided and Agent is required if the party submitting the nomination is different than the party holding the service contract.

2              As Kinder Morgan, Boardwalk and Iroquois have requested, make the service requester contract a business conditional data element on the upstream and downstream nominations of the PNT model.  It should remain mandatory for all other cases.  It should only be used on the PNT model’s upstream and downstream nominations if the pipeline supports contract level aggregation. Otherwise, it is not used.

3              Make it clear in the nomination implementation guides that there are three levels of aggregation and that a pipeline will generally only support one of those levels.  The three levels are Agent-level aggregation (give an example), Shipper level aggregation (give an example) and Contract level aggregation (give an example).  If parties desire the dataset support additional levels of aggregation then those parties need to submit a request to NAESB for the requirements of that aggregation level to be supported.