How to Run a Multi-Site Shutdown or Turnaround Without Ten Disconnected Spreadsheets

A turnaround is the hardest test of how well your systems work together. For a few days or weeks, a site takes assets offline, brings in extra contractors, consumes a long list of materials, and works under permits that expire by the hour. Now add several sites with overlapping windows and shared specialist crews, and the plan is no longer in one place. It is in ten.

The scope lives in the CMMS. Purchase orders sit in the ERP or a procurement tool. The schedule is a file from a project scheduling application, or an export of one. Permits are in the HSE system, contractor certificates are in a portal or a shared folder, and the real decisions happen in a messaging group. Each source is accurate on its own terms. Together they disagree, and nobody finds out until a crew is standing at a valve with no isolation, waiting for a gasket that was never received.

This guide covers turnaround planning and plant shutdown coordination across multiple sites: why plans fragment, how to diagnose it, what it costs, and a sequence of steps that surfaces delays weeks ahead instead of on the day. Near the end, we explain where The Ninjaz Group fits, and where it does not.

Why shutdown plans fragment

Maintenance outage planning fragments for a simple reason: each function adopts the tool that fits its own job, and nobody owns the joins between them.

Maintenance planners build scope in the CMMS because that is where work orders and asset history live. Procurement works in the ERP because that is where commitments and budgets are recorded. Project controllers build the critical path in a scheduling tool because the CMMS cannot model dependencies well. Safety teams manage permits and risk assessments in an HSE system. Contractor onboarding sits with whoever manages vendors. Then everyone uses messaging, because the other tools are too slow for the question that matters this afternoon.

The result is the same fact stored in several places with different values. A work order has one planned start in the CMMS and another in the schedule. A part is "on order" in procurement and "required" in the work package, yet nobody has checked whether the delivery date falls before the task date. A contractor is approved on one list and holds an expired certificate on another.

Manual reconciliation hides this for a while. A planner exports, pastes and emails an updated spreadsheet every Friday. That works for one site and one window. It does not survive five sites, a shared pool of specialists and a scope that changes weekly.

How to tell whether your coordination is leaking

You do not need a consultant to find out. Take one turnaround, current or recent, and run these checks:

• Trace ten work orders from the scope to their materials, contractor, permit and scheduled slot. Count how many links you can verify without asking a person.
• Compare the number of work packages in the CMMS with the number of activities in the schedule. Every gap is scope that is either unplanned or unscheduled.
• Check each long-lead item. Does its promised delivery date fall before the task start? Who checked, and when?
• Ask when contractor certificates were last verified against the individual names on the roster, not the company-level approval.
• Ask how long it takes to answer "what is our committed cost against forecast today?" If the answer is "give us until Friday," your data is stale.
• Read the messaging history. If decisions that change scope or dates appear only in chat threads, the systems of record are already wrong.

One failed check is normal. Three or more means the plan is held together by individuals, and individuals take leave, get ill, or burn out in week three.

What it costs when delays are found on the day

Consider an operator with six sites running staggered shutdowns in the same quarter. At Site C, a pump overhaul is scheduled for day four. The CMMS shows a spare seal kit in stock, because the shared warehouse record was never updated after Site A used the last one the week before. Nobody sees this until the crew opens the pump. The fix is an expedited order, a day of idle labour and a rebooked crane, and the crane change pushes two other tasks.

That single miss touches every category of cost:

Time. Idle crews are paid whether or not they work. A slipped critical-path task extends the outage, and every extra day defers production or service.

Inventory. Expedited freight, duplicate purchases and, over time, defensive stock. When planners cannot trust the stock view, they hoard spares at each site, tying up capital in parts another site may need.

Mistakes. Permits issued against an outdated scope, or work started by someone whose certificate lapsed, are safety and compliance exposures, not just scheduling errors.

Burnout. Planners who spend evenings reconciling spreadsheets are not planning; they are copying, and they are the same people on call when the window opens.

Customer frustration. Customers, internal or external, were given a return-to-service date. Each slip weakens trust in the next date, and some will plan around a more reliable supplier.

