How to Scope a Turbine Outage

What Outage Scope Means

Outage scope is the set of decisions made before the machine is opened that define what work will be performed during the outage window. It answers three questions:

• What must be done regardless of what is found? — fixed scope
• What will be done only if a defined trigger condition is found? — conditional scope
• What is explicitly not in scope for this outage? — deferred or excluded work

Scope definition is a decision, not a checklist. The difference matters: a checklist is followed regardless of context; a decision is made with specific inputs, against specific criteria, and with documented reasoning. Scope decisions should be traceable — meaning that in two years, when someone looks at the outage record, it should be clear what was decided, on what basis, and by whom.

The Two Categories of Scope Work

Fixed scope

Fixed scope is work that will be executed regardless of what the inspection finds. It is defined in advance based on:

• OEM-specified maintenance intervals — components with defined service lives or inspection intervals that fall within this outage window
• Regulatory or insurance requirements — inspection obligations that must be met for the machine to return to service
• Known findings from the previous outage — items documented as "repair at next outage" that cannot be deferred again
• Running condition data — if bearing temperature has been trending upward for six months, bearing inspection is fixed scope, not conditional

Fixed scope items should be clearly listed, with the basis for their inclusion documented. Adding work to fixed scope is straightforward; removing it requires equally clear justification and sign-off, because removing a fixed scope item means accepting the risk that the underlying reason for its inclusion was wrong.

Conditional scope

Conditional scope is work that will be performed only if a specific finding or measurement triggers it. Defining conditional scope in advance is more disciplined than deciding what to do reactively once the machine is open. A condition scope item has three parts:

• The trigger: what finding, measurement or condition activates this scope item
• The work: what is done if the trigger is met
• The decision maker: who authorises the scope addition if the trigger is met

Inputs to Scope Definition

Good scope definition requires systematic review of the available information before the outage window opens. The minimum inputs are:

Operating history since last outage

Review all condition monitoring data, alarm records and operating events since the previous outage. Look for trends — not just alarms that were acknowledged and forgotten. Vibration that has risen 15% over two years may never have triggered an alarm, but it is meaningful scope input. Temperature trends, oil analysis results and any trips or abnormal events should all be reviewed.

Previous outage findings and decisions

Every "monitor through next operating period" or "defer to next outage" decision made at the last outage becomes mandatory input to this scope definition. These items must be explicitly re-evaluated — not assumed to be fine because nothing went wrong. A finding deferred once is not automatically acceptable to defer again; the evaluation must be repeated with current condition data.

OEM intervals and service bulletins

Check the OEM documentation for any maintenance items that fall due within this outage window. Also check for outstanding service bulletins or technical instructions that have not yet been implemented. These are often missed in scope definition because they require active checking rather than being triggered by a visible symptom.

Regulatory and insurance requirements

Statutory inspection requirements — from pressure vessel authorities, insurance inspectors or grid operators — must be identified and included in fixed scope before any other scoping discussion. Missing a mandatory inspection is not a schedule problem; it is a compliance failure with potential operational consequences.

Common Scoping Errors

Scope defined too narrow to control cost

Defining scope narrowly to limit cost is a legitimate pressure, but it becomes an error when it excludes work that is genuinely needed based on the available evidence. If bearing condition data justifies bearing inspection and the scope excludes it to save time, the cost of a bearing failure in the next operating period will almost certainly exceed what was saved. Scope decisions should be based on risk, not on what is convenient.

Scope creep without structured evaluation

Once the machine is open and engineers are on site with access to components, there is natural pressure to add work for things that "look like they might become a problem." Sometimes this pressure is correct. But unstructured scope additions during the outage have the same problem as an unstructured scope definition: no clear basis for the decision, no documented reasoning, and no way to evaluate whether the work was necessary after the fact. Every scope addition made after the machine is opened should go through the same trigger-and-basis evaluation that conditional scope items use.

Deferring mandatory items to avoid conflict

In some organisations, there is pressure — from plant management, from asset owners, or from budget cycles — to defer maintenance items that are technically due. This is different from a legitimate defer decision based on condition assessment. Deferring a mandatory inspection because it is inconvenient is accepting a risk that has not been properly evaluated. If a deferral is made, it should be documented, the risk basis should be stated explicitly, and the person accepting the risk should sign off on it.

The Defer Decision

Deferring a scope item — deciding not to do work that was considered for this outage — is a legitimate decision when it meets specific criteria. A defensible defer decision requires:

• A condition basis: the available data does not indicate that the component is at risk before the next scheduled outage. This is not the same as "no alarm has triggered."
• A defined monitoring plan: if you are deferring on condition, you must have a plan to monitor the relevant parameters through the next operating period with defined thresholds for escalation.
• A documented re-evaluation date: the deferred item must appear on the next outage's pre-scope input, with the current basis for deferral noted.
• A named decision maker: someone with technical and commercial authority accepts the risk of deferral.

A defer decision that lacks any of these elements is not a decision — it is a default. Defaults accumulate. A machine that has been subject to repeated unstructured deferrals will eventually present multiple simultaneously due items during a single outage window, creating exactly the cost and schedule pressure that the deferrals were intended to avoid.

How to Handle Scope Changes During the Outage

Even the most carefully defined scope will encounter unexpected findings once the machine is open. A structured process for handling scope changes prevents both under-response (ignoring significant findings) and over-response (adding unnecessary work under time pressure).

For each unexpected finding encountered during the outage:

1. Document the finding formally — description, location, photographs, measurements
2. Assess severity using the same criteria applied to pre-defined scope: what is the risk if this finding is not addressed before the next outage?
3. Determine whether the finding is within the existing scope (it can be addressed without adding time or cost) or requires a scope addition (additional time, parts or expertise)
4. For any scope addition: document the basis, obtain authorisation from the appropriate decision maker, and record the cost and schedule impact

This process takes more time than an informal discussion and a phone call. It is worth the time, because the record it creates becomes the basis for future scope definitions and makes the true cost-to-condition relationship of each machine visible over successive outage cycles.

What Good Scope Documentation Looks Like

The output of a scope definition process should be a document that can be handed to the outage team — and reviewed after the outage — with the following information:

• Fixed scope item list: what will be done, why it is in scope, what parts and resources are required
• Conditional scope item list: what trigger conditions activate each item, what the work is, who decides
• Explicit deferrals: what was considered and not included, the basis for deferral, and the monitoring plan
• Scope change process: who has authority to add scope during the outage, what documentation is required

A scope document that is completed before the outage and reviewed after it — comparing planned scope against actual scope and actual findings — provides the information needed to improve scope definition for the next outage. The value of structured scoping compounds over outage cycles in the same way that structured inspection does.

Axerion provides planned revision decision support that includes pre-outage scope definition and on-site technical support through the outage window. For unplanned situations, unplanned stop technical support provides the same structured approach under compressed timelines.