Turnaround and Shutdown Management Software: Why a Discovery Job Wrecks the Critical Path Before Anyone Can See It

Why a turnaround is a different animal from every other project you run

Day nine of a twenty eight day refinery turnaround. A vessel comes open and the inspector finds wall loss beyond what the last inspection predicted. That is another four hundred hours of work, a specialist welding crew, material that is not on site, and a hold point for radiography. The turnaround manager asks the only question that matters: what does this do to steam out and start up, and what does it do to the forecast. The scheduler says he will have an answer for the morning meeting. Meanwhile eleven hundred contractors are on site burning money by the hour and three crews are standing at a gate because the isolation they need has not been hung.

A turnaround compresses a year of maintenance into a few weeks with a workforce that is mostly not yours and mostly not permanent. Everything you tolerate on a normal project becomes intolerable here, because the feedback loop is measured in hours. A week of drift is the whole margin, and the plant either restarts on the date the commercial team sold or it does not.

The tooling around this is almost always three systems and a lot of paper. Scope lives in the maintenance system as notifications and work orders. The schedule lives in Primavera P6. Cost lives in a spreadsheet or in a controls tool that gets updated weekly. Daily field progress arrives as a bundle of marked up sheets handed to a planner at six in the morning. The turnaround manager is the integration layer.

Problem 1: scope challenge is a meeting, and meetings do not scale

Worklists grow. 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. Between the initial worklist freeze and the day the plant comes down, the list typically multiplies, and every added item is defensible in isolation.

Scope challenge is the discipline of making each item justify itself against a written test: is it a genuine shutdown job, could it be done online, what is the consequence of deferring to the next event, and who accepts that risk. Most sites run this as a series of meetings with a spreadsheet on a projector. The problem is not the meeting, it is that the outcome of the meeting does not stick to the item. Three weeks later the item is back on the list under a different notification number and nobody remembers it was rejected.

What a custom build does: the scope item becomes a durable object with a state machine. Raised, challenged, accepted, deferred with a named acceptor and a target event, or rejected with a reason. Duplicates get detected on equipment tag and work description before they reach a meeting. Every accepted item carries its estimate, its discipline mix, its shutdown reason and the person who accepted it. When someone asks in the review why the event grew by 30 percent, the answer is a report rather than an argument.

Problem 2: the schedule and the cost forecast are different universes

P6 holds activities with logic and resources. Your cost tool holds a cost breakdown structure that does not map one to one onto those activities, because cost is organised by contract and discipline while the schedule is organised by unit and system. So a scope change updates one of them, promptly, and the other one catches up at the weekly report.

This is where the incumbents genuinely help and also where they stop. Oracle Primavera P6 is the right scheduling engine and nobody should be trying to replace it. Hexagon EcoSys and Cleopatra Enterprise are serious cost control and estimating tools, and if your cost breakdown is clean they will forecast well. Prometheus Group STO is purpose built for shutdowns and is tightly bound to SAP, which is a real advantage when you are an SAP site and a real constraint when your estimating, contracting and progress capture do not look like the workflow it ships with.

What a custom build does: it does not replace P6. It owns the scope register and the field data, and it keeps a bidirectional map between scope item, work order, and schedule activity so that a change in one place is visible in the other within minutes rather than at the next import. Cost is derived from the same objects: estimated hours by discipline on the scope item, actual hours from field capture, contractor rates from the contract, so the forecast at completion is computed from what is happening rather than typed from what someone believes.

Problem 3: work pack readiness is a checklist nobody can see

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

Most sites manage readiness with a spreadsheet per discipline updated by a coordinator. It is accurate at the moment it is saved and wrong an hour later.

What a custom build does: readiness becomes a computed state, not a manual claim. Each work pack has its prerequisites as records with owners and statuses, and the system publishes a rolling look ahead of jobs that are scheduled to start in the next 48 hours but are not ready, sorted by how much float they have. That single screen, in our experience, 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.

Problem 4: field progress is a fiction until you capture it at the front

