Gas Nomination Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a nomination project get scoped as a submission tool?

The most common scoping failure in this category is building a faster way to type. The proposal describes a single screen where a scheduler enters nominations, the system pushes them to each pipeline, and confirmations come back. It demos well, it is cheap to estimate, and it changes nothing, because the scheduler's real work happens before the typing.

What she is actually doing at 12:40 with twenty minutes to the timely close is solving an allocation problem. Given today's supply by point, the transport and storage capacity available to move it, the demand it has to serve, the imbalance already accrued on each pipeline and the cost of being wrong on each, where does the gas go? The workbook is not a typing aid. It is the model. Replace the typing and she keeps the workbook, which means you have paid for a system that sits beside the real one.

This happens because the visible artefact is the nomination and the invisible artefact is the reasoning. A developer watching a scheduler for an hour sees eleven portals and concludes the problem is eleven portals.

The fix is to make the contract model the first deliverable. Ask a prospective developer to draw it before anything else. If they draw pipelines and volumes, they will build a form. The right model has contracts carrying maximum daily quantities, receipt and delivery point rights, fuel and lost and unaccounted for retention, storage injection and withdrawal ratchets tied to inventory level, and terms that vary by day and by season. Then ask what the system proposes, not what it submits. If it cannot suggest an allocation the scheduler adjusts in five minutes, the workbook survives and so does the problem.

What goes wrong when you turn contracts into structured constraints?

The schedule risk in these projects is almost never engineering. It is contract discovery, and shippers are routinely surprised by what their own agreements say.

Transport agreements are the easiest and still take longer than anyone plans, because point rights and seasonal terms are often amended by letter agreements filed separately from the base contract. Storage is genuinely difficult: ratcheted injection and withdrawal rights that change with inventory level are fiddly to model correctly and easy to model plausibly but wrong, which is worse. Supply deals carry index pricing, minimum takes and operator behaviour that bears little relation to the contract text. And capacity release and asset management arrangements change who is nominating on whose behalf, which quietly breaks any model that assumes one shipper per contract.

The second failure is the long tail. A shipper with eleven pipelines has four that carry most of the volume and seven that carry edge cases, and the edge cases are where the unusual contract terms live. Teams that try to model all eleven before shipping anything spend two months in contract review and lose the project's momentum.

The fix is to sequence discovery and accept manual for the tail. Model the four or five pipelines carrying most of your volume and the contract types you actually use, ship that, and leave the remainder in the workbook for a while. It will cost you almost nothing to leave them there. Budget explicit hours for a person who can read a gas transport agreement, and treat any contract nobody can locate as a finding rather than an inconvenience.

Why do the pipeline connectors break after launch?

Every multi pipeline shipper ends up with a mix of interfaces. Where a pipeline offers electronic data interchange or an application programming interface, you use it and it is stable. Where it only offers a portal, you automate the portal, and portals change.

The failure is not that connectors break. That is expected and unavoidable. The failure is how they break. A portal redesign, an added confirmation step, a session timeout change or a new terms acceptance screen will typically produce a submission that appears to succeed. Nothing errors. The scheduler sees sent, the pipeline sees nothing, and the discovery happens after the cycle has closed. Any developer promising this will never happen has not maintained a portal integration.

The second version of this failure is credential handling. Portal logins expire, get rotated by a pipeline, or lock out after a password policy change, and if credentials live in a configuration file nobody owns, the lockout arrives on the day the person who set it up is on leave.

The fix is positive confirmation and severity based alerting. A submission is not complete until the pipeline has acknowledged it and the system has read that acknowledgement back, and anything without an acknowledgement inside a defined window escalates to a human by phone if the timely deadline is close. Build a deadline aware alert ladder rather than a single email channel, because a discrepancy at three in the afternoon and a failed submission at 12:55 are not the same event. Then agree in the contract who fixes a changed portal, how fast, and at what cost in year two.

What happens when imbalance, flow orders and the audit trail are not covered?

Three gaps recur, and each one is discovered at the worst available moment.

Imbalance is the first. Gas accounting systems calculate it accurately after allocation, after the month closes. That is correct for accounting and useless for operations, because by then every cycle that could have traded, parked or adjusted out of trouble has passed. A shipper without a live estimate finds out from the statement and pays whatever the tariff says.

Operational flow orders are the second. They land on a pipeline's informational postings, carry penalties written into the tariff, and have short response windows. If nobody is polling postings overnight and on weekends, an order on a pipeline you are not actively working reaches you the next morning, which is often after the window that mattered.

