Subsea Cable Operations Software Problems: The 7 That Cost Ship Days and Start Cost Disputes, and How to Avoid Them

Why does the project get scoped as a maintenance ticketing system?

The request usually arrives as a wish for better tracking. We want to see open faults, who is doing what, and when the ship sails. That produces a ticketing system with a status field and a comments box, and it is the wrong shape for this work in a way that only becomes obvious later.

A repair is not a task with a start date. It is a case that has to hold evidence: fault measurements from the line monitoring system and the terminal, permit correspondence per jurisdiction, ship logs, depot picks with serial numbers, jointing records, post repair test results, and every authorisation given along the way with the clause it was given under. Some of those documents will be read by a lawyer if a claim against a damaging vessel goes wrong, or by an owner who disputes their share eight months later.

The fix is to write the evidence requirement into the acceptance criteria before anyone designs a screen. The first release must be able to export a complete, ordered, tamper evident pack for a single fault, containing every measurement, document, decision and cost line with its source. Build the status view from that record afterwards, where it costs almost nothing. Teams that build the status view first end up with a tidy dashboard and the same email thread underneath it, which means the folder structure remains the real system of record and nothing has actually changed.

What goes wrong with the route position list and as laid data?

Everything in this category hangs off the system model, and the system model is usually a set of documents rather than data. The route position list sits in a spreadsheet issued at handover. Repeater and branching unit positions live in the as laid records. Burial depth is in a survey report. Then a repair adds slack and changes cable length, and that change is noted in a document rather than applied to the geometry, so the next fault localisation is calculated against a route that no longer describes the cable in the water.

This is why the electrical distance from the power feeding equipment and the optical time domain reflectometer trace disagree by a few kilometres and nobody can say which is closer to the truth. The discrepancy is treated as noise when it is actually accumulated drift in the record.

The fix is to make the route position list a first class versioned object with segments, repeaters, branching units, joints and burial depth, and to require that every completed repair updates the geometry as part of closing the case rather than as a document filed afterwards. Store the electrical and optical estimates side by side with their disagreement visible rather than reconciled away, because the size of that gap is itself operational information. Migrate one system first and reconcile it properly against the as laid records, because migrating four systems at once means importing four sets of unexamined drift and trusting all of it.

Why do line monitoring and finance integrations break after launch?

Two integrations carry most of the value here and both are harder than they look on a proposal. Pulling alarms and measurements directly from line monitoring and power feeding equipment means a fault case opens with its electrical distance attached instead of being typed in from a screenshot, which saves the first hour of the response. The obstacle is that interfaces on this class of equipment are not uniform, vary by vendor and by generation, and some are old enough to need serial or proprietary handling rather than anything resembling a modern interface.

The finance integration breaks differently. Allocated cost lines have to post into a general ledger whose calendar, entity structure and currency handling belong to a finance team with their own close deadlines. A month end that closes before a daily ship report has been received creates an accrual problem nobody designed for.

The fixes are practical. Treat each equipment interface as its own scoped item with a named vendor and generation, and require a working capture from a real terminal before sign off rather than a demonstration against sample data. Build a manual entry path that is as good as the automated one, because during a fault the automated feed is exactly what may be unavailable. On the finance side, agree accrual behaviour for costs incurred but not yet documented, and put a reconciliation report between allocated lines and posted journals in front of a human every month rather than trusting the interface silently.

What happens when permits and authority rules are not covered?

These are the two gaps that cost days and money respectively. Permits left out of scope means each application is rebuilt from scratch, usually by someone reading last time's email thread, and applications go to the wrong ministry more often than anyone admits because the correct authority for a given position was institutional knowledge rather than a record. The pack you submitted for the previous repair in the same waters is the fastest possible starting point for the next one, and it is unreachable if permits only exist in an inbox.

Authority rules left out of scope are worse. The construction and maintenance agreement says who can authorise a repair, at what cost threshold, and what happens when the threshold is crossed. If the software does not encode that, a repair proceeds on somebody's judgement and the authorisation is reconstructed afterwards, which is precisely the situation an owner needs in order to challenge their share.

The fix is to make each permit its own record attached to the fault case, with the jurisdiction, the authority, the submitted pack, the status, and any expiry or conditions, structured so packs are reusable. Then encode the authority ladder as rules: this cost band, this approver, this notification, recorded with a timestamp and the clause relied on. Both of these are configuration work rather than engineering, and both need the person who administers the agreement in the room while they are captured.

Should you build custom or configure what you already own?

There is no packaged product for consortium cable operations, and pretending otherwise would be dishonest. What exists is a combination of Excel, SharePoint, Microsoft Project and email, sometimes with a maintenance management system inherited from the terrestrial side of the business.

Some operators should improve that rather than commission software. If you own capacity on systems you do not help manage, your exposure is an invoice you either pay or contest, and a well organised shared drive plus a competent administrator covers it. If you operate exactly one system with a stable consortium, few repairs and a manager who has run it for a decade without complaint, spend the money on documentation first: put the route position list into a database, get the agreement clauses summarised into a decision table with worked examples, and index the permit archive by position and authority. That is a few weeks of disciplined work and it removes a surprising share of the pain. If it does not, you will at least have produced the exact input a build needs.

Build when you operate or manage more than one system, when repair cost disputes routinely run past ninety days, when the person who understands apportionment is one person, or when a landing party or cable maintenance authority relationship has already cost you time because nobody could produce a record on demand.

How do hidden costs get into the quote?

Digital Heroes delivery bands here are $90,000 to $180,000 over 14 to 20 weeks for a first release covering the system model, the fault case with permits and ship coordination, and a cost apportionment engine for one agreement, then $220,000 to $500,000 phased across 9 to 15 months for a full operations platform. The overruns are almost never engineering; they are the work of turning documents into rules.

• Each maintenance agreement. Every additional agreement is a separate rule set, not a configuration toggle, because the clauses were drafted by different lawyers for different consortia.
• Each permit jurisdiction. Different authority, different pack, sometimes a different language and a local representative requirement.
• Equipment interfaces. Line monitoring and power feeding integration priced per vendor and generation, with older equipment costing more than newer.
• Clause interpretation workshops. The time of whoever administers the agreement, which is the scarcest resource in the project and the one most often assumed to be free.
• Owner portal variants. Each owner wanting their own view against their own accounting calendar is real configuration and real support.
• Historical fault reconstruction. Loading past repairs so the cost engine can be validated against known outcomes, which is worth doing and is not free.

Cost stays down by starting with one system and one agreement and accepting that the first release will not touch capacity sales or the network operations centre, both of which have working tools already.

What separates a build that works from one that fails here?

The builds that work capture agreement knowledge as written decisions during discovery, signed off by whoever administers the agreement, before any apportionment code is written. That is the whole game. The rules that make the system valuable usually live with one or two long serving people, and a project that treats them as occasional reviewers rather than the primary source encodes a generic model nobody trusts, which then gets bypassed during the first real fault.

They also make every allocated line traceable to a source document. When an owner queries their share, the response is a statement with the daily ship report attached rather than a spreadsheet and an argument. That single property is what converts a recurring dispute into a routine query, and it is the reason the cost engine belongs in the first release rather than phase two.

The builds that fail were validated in a meeting rather than on a fault. Insist that the first release is used on the next real event, with the previous process running alongside it, and treat any question the system cannot answer during that event as a defect rather than as a future enhancement.

Settle ownership before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and a developer who hedges on that is building a dependency you will pay for at the worst possible moment, which in this business is during a fault.