Nuclear Outage Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the constraint model scope get underestimated so often?

The requirement gets written as a mobile view of the outage schedule with live updates, and it is quoted accordingly. It is a reasonable sounding scope and it produces a system nobody uses past week one, because the reason the published schedule and reality diverge from about day three is not that the schedule is hard to see.

What governs a refueling outage is a set of objects that no scheduling tool carries. Technical specification limiting conditions with allowed completion times. Shutdown safety function availability. Clearance orders and the tag conflicts between them. Contamination and radiation zone access. Fire protection compensatory measures. Configuration control on systems that are partly disassembled. Those constraints are currently enforced by experienced people in the five in the morning meeting, and if the software does not carry them, the software is a display and the meeting is still the system.

The scope that earns its cost is a constraint model per work order: the clearance it requires, the radiation work permit scope it falls under, the zone it occupies, the qualifications the craft need, and the plant configuration state it depends on, each sourced from the system that owns it. On top of that sits one engine answering one question continuously, which of the ready jobs can actually start right now, and which single clearance release frees the most downstream work.

Get this into the scope document before pricing. A vendor who quotes a schedule viewer is not underquoting the same product, they are quoting a different one, and the gap will surface in the first outage rather than in acceptance testing.

What goes wrong when you try to get the data out of the source systems?

The clearance and tagging system, the radiation protection system holding permits and dose, the access authorisation and qualification system, the work management system of record and the scheduling product are each owned by a different organisation at your station, each with its own change process and its own view on who may read what. Getting read access to all five is not a technical task. It is five separate negotiations, each with a lead time, and it is the single most common reason these projects slip.

Then the identifiers disagree. A person exists in the access system under a badge number, in the qualification system under a training identifier, and on a craft roster under a name. A component exists in work management under an equipment identifier and in the clearance system under a tag point that maps to it only through somebody's knowledge. A work order in the scheduling product carries an activity code that relates to the work management number through a convention rather than a field. Reconciling those mappings is real work and it has to be done with people who hold the institutional knowledge, not inferred from data.

The sequencing that works is to start the five access conversations in week one, before design is complete, and to treat identifier reconciliation as a named deliverable with a station owner rather than as part of integration. Then pilot on one department and one outage window, because the mapping problems that survive design will surface there at a scale you can fix, rather than station wide during an actual outage.

Why do the work management and scheduling integrations break after launch?

Because both source systems change underneath you in ways that are normal for them and destructive for a layer built on top. The scheduling product gets republished on a cadence, and a republish can renumber activities, change durations wholesale and drop activities that were logically superseded. If your constraint model keyed itself to activity identifiers, the model detaches from the schedule on the first republish and the field sees stale readiness answers with no error anywhere.

The work management system moves work orders through states that mean specific things in your station's procedure and nothing generic. A work order that goes to a hold state for planning revision is not the same as one held for parts, and a system that treats both as not ready will produce a readiness answer that experienced planners immediately recognise as wrong, which is fatal for adoption. They will use it twice and stop.

The way to survive both is to key the constraint model to the work order number, which is stable, rather than to a schedule activity, and to carry the schedule relationship as an association that can be rebuilt on every republish. Then map the work order states explicitly with your planning organisation, including the ones that only exist by local convention, and make unmapped states an exception that surfaces rather than a default that assumes.

What happens when the quality assurance and cyber security scope is not covered?

This is the gap that turns a good project into a stalled one, and it is almost always a scoping failure rather than a technical one. A station applies software controls that ordinary commercial projects do not, and even a non safety related application carries documentation, verification and configuration management obligations that your quality assurance organisation defines. Separately, anything reading plant systems goes through a cyber security architecture review with real duration and real ability to change the design.

What goes wrong is that both are treated as approvals to obtain at the end. They are not approvals, they are requirements that shape the build, and discovering them in month six means reworking documentation, verification evidence and sometimes the network architecture that the whole read path depends on.

There is a third determination sitting above both. Whether any part of the scope touches the licensing basis is a question for your licensing organisation, not for a software vendor, and it changes the project fundamentally if the answer is yes. It must be asked and answered before scoping, in writing.

The practical fix costs nothing. In week one, ask your quality assurance organisation what software quality requirements apply to a non safety related application at your station, ask your cyber security group to scope the architecture review, and ask licensing for a written determination on the proposed scope. Build the project plan around those three answers. Stations that do this ship. Stations that discover the answers late do not.

Should you build custom or configure what you already own?

Do not build a replacement for your work management system of record under any circumstances, and be sceptical of anyone who suggests it. Hitachi Energy Asset Suite and IBM Maximo hold the work order record for good reasons and the migration risk is wildly disproportionate to any benefit. The same applies to Oracle Primavera P6: it models activities, durations, logic and resources competently and your scheduling discipline is built around it. Replacing it buys you nothing and costs you your planners.

If your station runs short outages with a largely permanent workforce and your existing scheduling discipline is producing outcomes you are satisfied with, do not build at all. Configure what you have and spend the money elsewhere. The build case is not universal in this sector and we will say so.

The build is a layer, and only a layer. It reads from the systems of record, models the constraints they do not carry, and answers the readiness question continuously. Build it when your outages routinely lose time to crews arriving at jobs that cannot start, when emergent work reordering is managed verbally while the field works from printed schedules, when qualification and access constraints are discovered at shift turnover rather than during planning, or when nobody can explain after an outage where the duration actually went. Multi unit fleets have a fifth reason, which is that outage performance is not comparable across stations on any common basis.

How do hidden costs get into the quote?

Five specific to this environment. Quality assurance documentation and verification, which is a genuine workstream and not a paperwork tax, and which most commercial developers have never produced. Cyber security architecture review, which has a duration set by your organisation rather than by the project.

Integration access, covered above, which is five negotiations with five owners and is almost never in a fixed price. Identifier reconciliation across those five systems, which is knowledge work with your own people and cannot be done by a developer alone.

And offline behaviour in the field. A plant environment has poor connectivity, gloved hands and areas where a device cannot go, and the difference between a responsive web page and something a craft supervisor will actually use at two in the morning in a containment is design work that quotes routinely omit.

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

Whether the system surfaces conflicts to a named human or tries to resolve them. If a clearance order and a radiation work permit disagree about a job's readiness, the correct behaviour is to raise it to the person with authority, not to apply a rule. A developer who describes an automatic resolution has misunderstood where authority sits in a nuclear station, and the first time the system quietly resolves something it should not have, the station will stop trusting all of its output.

Second, whether the field view is genuinely current. The value is in the gap between a discovery in the plant and the affected crews knowing about it. Most stations manage emergent work well in terms of decision quality and poorly in terms of decision speed, and the recoverable time sits entirely in that delay. If the system republishes on the same cadence as the printed schedule, it has not addressed the problem.

Third, post outage forensics. An immutable record of what was planned, what changed, when and on whose decision is what stops the next outage plan being built from the last plan plus optimism. It is cheap to build during the project and impossible to reconstruct afterwards.

Fourth, ownership. You should own the repository, the infrastructure and the integration configurations, agreed in writing before kickoff. At Digital Heroes the client owns everything from the first commit. In a regulated environment that ownership is what allows your own organisation to audit, control and verify what is running, and a vendor hosting the system on their accounts is creating a configuration control problem your quality organisation will eventually have to solve.