How to Develop an Effective Technical Procedure

What an effective procedure must achieve

A well-developed procedure should answer the practical questions that arise before, during and after execution.

• What work is being performed?
• Why is the work required?
• Which equipment, systems and boundaries are included?
• Who is authorised and responsible?
• What must be complete before work begins?
• What hazards, permits and isolations apply?
• In what sequence should the work proceed?
• Which conditions require the work to stop?
• What evidence confirms each important result?
• What constitutes acceptance?
• How will the system be restored or handed over?
• Which records must be retained?

If the procedure leaves these questions to be resolved during execution, it is not yet ready for controlled use.

1. Confirm that a procedure is the right document

Not every activity requires a full procedure. Select the document type according to the complexity, risk, repeatability and evidence requirements of the work.

Using the wrong document type can produce either excessive administration or insufficient execution control.

2. Define the purpose and required outcome

Begin by stating why the procedure exists and what successful completion must achieve. The purpose should describe the intended result rather than repeat the document title.

A clear purpose identifies:

• the function, condition or state to be achieved;
• the reason the activity is required;
• the evidence needed to demonstrate completion;
• the operational or project decision supported by the result.

A procedure cannot be structured effectively until the required outcome is clear.

3. Establish scope and boundaries

Define precisely what the procedure includes and excludes. A broad title may involve several systems, disciplines, interfaces and operating authorities.

The scope should identify:

• equipment and systems included;
• physical and functional boundaries;
• supplying and receiving systems;
• interfaces with other procedures;
• operating modes covered;
• temporary equipment included;
• activities specifically excluded;
• starting system condition;
• required final system condition.

Where system boundaries are complex, refer to approved drawings, system definitions, marked-up diagrams or boundary registers.

4. Identify users, roles and authority

Write for the people who will prepare, execute, witness, approve and accept the work. Define responsibilities clearly enough that ownership is not negotiated during execution.

Relevant roles may include:

• procedure owner;
• executing authority;
• operating authority;
• commissioning authority;
• test engineer;
• discipline engineer;
• vendor representative;
• control-room operator;
• safety representative;
• witness;
• client or Class representative;
• final accepting authority.

For each role, establish where applicable:

• preparation responsibility;
• approval responsibility;
• control of permits and isolations;
• authority to start;
• authority to pause or stop;
• responsibility for recording results;
• authority to accept deviations;
• responsibility for restoration;
• final acceptance responsibility.

Attendance and responsibility are not the same. A person listed as a witness should not be assumed to own execution control.

5. Gather and control source information

A procedure should be based on current, approved and traceable technical information.

Relevant sources may include:

• specifications;
• approved drawings;
• equipment data sheets;
• cause-and-effect diagrams;
• control narratives;
• manufacturer manuals;
• commissioning plans;
• system definitions;
• inspection and test requirements;
• risk assessments;
• permit and isolation standards;
• project requirements;
• Class or regulatory requirements;
• operating procedures;
• previous approved test records;
• technical queries and approved changes.

Record the document number, revision and status of important references.

Do not copy obsolete instructions into a new procedure merely because they were used on an earlier project or similar unit.

6. Understand the task before writing the steps

The author should understand how the system, equipment and interfaces are intended to function before attempting to write the execution sequence.

Useful preparation may include:

• system walkdown;
• drawing review;
• review of construction and completion status;
• discussion with engineering and operations;
• vendor consultation;
• review of known technical queries;
• inspection of access and working conditions;
• review of similar previous work;
• confirmation of test equipment and temporary services;
• identification of connected-system dependencies.

Where the task is complex, first map the activity as a high-level sequence before writing individual instructions.

Suggested sequence:

1. Establish the starting condition.
2. Confirm prerequisites.
3. Apply required controls.
4. Prepare the system.
5. Execute the activity.
6. Record intermediate results.
7. Respond to abnormal conditions.
8. Verify acceptance.
9. Restore the system.
10. Complete records and handover.

7. Define prerequisites and readiness

A procedure should not begin with the first operating instruction. It should begin with confirmation that the work is ready to proceed.

Prerequisites may include:

• approved procedure and revision;
• approved risk assessment or method statement;
• valid permits and isolations;
• mechanical completion status;
• closed prerequisite punch items;
• available utilities;
• confirmed system boundaries;
• correct software and configuration;
• calibrated test equipment;
• suitable temporary equipment;
• available communications;
• required personnel and witnesses;
• approved vendor attendance;
• safe access and lighting;
• weather or environmental limits;
• emergency arrangements;
• agreed restoration plan.

Each prerequisite should be:

• objectively verifiable;
• assigned to an owner where necessary;
• confirmed before dependent work begins;
• recorded where its status is important to acceptance.

“Ready” should describe a verified condition, not an expectation that unresolved work will be completed during the test.

8. Integrate hazards and controls

Safety controls should be built into the execution sequence rather than placed only in a general warning at the start of the document.

The procedure should identify where applicable:

