Skip to main content
All white papers
Turnaround execution

Discovery work: keeping scope growth honest and recorded

2026-09-03 · 8 min read · By Kash Mohammed, President

Key takeaways

  1. 01Discovery work is scope that could not be known until the equipment was opened, and it deserves its own record with evidence, an approval, and a cost line.
  2. 02Approve discovery work inside the shift with a short recorded workflow, because a decision that waits for the morning meeting costs a day of critical path.
  3. 03Tag every discovery item with the reason it was not in the plan, so the post-event review can separate true discovery from inspection scope that was missed.
  4. 04Tie each item to the asset and the suspected damage mechanism, not to the job folder, so the next planning cycle and the next RBI inherit it.

Every turnaround has a work list that grows once the equipment is open. Some of that growth is unavoidable: a bundle fails the hydrotest after cleaning, a floor shows pitting under a coating nobody had lifted in twelve years. Some of it is not: a leaking valve everyone knew about, a "while you are in there" from operations, a rework of a weld that failed RT. All of it lands on the same crews, the same cranes, and the same critical path. The difference between a turnaround that closes near plan and one that overruns by weeks is rarely the volume of discovery. It is whether each item was recorded, classified, approved, and costed as it happened, or reconstructed from whiteboards and text messages afterward.

What counts as discovery work in a turnaround?

Discovery work, also called found work or emergent work, is scope that could not reasonably have been identified until the equipment was opened, cleaned, or inspected. The test is knowability before the window, not surprise during it. Typical examples:

  • A shell-and-tube bundle that passes visual but fails the test-ring hydrotest after hydroblasting, exposing tube-to-tubesheet leaks.
  • Pitting on a vessel floor or a tank bottom under a coating that was intact from the outside.
  • Weld indications on radiography of a nozzle that was in the inspection scope but had never shown a defect.
  • Cracking on tray support rings, downcomer welds, or internal attachments visible only after the trays are pulled.
  • Refractory or lining damage found after the manway is opened.

Three other categories arrive through the same door and need to be kept apart:

  • Missed scope. Work that was detectable before the event through on-stream inspection or a walkdown but was not inspected or not carried into the plan.
  • Operations requests. Work operations wants done while the unit is down, unrelated to any finding.
  • Rework. Correction of work performed during the event itself.

Each has a different owner and a different lesson. Lumping them together under "additional work" is how the post-event review ends with nobody responsible for anything.

Why does discovery work blow the schedule and the budget?

Discovery arrives at the worst possible moment. It is found mid-window, usually on equipment that is already on or near the critical path, and it is estimated in a hurry by people whose attention is already committed. It competes for the same fitters, welders, NDT technicians, cranes, and permits as the planned work. Materials may have lead times longer than the remaining window. And the approvals run through the area lead, the turnaround manager, and the integrity engineer, all of whom are saturated.

The record problem compounds the operational one. On many sites, found work is captured on a whiteboard in the field office, in the daily progress report as a sentence, and in a contractor's timesheet as hours against a generic code. By the last week, nobody can say how many hours went to discovery versus plan, which items were approved by whom, or which deferred items now carry a new inspection date. The cost reconciliation becomes an argument rather than a report. Scope growth is consistently named in industry post-event reviews as a leading driver of overruns, and the sites that manage it best are not the ones with less discovery. They are the ones whose discovery is visible while the event is still running.

What should a discovery work record carry?

Treat discovery as a record type, not a note. The minimum fields, set up before the event so nobody is designing forms at 02:00:

  • Asset node and component. The exchanger, the tube bundle, the nozzle, the weld. Never just the job number.
  • Origin. Who found it, when, and through which inspection activity or work step.
  • Evidence. Photos bound to the component at capture, the UT readings or RT report reference, and the NDT technician's identity.
  • Suspected damage mechanism. Thinning, cracking, erosion, under-deposit corrosion. This is the field the RBI will consume later.
  • Proposed disposition and alternatives. Repair now, temporary repair, defer with a fitness-for-service case, or replace.
  • Estimate. Hours by craft, materials, equipment, and the earliest start given lead times.
  • Critical path impact. Whether the item extends the window, and by how much.
  • Reason code. Why it was not in the plan (covered below).
  • Approval chain. Recorded transitions with identity and timestamp.
  • Cost entry and delay event. Filled once the work is done or the schedule moves.

If the record carries these fields as structured data, the review at the end of the event is a query. If it carries them as prose in a daily report, the review is a reading assignment nobody finishes.

How do you approve discovery work without stalling the shift?

