Define Functions & Performance Standards

Process Steps

1. 01

   Document operating context

   Intent

   Capture duty cycle, environment, redundancy and any process-imposed limits so every function statement reads against the real conditions the asset works in.

   Inputs

   • Signed charter and boundary diagram from Phase 1
   • Operator interviews and control-room logs
   • Design basis / process flow diagrams
   • Recent process, throughput or feedstock changes

   Actions

   • Write a short context statement (1–2 paragraphs)
   • Record duty cycle, ambient conditions and any redundancy or standby capacity
   • Note recent context changes (higher throughput, new feedstock, deferred capex, seasonal duty)
   • Confirm with operations that the description matches how the plant actually runs today

   People

   Operations supervisor and control-room lead confirm real duty. Process engineer verifies against design. Reliability engineer records.

   Process

   Context is written before functions. If the context changes later, function statements are re-tested — not silently rewritten.

   Technology

   Operating context template stored in the RCM pack. Reference to process flow diagrams and DCS trends.

   What Good Looks Like

   • Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
   • The opposite of: copying the design basis and calling it context
   • The opposite of: ignoring recent throughput or feedstock changes
   • The opposite of: skipping operator input

   What Bad Looks Like

   • Copying the design basis and calling it context
   • Ignoring recent throughput or feedstock changes
   • Skipping operator input — duty cycle assumed from spec sheets

   Outputs

   • Documented operating context statement
   • Register of recent context changes with dates
   • Confirmed duty and redundancy assumptions
2. 02

   List primary functions

   Intent

   State exactly what the asset must do — verb + object + measurable performance standard — so failure has a clear benchmark.

   Inputs

   • Operating context from Step 2.1
   • P&ID tag numbers and design duty
   • Instrument ranges and process control set-points

   Actions

   • Use active verbs: pump, contain, filter, convey, isolate
   • Quantify performance: flow, pressure, temperature, cycle time, availability
   • One function per statement — split composite duties into separate lines
   • Number functions so failure modes can reference them (F1, F2, …)

   People

   Operator and process engineer confirm the real performance standard. Reliability engineer records.

   Process

   Every function has a verb, object and measurable standard. Statements without a number cannot pass into Phase 3.

   Technology

   Function register (spreadsheet or RCM software) linked to P&ID tags.

   What Good Looks Like

   • Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
   • The opposite of: vague statements like 'work properly'
   • The opposite of: bundling multiple functions into one line
   • The opposite of: copying design capability instead of the real operating standard

   What Bad Looks Like

   • Vague statements like 'work properly' — nothing to fail against
   • Bundling multiple functions into one line
   • Copying design capability instead of the real operating standard

   Outputs

   • Numbered primary function list with measurable standards
   • Cross-reference to P&ID tag numbers
3. 03

   List secondary functions

   Intent

   Cover the ESCAPES categories (Environmental, Safety, Control, Appearance, Protection, Economy, Structural) so protective and hidden functions are never missed.

   Inputs

   • Primary function list from Step 2.2
   • HAZOP, safety case and environmental permit conditions
   • Alarm and trip schedules; relief-device register

   Actions

   • Walk the asset with an operator — protective devices are always missed on paper
   • Cross-reference safety case, HAZOP and environmental permits
   • List every alarm, trip, relief, containment and standby function
   • Confirm secondary functions have their own measurable standards

   People

   Operator walk-down with reliability engineer. HSE representative confirms safety and environmental duties.

   Process

   Secondary functions sit under the primary function they support. Protective functions carry a note that they are hidden — flagged for Phase 5.

   Technology

   Function register linked to HAZOP node IDs and safety-instrumented-system schedules.

   What Good Looks Like

   • Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
   • The opposite of: missing protective functions
   • The opposite of: treating alarms as inputs rather than functions in their own right
   • The opposite of: assuming standby equipment doesn't need functions defined

   What Bad Looks Like

   • Missing protective functions — hidden failures go undetected in Phase 5
   • Treating alarms as inputs rather than functions in their own right
   • Assuming standby equipment doesn't need functions defined

   Outputs

   • Complete secondary function list under each parent primary function
   • Cross-reference to safety case / HAZOP node numbers

People

Operator input is non-negotiable — operators know the real performance standard. Reliability engineer records; process engineer confirms design intent.

Process

Function statements are the single source of truth for everything downstream. Never begin failure modes until every function has a measurable standard.

Technology

Function register (spreadsheet or RCM software). Link to P&ID tag numbers.

Phase Outputs

• Numbered function list per asset
• Documented operating context statement
• Confirmed performance standards (desired capability)