• energy sources;
• stored energy;
• moving equipment;
• pressure;
• temperature;
• hazardous substances;
• electrical hazards;
• lifting and suspended loads;
• confined or restricted access;
• simultaneous operations;
• environmental limitations;
• communication requirements;
• exclusion zones;
• personal protective equipment;
• emergency stop arrangements;
• stop-work conditions.

Do not duplicate a full risk assessment inside the procedure. Refer to the approved risk-control documents while making the critical execution controls visible at the relevant steps.

9. Write executable steps

Each step should direct a clear action, identify the responsible role where necessary and state the expected result.

Effective instructions normally:

• begin with an action verb;
• contain one primary action;
• follow the actual execution sequence;
• identify the equipment or control clearly;
• avoid undefined pronouns;
• avoid unnecessary narrative;
• state required readings, conditions or evidence;
• identify related hold points or acceptance criteria;
• include restoration where the action changes the system state.

Avoid vague instructions such as:

• Check system.
• Test as required.
• Confirm satisfactory.
• Inspect all equipment.
• Adjust if necessary.
• Repeat until correct.

Replace vague wording with observable requirements.

A competent executor should not have to guess what action, observation or result the author intended.

10. Keep one instruction under control

Do not combine several independent actions, observations and decisions into one long procedural step. Separate them where a failure, hold point or unexpected result would require the sequence to stop.

A controlled step should make clear:

• what action is performed;
• who performs it;
• what condition must exist first;
• what result is expected;
• what evidence is recorded;
• what happens if the result is not achieved.

Where several actions must occur together, explain the coordination method and identify the person controlling the sequence.

The step structure should make it possible to identify exactly where execution stopped and what system condition existed at that point.

11. Define hold points, witness points and approvals

Formal intervention points should be visible within the procedure and agreed before execution.

For each intervention point, define:

• the required condition;
• the responsible party;
• the required notice;
• the evidence to be reviewed;
• the method of release;
• the record of acceptance.

Do not allow an attendance signature to be interpreted as technical acceptance unless that responsibility is explicitly assigned.

12. Establish measurable acceptance criteria

Acceptance criteria should be defined before execution begins. They should not be negotiated after the result is known.

Criteria may be based on:

• approved design values;
• manufacturer limits;
• project specifications;
• Class or regulatory requirements;
• operating limits;
• functional behaviour;
• timing;
• sequence;
• alarm and trip response;
• stability;
• repeatability;
• leakage or integrity requirements;
• connected-system response;
• documented engineering acceptance.

Avoid relying only on terms such as:

• satisfactory;
• acceptable;
• normal;
• correct;
• adequate;
• as expected.

Where numerical limits are required, reference the controlled source rather than inventing values in the procedure.

A result is auditable only when the acceptance basis is known and traceable.

13. Define abnormal-result and stop-work responses

A procedure should explain what happens when the expected result is not achieved.

The response should distinguish between:

• a minor result that can be recorded and reviewed;
• a condition requiring technical clarification;
• a failed acceptance criterion;
• an unsafe or unstable condition;
• a result requiring immediate restoration;
• a condition requiring the procedure to stop.

The procedure should define:

• who is notified;
• who has authority to continue;
• how the system is made safe;
• how evidence is preserved;
• how deviations are recorded;
• whether retesting is permitted;
• which approval is required before resuming.

Do not instruct executors to keep adjusting equipment until the result becomes acceptable unless the adjustment process, authority and limits are explicitly controlled.

14. Control temporary configurations

Testing and commissioning may require temporary supplies, jumpers, bypasses, overrides, simulated signals, temporary instruments or altered settings. These configurations must be visible and controlled.

For every temporary configuration, identify:

• purpose;
• technical basis;
• owner;
• authorisation;
• physical identification;
• installation record;
• operating limitation;
• monitoring requirement;
• removal point;
• restoration check;
• final close-out evidence.

The procedure should include a final review confirming that all temporary configurations have been removed or formally transferred under an approved control process.

15. Plan restoration and final system state

The required final condition should be defined before execution starts.

Restoration may include:

• returning selectors and operating modes;
• removing test equipment;
• removing temporary supplies;
• reinstating protection;
• removing overrides and bypasses;
• restoring valves, dampers and mechanical arrangements;
• confirming software or setting status;
• clearing permits and isolations;
• checking connected systems;
• completing housekeeping;
• updating control-room status;
• communicating limitations;
• recording the final configuration.

Do not assume that returning equipment to its starting condition is always correct. The intended final state may be operational readiness, preservation, standby, isolation or formal handover.

A procedure is not complete until the system state is known, controlled and communicated.

16. Design the evidence record

The procedure should make it easy to record the evidence required for acceptance.

Evidence may include:

• dates and times;
• responsible personnel;
• witness details;
• instrument identification;
• calibration status;
• measured results;
• equipment status;
• alarm and trip response;
• photographs;
• control-system records;
• configuration files;
• signed test sheets;
• punch references;
• deviation records;
• technical-query references;
• final acceptance signatures.

Avoid requiring unnecessary signatures that do not represent a defined responsibility.

