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

Why does the scope register keep growing after the worklist freeze?

Between the freeze and the day the plant comes down, the list grows, and every added item is defensible on its own. Someone raises a notification for a valve they have wanted replaced for three years. Operations adds a modification. Engineering adds a tie in for a project that has not been sanctioned. Then the same item reappears three weeks after it was rejected, under a new notification number, because the outcome of the challenge meeting attached to the meeting and not to the item.

This is specific to turnarounds because the currency is a fixed window rather than a budget line. An extra four hundred hours on a normal maintenance plan is absorbed. In a shutdown it either consumes float on the critical path or it consumes crews you needed somewhere else, and by the time the growth is visible in the hour count it is too late to resource it.

The fix: make the scope item a durable record with a state machine, not a spreadsheet row. Raised, challenged, accepted, deferred with a named acceptor and a target event, or rejected with a reason. Detect duplicates on equipment tag and work description before an item reaches a meeting, so a rejected job cannot return wearing a new number. Carry the estimate, the discipline mix, the shutdown justification and the acceptor on every accepted item. Growth then becomes visible and attributable while there is still time to act, which is the point. The purpose is not to block scope, it is to stop discovering it in week two.

What goes wrong with equipment tag data and historical estimates?

Two data problems sink turnaround builds and neither is a software problem. The first is that the equipment tag is not the same string in the maintenance system, in the schedule and on the drawing. Tags carry different prefixes, different level separators, and in older plants two tags for what is physically one exchanger after a replacement in 2009. Any function that depends on joining across systems, duplicate detection, history lookup, readiness rollup, quietly degrades because the join misses.

The second is that the estimating history from previous events is either gone or unusable. Actual hours were captured against cost codes rather than against jobs, so nobody can say what a comparable exchanger bundle pull actually took on this site. Every estimate therefore starts from an experienced person's memory, which is better than nothing and worse than data, and it is why the same job is estimated differently by two planners in the same week.

The fix: treat tag reconciliation as a funded workstream before the build, with an owner who can decide which system is authoritative and who maintains the alias map as tags change. Capture actual hours against the job and the discipline from the first event the system runs, even if that first event produces no benefit, because event two is where the payback starts. Where history exists in old timesheets, load it and mark its confidence rather than pretending it is clean.

Why do the Primavera and maintenance system integrations break after launch?

They break because they were built as an import rather than as a relationship. Reading an XER export once is straightforward. Maintaining a live map between scope item, work order and schedule activity while a scheduler is actively editing the file is a different exercise, and it is the one that fails in week one of the event.

The specific failure modes are predictable. The scheduler has the file checked out, so the sync window closes. An activity is deleted and recreated with a new identifier, so the mapping to the scope item is orphaned and the progress posted against it disappears from the forecast. Discovery work is added directly in the schedule by a planner under pressure, so it exists in Primavera P6 and not in the register, and the two hour counts diverge by the day. On the maintenance side, work order status changes made in the field system do not flow back, so the register shows jobs open that were completed yesterday.

The fix: define the direction of authority per field before anything is coded. The register owns scope, estimates and readiness. The schedule owns logic, dates and sequence. Field capture owns progress. Sync on stable identifiers rather than activity codes, and detect an orphaned mapping as an exception with an owner rather than dropping it silently. Agree the conflict rule and the behaviour when the file is locked, in writing, and rehearse both during a small shutdown before the event that matters.

What happens when permit and isolation readiness is not covered?

A crew cannot start until the permit is available, the isolation is hung and verified, the blind list is signed, the scaffold is built and tagged, the material is staged at the right laydown, the tooling is booked, and where it is code work the procedure and a qualified welder are both available. Any one of those missing puts eight people on standby. Multiply by concurrent fronts and standing time becomes the largest controllable loss in the event.

Most sites manage this with a spreadsheet per discipline maintained by a coordinator. It is accurate when it is saved and wrong an hour later, and it records a claim rather than a fact. Nobody is lying. The coordinator was told the scaffold was up.

The fix: make readiness a computed state. Each work pack carries its prerequisites as records with owners, statuses and timestamps, and the system publishes a rolling look ahead of jobs scheduled to start in the next forty eight hours that are not ready, sorted by float. That one screen changes the morning meeting from a status recital into a decision meeting, because it names the blocker and the person who owns it rather than the job. Permit and isolation state should be read from the systems that own them rather than retyped, and where the permit system cannot be integrated, the manual entry needs a timestamp and a named person so its age is visible.

Should you build custom or configure what you already own?

If your shutdowns are short, largely repeatable and executed by a stable in house crew who know the work, do not build. Primavera P6 plus a disciplined worklist and a good coordinator is genuinely sufficient at that scale, and a custom system becomes overhead somebody has to maintain between events.

If you are a heavy SAP site and your process resembles the workflow it ships with, configure Prometheus Group STO rather than building. It is purpose built for shutdowns and tightly bound to SAP, which is a real advantage when that is your estate. On the cost side, Hexagon EcoSys and Cleopatra Enterprise are serious estimating and cost control tools, and if your cost breakdown structure is clean they will forecast properly. None of this should be rebuilt.

Above all, do not replace P6. It is the right scheduling engine and a custom layer belongs alongside it. Build when your events run past roughly forty thousand contractor hours, when discovery work routinely takes more than a day to move from found to working, when your scope register and your schedule are reconciled by a human, or when you cannot say at any moment how many crews are standing and why.

How do hidden costs get into the quote?

Five items reliably land after signature. Integration depth with Primavera, because a quote priced against reading an export is a different project from maintaining a live bidirectional map against a file under active edit. SAP work order and project system integration, which is its own workstream with its own transports and its own approvals on your side. Contractor timesheet reconciliation, since every contract carries different rates, shift premiums, travel rules and minimum call outs, and each variation is real work. Offline mobile capture, which roughly doubles the testing burden and is not optional inside a plant where reception fails under a pipe rack. And tag reconciliation, which is usually assumed to be a data import and is actually a decision programme.

The fix: ask for the integration priced separately from the application, and ask what the number becomes for a second contractor rate structure and a second site with different level naming. Ask who on your side owns tag reconciliation and how many hours a week that assumes. Then insist the first release runs on a single unit or a small shutdown with two contractors rather than fifteen, because scope discipline in the build is the same skill as scope discipline in the event.

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

Ask the team to model the objects on a whiteboard before you sign. Scope item, work order, schedule activity, work pack and readiness prerequisite are five things with five lifecycles. A developer who collapses them into tasks and subtasks has built a project tracker and will discover the difference during your event, in front of eleven hundred contractors.

Ask whether they know what a blind list is, what an isolation certificate does to a start date, and what rules of credit are. You are testing whether they have stood in a turnaround control room, because everything genuinely hard here is domain knowledge rather than code. Ask how progress is captured, and accept only verifiable steps with rules of credit agreed before the event rather than percent complete, which is an opinion and under commercial pressure a generous one. Ask about offline behaviour, since a system that needs connectivity inside a vessel will not be used and you will end up back on marked up sheets with an expensive system running in the background.

Then go live at least one full event cycle early, shaken out on a small shutdown first. Going live during a major turnaround is the single most common way these projects fail, because the people who would normally absorb teething problems are the busiest people on site. Settle ownership before kickoff too: the repository, the cloud accounts and the right to hire anyone else. Your productivity history across events is the most commercially valuable data your maintenance organisation produces, and it should not sit in a developer's account.