The audit trail is the third and the most quietly damaging. A pipeline disputes a scheduled quantity, or a trader claims the desk failed to move gas that was bought, and the evidence is a workbook overwritten four hundred times.

The fix is to build all three into the first release rather than phase two. A running estimated imbalance per contract per pipeline, computed from scheduled quantities against measured actuals with an explicit confidence indicator so nobody treats an estimate as settled. A watcher polling postings and critical notices continuously with routing by severity and time of day. And every nomination stored as an immutable submission carrying the portfolio state it was computed from, the constraints active at the time, the confirmation received and any override with the person and the reason. That last one costs almost nothing when designed in and is close to impossible to retrofit.

Should you build custom or configure what you already own?

If you nominate on one or two pipelines under straightforward firm transport with stable supply and demand, stay where you are. The pipelines' own electronic bulletin boards plus a well kept workbook will do the job, and a build would be an expensive way to formalise something that already works. We tell small marketers this regularly and it is the right advice.

The packaged tools are also a fair fit for a genuinely conventional portfolio. Quorum PGAS and ION Openlink handle the transactional and accounting side competently. Energy Solutions International PipelineManager and Latitude Technologies connect to bulletin boards and do it credibly. If your portfolio is firm transport, no active storage optimisation and no marketing desk changing positions inside the flow day, configure one of them and spend the difference elsewhere.

Where they stop is representing your specific constraint set well enough to propose a nomination, and encoding the negotiated behaviour of each pipeline relationship. Neither will tell you that a particular pipeline's confirmation pattern means you should submit early on Fridays. That knowledge sits with the scheduler who has done it for nine years, and if her workbook is the real system, that is what a build replaces.

Build when two or more of these are true. You nominate across more than about six pipelines. You actively optimise storage rather than filling and draining it. Your marketing desk changes positions inside the flow day and the scheduler learns by text message. Cashout has become a monthly cost you have stopped questioning. Or one person holds the entire function and cannot take a week off in January.

How do hidden costs get into the quote?

Four items reliably arrive after signature. Connectors, counted per pipeline in the proposal and then discovered to be two different classes of work, because an interface based connector is built once and a portal based one carries permanent maintenance. Storage, where ratcheted rights turn a line item into a modelling exercise. Capacity release and asset management agreements, which change the shape of the contract model rather than adding to it. And intrastate pipelines or local distribution company citygate arrangements that do not follow the shared conventions cleanly.

The fifth is the write back. If the system has to push results into an existing gas accounting package rather than own both ends, that integration is usually scoped as a feed and delivered as a reconciliation problem.

The fix is to force the quote to distinguish. Ask which pipelines are interface based and which are portal based, and what the annual maintenance figure is for the portal group. Ask whether storage ratchets are in release one. Ask what happens to capacity release. And ask for a monitoring and alerting plan for connector failure in writing, because that is the difference between a vendor who has run one of these and a vendor who has demonstrated one.

What separates a gas scheduling build that works from one that fails?

The builds that work respect the clock. The gas day starts at 9:00 a.m. Central, the timely cycle closes at 1:00 p.m. the day before, evening follows at 6:00 p.m., and three intraday cycles run through the flow day. That makes the system deadline driven rather than batch driven, and everything about it follows: assembly, validation and submission all have to complete inside a fixed window, failures have to surface in seconds rather than at the next refresh, and intraday re optimisation is a first release feature rather than a later addition. Confirm current cycle timing against each pipeline's tariff, since practice varies at the edges.

They earn the scheduler's trust rather than assuming it. Run the new system in parallel with the workbook for at least a full month including a month end close before retiring the spreadsheet, and make the system's proposed allocation visible with its reasoning so she can see why it differs from hers. Plan the transition for a shoulder month, because cutting over in winter is how a good build acquires a bad reputation in one cold snap.

They start narrow deliberately. Four or five pipelines, the contract types you genuinely use, the audit trail from day one. The long tail can wait and the tail is where the schedule overruns hide.

And they settle ownership before kickoff. The repository, the infrastructure accounts, the connector code and the credentials, in writing, with the right to hire another firm. At Digital Heroes the client owns all of it from the first commit. Connectors are the piece vendors most often try to retain as a service, and that is precisely where a dependency becomes expensive, because your access to eleven pipelines then runs through someone else's contract.