Where readings or results are important, provide a structured place to record them rather than leaving evidence in handwritten margins or separate informal notes.

17. Walk through and validate the draft

A desk review alone may not reveal access problems, missing interfaces, incorrect sequencing or unclear instructions.

Validation should be proportionate to the risk and complexity of the activity and may include:

• multidisciplinary document review;
• field walkdown;
• drawing and equipment cross-check;
• control-room review;
• vendor review;
• operator review;
• tabletop walkthrough;
• dry run;
• simulation;
• controlled trial;
• witnessed first execution.

During validation, check:

• whether the sequence matches the real system;
• whether every control can be identified;
• whether access is practical;
• whether prerequisites are sufficient;
• whether the required people can coordinate the actions;
• whether acceptance evidence can be captured;
• whether restoration is complete;
• whether the procedure can be stopped safely.

Validation tests the procedure as an execution tool, not merely as a document.

18. Review, approve and issue

The review and approval route should reflect the technical scope, risk and project requirements.

Reviewers should understand what they are accepting.

Typical review interests include:

• technical correctness;
• system integration;
• operational impact;
• safety controls;
• execution practicality;
• vendor requirements;
• inspection and test evidence;
• Class or client requirements;
• restoration and handover;
• document control.

Before issue, confirm:

• title and document number;
• revision;
• page numbering;
• references;
• responsibilities;
• prerequisites;
• risk controls;
• sequence;
• acceptance criteria;
• records;
• approvals;
• revision history.

Only the approved revision should be available for controlled execution.

19. Control changes during execution

A procedure should not be informally rewritten in the field when the system, sequence or acceptance requirement differs from the approved basis.

When a change is required:

1. Stop at a safe and controlled point.
2. Record the issue.
3. Preserve relevant evidence.
4. Obtain technical review.
5. Assess safety and interface impacts.
6. Define the revised instruction or acceptance basis.
7. Obtain the required approval.
8. Issue or record the controlled change.
9. Brief affected personnel.
10. Resume only when authorised.

Minor annotations should not be used to conceal a material change in technical scope, risk or acceptance criteria.

20. Capture learning after execution

The first controlled use of a procedure often identifies improvements that were not visible during drafting.

After execution, review:

• unclear instructions;
• missing prerequisites;
• unexpected interfaces;
• unnecessary steps;
• repeated delays;
• access limitations;
• unsuitable evidence fields;
• abnormal results;
• restoration issues;
• temporary configurations;
• user feedback;
• changes made during execution.

Update the controlled procedure where the learning is relevant to repeat work.

Do not allow marked-up working copies to become unofficial permanent revisions.

Technical procedure development checklist

• Confirm that a procedure is the appropriate document type.
• Define the purpose and required outcome.
• Establish physical and functional scope boundaries.
• Identify users, roles and authority.
• Verify current source documents and revisions.
• Understand the system and task before drafting.
• Define objectively verifiable prerequisites.
• Integrate hazards and controls into the sequence.
• Write one clear primary action per step.
• State expected results and evidence requirements.
• Define hold points, witness points and approvals.
• Establish measurable and traceable acceptance criteria.
• Define abnormal-result and stop-work responses.
• Control temporary configurations.
• Define restoration and the required final system state.
• Provide structured evidence fields.
• Walk down and validate the draft.
• Complete technical, operational and safety review.
• Issue only the approved revision.
• Control changes during execution.
• Capture learning after first use.
• Update repeat-use procedures through document control.

Minimum content of a controlled technical procedure

The precise format will vary, but a controlled technical procedure should normally contain enough information to establish the following:

• title;
• document number;
• revision and status;
• purpose;
• scope;
• exclusions;
• references;
• definitions and abbreviations;
• responsibilities;
• prerequisites;
• safety and risk controls;
• tools and test equipment;
• starting condition;
• execution sequence;
• hold and witness points;
• expected results;
• acceptance criteria;
• abnormal-result response;
• temporary-configuration controls;
• restoration requirements;
• required records;
• final acceptance;
• revision history;
• approvals.

Questions for the final author review

• Can a competent person understand the intended outcome?
• Are the system boundaries unambiguous?
• Is the approved source information traceable?
• Are responsibilities and authority clear?
• Can every prerequisite be objectively confirmed?
• Are risks controlled at the point they arise?
• Does each step contain a clear action?
• Are expected results and acceptance criteria defined?
• Can the work stop safely at each important stage?
• Are abnormal results controlled?
• Are temporary configurations visible?
• Is the final system state defined?
• Can the required evidence be recorded easily?
• Has the procedure been validated against the real system?
• Is the approved revision clearly identifiable?
• Can another competent person understand the completed record?

A procedure is an execution control

A technical procedure should not be treated as a document produced only to satisfy a project requirement. It is part of the control system for the work.

When purpose, scope, responsibilities, prerequisites, risks, sequence, acceptance and restoration are clearly defined, teams can execute with fewer assumptions and produce stronger evidence of completion.

When those elements are unclear, even an experienced team may deliver inconsistent results, lose technical evidence or leave the system in an uncertain condition.