Running a refinery turnaround in Dynamics 365

A turnaround is the largest, most expensive and most tightly constrained thing a process plant does. The unit comes down on a fixed date, several thousand discrete jobs have to happen in a defined order, most of the people doing them do not work for you, and every day of overrun has a number attached that everyone in the room knows.

It is also the piece of work most likely to be run on a scheduling tool that nobody else in the business can see into, with cost reconciled weeks after the unit is back up.

This article covers how a turnaround maps onto Dynamics 365 Project Operations and Field Service, where the standard scheduling engine runs out of road, and what we have learned building this at refinery scale.

Why a turnaround breaks ordinary project tooling

Most project software assumes a project that finishes when it finishes. A turnaround assumes the opposite: the end date is the fixed point and everything else negotiates around it.

Three properties follow from that, and each one breaks a different assumption in standard tooling.

Volume. A mid-size unit turnaround is thousands of tasks. A full refinery turnaround is tens of thousands. Tools that are pleasant at two hundred tasks behave very differently at eight thousand, and the difference does not show up in a demo.

Dependency density. Scaffolding before insulation before the blind before the inspection before the reinstatement. These are not decorative links; the schedule is the dependency graph, and a change to one task’s duration has to propagate through everything downstream in seconds, not overnight.

Found work. You open a vessel and discover something that is not in the plan. Found work is not an exception on a turnaround, it is a category, and it can be a third of the scope. A system that cannot absorb new work, price it, schedule it and get it approved inside a shift is a system that gets abandoned in week two and replaced by a spreadsheet.

The shape that works

The structure we use puts the financial container and the execution record in different places, deliberately.

• Portfolio and programme hold the turnaround as a whole, so the plant can see all of it and roll cost up without exporting anything.
• The project is the financial container. It carries the budget, the contract, the pricing rules and the cost actuals.
• The work breakdown structure carries the plan: tasks, durations, dependencies, resource assignments.
• Work orders are what a crew actually receives, tied to a functional location and to equipment, carrying tasks, safety steps and the permit.

Because Field Service and Project Operations are now natively connected, a project task can become a work order directly, and the cost of that work order flows back to the project rather than into a separate service ledger. We covered the mechanics of that integration in a previous article.

The practical consequence for a turnaround manager is that the daily question — “what did yesterday cost us and are we still going to make the date” — is answerable from one place, by looking, rather than by asking four people to send spreadsheets.

Where the standard scheduling engine runs out

This is the part most articles skip, so it is worth being specific.

Project Operations schedules through Microsoft Project for the Web by default. That engine is capable and well integrated, and for the large majority of professional services projects it is the right answer. At turnaround volume, with turnaround dependency density, it becomes the constraint.

Microsoft’s answer is a documented alternative. External scheduling mode lets you, in Microsoft’s words, “natively create, update, and delete data in tables that are related to work breakdown structures (WBSs), but without the current limits that Microsoft Project for the Web enforces”. Microsoft is equally clear about who it is for: customers who have the tools to define a WBS outside Project Operations’ own scheduling logic, or who need to manage schedule hierarchy, dependencies or task duration themselves.

That is the door. Going through it has consequences, and they are worth knowing before you commit:

• It is one-way. Microsoft’s documentation is blunt: “After you set this mode for a project, you can’t change it.” Decide per project, at creation.
• You now own the data model. Tasks, team members, resource assignments and dependencies all have to be written correctly by you. Get it wrong and the reconciliation, estimates, tracking and assignment grids may simply not render.
• Contours do not build themselves. Resource assignments no longer populate the planned-work column that stores time-phased effort. If you want effort, cost and sales-price contours to calculate, you write them, in the exact format the platform expects. This is the single most underestimated piece of work in an external scheduling implementation, and we wrote a three-part series on doing it.
• There is a hard import ceiling elsewhere. When importing quote or contract line details from a project, Microsoft documents a maximum of 500 tasks in the WBS, based on a limit of 20 assignments per task. On a turnaround you will pass 500 tasks in the first afternoon, so the commercial structure has to be designed around that rather than into it.
• Some conveniences go. Copilot task, risk and issue generation is unavailable on externally scheduled projects, and moving a project’s start date does not move its tasks.

None of this is a reason to avoid external scheduling for turnaround work. It is a reason to go in with the trade-off written down, because the decision is irreversible per project and the contour work is real engineering rather than configuration.

Contractor cost, before it becomes an invoice

On most turnarounds the majority of labour is contract labour, and the majority of cost surprises live there. The pattern that removes them is unglamorous: contractor time and materials are booked against the work order, the work order belongs to a project, and the project’s pricing rules turn hours into cost at approval time rather than at invoice time.

The effect is that a disputed line is disputed on the day, by the supervisor who was standing there, instead of six weeks later by a cost engineer with a PDF. The plant also gets a running commitment position instead of a retrospective one.

This is the single clearest return on doing turnaround work in an integrated system, and it is worth building for even if nothing else on this list applies to you.

The field half

A turnaround schedule is only as honest as the completion data feeding it, which means the field experience decides whether the whole thing works.

Permits. A permit to work that lives in a separate system is a permit that gets worked around. Held as its own record, linked to the work order and the functional location, it carries its type, issuing authority, expiry and state, and the mobile app can refuse to proceed against an expired one. The permit board stops being a physical board.

Offline. Plants have areas with no signal, and a turnaround puts crews in exactly those areas. Work has to be readable, completable and signable with no connection, and sync when the technician walks back into coverage.

Functional location and equipment. Every job carries one or both. This sounds like a data-quality nicety until someone tries to find every job on a particular train, or work out which vessel a finding belongs to, in the third week.

Found work, raised where it is found. A technician who discovers something should be able to raise it against the equipment, on the spot, with a photograph. That record then needs a route to being scoped, priced, scheduled and approved that takes hours rather than days. Design this path first. It is the one that decides whether the system survives the turnaround.

Daily, not at the post-mortem

The measure of whether any of this has worked is simple. On the morning of day nine, can the turnaround manager see percentage complete by area, cost against budget, the critical path as it now stands and the found-work backlog, without anyone having prepared anything?

If the answer is yes, the arguments in the morning meeting are about the plant. If the answer is no, they are about whose spreadsheet is right.

Where we come in

We are a Microsoft partner, and our current work is a maintenance and turnaround management programme for one of the largest refiners in the United States: portfolio and programme structures for capital and maintenance work, the notification-to-work-order chain, functional location and equipment rules, electronic permits, shift and calendar templates for round-the-clock operations, contractor cost flowing into project pricing, and scheduling performance at a scale where the standard engine needed replacing.

That last piece is why we wrote the external scheduling engine series. It is not theory.

If you are planning a turnaround and the systems question is still open, talk to us. We will tell you honestly which parts of this are configuration, which parts are engineering, and roughly what each costs.

Related reading: Field Service and Project Operations, natively connected, and our energy, oil and gas practice.

Sources

• Microsoft Learn: External scheduling (mode, limitations, contours, 500-task import limit)
• Microsoft Learn: Create a work breakdown structure
• Microsoft Learn: Schedule a project with a work breakdown structure
• Microsoft Learn: Create functional locations in Dynamics 365 Field Service
• Microsoft Learn: Project Operations and Field Service integration
• Microsoft Learn: Integration reference architecture