A planning sequence that surfaces delays early

The goal is not a perfect plan. It is a plan whose weak points become visible early enough to fix.

1. Baseline the scope with one ID per work package. The same ID should appear in the CMMS work order, the schedule activity, the purchase requisition, the contractor assignment and the permit. Route every scope change through one change log.
2. Build a materials readiness list from the scope. For each package, list the parts, reserve them against stock, and mark long-lead items with a required-on-site date set ahead of the task start by an agreed buffer.
3. Qualify contractors by person and by date. Check certifications, inductions and insurance against the shutdown dates, not today's date. A certificate that expires on day six is a day-six problem you can see in week one.
4. Set readiness gates. At fixed points before the window, for example twelve, eight, four and one week out, define measurable criteria: the share of packages with materials ordered, confirmed delivery dates, named crews and draft permits. Gates without numbers become meetings.
5. Link permits and isolations to the schedule. A permit request should be generated from, or at least checked against, the activity it supports, so a date change in one place prompts a review in the other.
6. Track committed and forecast cost weekly by package. Actuals tell you what already went wrong. Commitments and forecasts tell you what is about to.
7. Run one short cross-site review during execution. Exceptions only: what is late, what is blocked, what changed. Record decisions against the work package, not in a thread nobody can search later.

What each system should own

Most turnaround software problems are not missing features. They are unclear ownership. A workable split looks like this:

The CMMS owns scope, asset history and work order status. It is the record of what is being done to which asset. The ERP and procurement tools own commitments, receipts, stock and cost; they answer whether a part is ordered, received and paid for. The scheduling tool owns sequence, dependencies and the critical path. The HSE system owns permits, risk assessments and incident records. Contractor management owns who is approved, for what, until when. Messaging owns conversation, and should not own decisions.

Once ownership is clear, the work is in the links. Each system should carry the work package ID, and changes in the owning system should reach the others without someone retyping them. Where a link cannot be automated yet, name the person responsible and the day of the week it is checked. An honest manual process with an owner beats an assumed integration nobody monitors.

This is where shutdown management software evaluations often go wrong. A new all-in-one tool bought for one turnaround means migrating history, retraining crews and creating an eleventh source of truth. The better question is often how to connect what you already run.

How The Ninjaz Group approaches multi-site shutdown coordination

The Ninjaz Group is a managed-services partner for multi-location enterprises, including energy and industrial companies with field sites. We work in three layers: Managed Transformation (strategy, design, build), Managed Link (the integration layer we build, own and maintain between your existing systems) and Managed Business Operations (managed IT and day-to-day running after go-live).

Engagements start with a Blueprint. We map how the operation actually runs and find where work is done twice, data goes stale and money leaks. For a turnaround, that means following a work package through scope, materials, contractors, permits and cost, and showing where the handoffs break. You keep the map. Build & Link follows with no rip-and-replace; software you have already paid for stays. Then Operate.

The integration hub we deploy and run is the Ninjaz Operating Platform. It connects to systems you already have, including ERP, CMMS, inventory, finance, and channels such as email and WhatsApp. A unified data layer keeps one record per asset and order, so a work order and the spare it needs are not described differently in two places. The Command Center shows live KPIs and alerts across locations, inventory and asset views span sites, and workflow automations can be configured to flag conditions such as a delivery date landing after a task date. Team chat boards tied to records keep a decision attached to the work it affects, with roles and an audit trail behind it.

The limits matter. The platform does not replace your scheduling tool or your planners' judgment. Connections to HSE, procurement or scheduling tools are scoped in the Blueprint, based on what you run. What it provides is one shared view, so exceptions surface while they are still cheap to fix.

Start with one turnaround

You do not need to fix every site at once. Pick the next turnaround, run the diagnostic checks above, and write down where the answers came from a person rather than a system. That list is your first integration backlog, and it is worth having whoever you work with.

If you want help mapping it, book a consultation and we will walk through how a Blueprint would work for your sites. If you would rather see the hub first, take a look at the platform demo.