Foremen report percent complete. Percent complete is an opinion, and under commercial pressure it is a generous one. Progress collected as a percentage means earned value curves that look healthy until day nineteen, when they abruptly do not.

What a custom build does: progress by verifiable steps rather than percentage. A heat exchanger job is not 60 percent done, it has had its blinds installed, been broken out, been pulled, and is at the cleaner. Each of those is a binary someone can see. Rules of credit assign the earned hours per step and they are agreed before the event, not argued during it. Capture happens on a phone or tablet at the front, offline capable because reception inside a plant is unreliable and a system that requires connectivity will simply not be used. The same capture records crew size and hours, which gives you actual productivity per contractor per discipline while there is still time to act on it.

Problem 5: discovery work has no fast path

The whole event turns on how quickly discovery work moves from found to working. Today that path is: inspector writes it up, engineer reviews, estimator prices, turnaround manager approves, planner schedules, materials chased, contractor mobilised. Each handover is an email or a corridor conversation, and the elapsed time is a day or two while the equipment sits open.

What a custom build does: a discovery job is raised at the front with photographs and the equipment tag, and it enters a queue with a target response time. Historic similar jobs are surfaced automatically so the estimate starts from what a comparable repair actually took on your site rather than from a guess. Approval is a step with a threshold, so small jobs move without waking the manager and large ones go straight to him with the schedule impact already computed. This is the one place we would use a language model in a turnaround system: reading inspection write-ups and free text notifications to classify the work type and match it to historic jobs. We would not let it schedule anything. Scheduling logic is where judgement lives and an automated resequence during an event is how you lose the trust of every superintendent on site.

What this costs and how long it takes

A first release covering the scope register with challenge workflow, work pack readiness, daily field progress capture with rules of credit, and a live forecast runs $80,000 to $170,000 over 14 to 20 weeks. Time it so that go live is at least one full event cycle before the turnaround, because you want a small shutdown to shake it out. A full platform adding cost integration, contractor productivity and LEM reconciliation, materials and tooling readiness, permit and isolation linkage, scenario comparison and post-event benchmarking runs $220,000 to $550,000 over 8 to 14 months.

What drives cost up here: P6 integration depth, because reading an XER export is straightforward and maintaining a live bidirectional relationship with a schedule that a scheduler is actively editing is not. SAP work order and project system integration, which is its own workstream with its own transports. Contractor timesheet reconciliation, because every contract has different rates, shift premiums and travel rules and each is real work. Offline mobile capture, which doubles the testing burden but is not optional in a plant. What keeps cost down: run the first version on a single unit or a single small shutdown, with two contractors rather than fifteen.

Build versus buy, honestly

Buy if your shutdowns are short, largely repeatable, and executed by a stable in-house crew who know the work. P6 plus a well run worklist and a good coordinator is genuinely sufficient and a custom system would be overhead. Buy Prometheus if you are a heavy SAP site whose process is close to the workflow it ships and you would rather adapt your process than build one.

Build when two or more of these are true. Your events exceed roughly 40,000 contractor hours. Discovery work routinely takes more than a day to move from found to working. Your scope register and your schedule are reconciled by a human. You cannot answer, at any moment on any day, how many crews are standing and why. Or you run several sites and want the next event to start from the last event's actual productivity rather than from an estimator's memory.

How to choose a developer for turnaround software

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

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 hard in this build is domain knowledge rather than code.

Ask specifically how they will handle P6. Which direction, at what frequency, what happens when the scheduler has the file open, and what the conflict rule is. A vague answer here becomes your worst week.

Ask about offline. If field capture needs connectivity inside a vessel or under a pipe rack it will not be used, and you will end up back on marked up sheets with a more expensive system in the background.

Ask who owns the code and the infrastructure, and get it in the contract before kickoff. At Digital Heroes you own the repository and the cloud accounts from the first commit and can hire anyone to continue the work. A turnaround system holds your productivity history across events, which is the most commercially valuable data your maintenance organisation produces. It should not sit in somebody else's account.