The approval that waits for the 07:00 meeting costs a shift of critical path. The approval that happens by phone with no record costs the audit trail. The workable middle is a short workflow with thresholds set before the event:

  • Below an agreed hours and cost threshold, the area lead approves in the field.
  • Above it, the turnaround manager approves, with the estimate and evidence in front of them.
  • Anything that changes a design basis (thickness, MAWP, material, a rerate) or that defers a finding on a pressure boundary goes through the integrity engineer, whatever the cost.

Every disposition should be a recorded state transition: submitted, under review, approved, rejected, on hold, and owner sign-off at completion. Rejections matter as much as approvals. "We decided not to repair it this event" is an integrity decision, and it needs the engineer's name, the reasoning, and the new inspection date attached. Approvers should be able to act from a tablet, seeing the photo and the readings, rather than from a verbal description relayed through two people.

How do you tell real discovery from scope that planning missed?

Require a reason code at the moment the item is raised, while the person who found it still knows the answer:

  • Not detectable before opening. True discovery.
  • Detectable but not inspected. An on-stream inspection or interval gap.
  • Known but deprioritized. A planning decision that did not hold.
  • Operations request. Unrelated to a finding.
  • Design or process change. New scope by decision.

After the event, the distribution of these codes is the most useful chart in the review. A high share of "not detectable" is the nature of the equipment and argues for contingency. A high share of "detectable but not inspected" means the on-stream program is thin and the fix is between turnarounds, not inside them. A high share of "known but deprioritized" is a planning discipline problem. Without the code, all of it looks like bad luck.

Carry the history forward. The discovery hours per equipment type from the last three events at the same site is a far better contingency basis than an industry rule of thumb, and it is only available if discovery was recorded as a category each time.

What does the post-event review need from discovery records?

The review is where the recording pays for itself. It needs, per event and per unit:

  • Discovery hours and cost against plan, split by reason code and by equipment type.
  • Time from raise to approval, and the items where the approval waited.
  • Delay events attributed to discovery, with the critical path impact.
  • Items deferred, each with its integrity justification and its new inspection date.
  • Findings that changed the asset's damage mechanism record or its corrosion rate.
  • Assets where discovery has recurred across events.

The last two feed the integrity program directly. A recurring exchanger bundle failure is an RBI input. A cracking mechanism found on tray supports changes what the next internal inspection looks for. If those findings stay in the turnaround report, the inspection planner for the next cycle starts from the previous inspection, not from what was actually seen. The full turnaround planning picture is on the intelliPROJECTS page.

How intelliSPEC handles it

intelliPROJECTS models the event with its own record types: event, activity, crew, daily progress, delay event, gate review, and cost entry. Discovery work raised in the field is an activity against the asset node, with photos and readings attached at capture. The field app works fully offline with no time limit on the local store, so an item raised inside a column with no signal is recorded the same as one raised in the field office.

Dispositions use the platform's workflow transitions (submit, approve, reject, hold, resume, reopen, and owner sign-off), each carrying the identity of the person who acted. The hash-chained audit trail records every create, update, and approval with actor, timestamp, and request context, and audit events are never auto-deleted, so the question of who approved a deferral has a durable answer. Cost entries and delay events link back to the activity that caused them.

Because the platform is metadata-driven, a tenant adds its own reason codes and approval thresholds through the form designer rather than through a change request. Findings flow to intelliINSPECT on the asset record, and suspected damage mechanisms are first-class records in intelliINTEGRITY where the API 580/581 semi-quantitative RBI scoring reads them. The completed record pins the form configuration it was executed with, so the discovery item from this event renders the same way when the next planner opens it.

Questions this paper answers

Questions this paper answers

What is discovery work in a turnaround?

Discovery work, also called found work or emergent work, is repair or inspection scope that could not reasonably be identified until the equipment was opened, cleaned, or inspected during the event. It is distinct from scope that was missed in planning and from requests added by operations during the window.

How much contingency should a turnaround carry for discovery work?

There is no universal figure. The defensible method is to use your own history: the discovery hours and cost per equipment type from previous events at the same site. That requires discovery items to have been recorded as a category, which is the point of keeping them honest.

Who should approve discovery work during a turnaround?

Set thresholds in advance. Small items go to the area lead, larger items to the turnaround manager, and anything that changes design pressure, thickness basis, or requires a rerate goes through the integrity engineer. Every approval and every rejection should be a recorded transition with the approver's identity.

How do you tell discovery work from missed scope?

Require a reason code when the item is raised: not detectable before opening, detectable but not inspected, known but deprioritized, operations request, or design change. The distribution of those codes after the event tells you whether the problem is the equipment or the planning.

Where should discovery findings end up after the turnaround?

On the asset record, not in the event folder. Findings update the inspection history, suspected damage mechanisms update the RBI inputs, and deferred items carry a new inspection date. If the record lives only in the turnaround report, the next planner starts from zero.