1.1. SWIFT

1.1.1. Description and Purpose

The Structured What-If Checklist Technique (SWIFT) combines the use of checklists with a brainstorming ‘What if?’ approach. It was initially developed for hazard identification in the chemical process industry. The technique was developed as an efficient alternative to HAZOP for providing highly effective hazard identification in situations and systems where HAZOP is not appropriate. SWIFT can also be used in conjunction with or complementary to a HAZOP.

The Structured What-If Checklist is a thorough, systematic, multi-disciplinary team orientated analytical technique. Whereas, HAZOP examines the facility item-by-item, procedure-by-procedure, etc. by applying guidewords, SWIFT, on the other hand, is a systems-oriented technique which examines complete systems or subsystems. To ensure comprehensive identification of hazards, the technique relies on a structured brainstorming effort by a team of experienced experts which is supported by supplementary questions from a specifically developed checklist. It requires specialists, who have the domain knowledge required of the area being considered, to evaluate the consequences of hazards that might result from the various potential failures or errors they have identified. When answering all the questions raised about realistic deviations from the normal intended operation of a system, design or operation, the team assesses the likelihood of an incident, the potential consequences and the adequacy of safeguards to prevent or mitigate it.

Its effectiveness in identifying hazards comes from asking questions in a variety of important areas, according to a structured plan. The aim is to ensure complete coverage of all the various types of failures or errors which are likely to result in a hazard within the system being examined.

The “What-if?” questions, which can be posed by any team member (including the SWIFT leader and Recorder) are structured according to various question categories. The SWIFT analysis is further strengthened through the use of category specific checklists at the conclusion of each question category resulting in an additional level of thoroughness. Information resulting from the SWIFT meeting is recorded on logsheets in columns as “What If”, “Consequences”, “Existing Safeguards” and “Recommendations”.

1.1.2. When It Might be Used

SWIFT is generally applicable for almost every type of risk assessment application, especially those dominated by relatively simple failure scenarios. It can be used alone, but most often used to supplement other, more structured techniques.

1.1.3. Advantages, Disadvantages, and Limitations to The Defence Sector or The Particular Domain


  • The technique is efficient because it generally avoids lengthy discussions of areas where hazards are well understood or where prior analysis has shown no hazards are known to exist.
  • It is very flexible, and applicable to any type of installation, operation or process, at any stage of the lifecycle.
  • It is quick, because it avoids repetitive consideration of deviations.
  • It uses the experience of operating personnel as part of the team.
  • If the subject matter experts are not available for the SWIFT session their questions can be gathered in advance and included in the checklist.
  • The checklists used are robust as the questions asked intuitively cover historical incidents that have happened in the past


  • Adequate preparation of a checklist in advance is critical to achieve completeness.
  • Its benefit depends on the experience of the leader and the knowledge of the team.
  • SWIFT relies exclusively on the knowledge of the participants to identify potential problems. If the team fails to ask important questions, the analysis is likely to overlook potentially important weaknesses.
  • Reviewing a what-if analysis to detect oversights is difficult because there is no formal structure against which to audit.
  • Most what-if reviews produce only qualitative results; they give no quantitative estimates of risk-related characteristics. This simplistic approach offers great value for minimal investment, but it can answer more complicated risk-related questions only if some degree of quantification is added (for example using Risk Matrices).
1.1.4. Sources of Additional Information

A list of additional information (e.g., Standards, textbooks, and websites) includes but is not limited to:

1.1.5. Additional Comments

Question Categories

Typical question categories that could be used are:

  • External Factors or Influences
  • Operating Errors and Other Human Factors
  • Maintenance
  • Measurement Errors
  • Equipment/Instrument Malfunction
  • Loss of Integrity
  • Emergency Operations
  • Utility Failures
  • Environmental and Health

Sample Checklist

The basic structure of the SWIFT system as developed originally for the process industry translates well to the marine industry. Some changes to topic list are necessary, but these are not extensive. The following list provides a starting point for the derivation of a checklist for a specific problem or range of problems.

This list would be extended by accident reviews, task analysis, codes and standards, and legislation. In the area of accident reviews, often the classification system of the accident database can be helpful in generating checklist questions. These words are helpful to the team in brainstorming causes of hazardous events.

Checklists should not be handed out to experts involved in the brainstorming and should be kept for prompting by the SWIFT Leader.

External Factors or Influences


  • Strong wind
  • Fog/reduced visibility
  • Flood
  • Heat
  • Cold
  • Humidity (wet/dry)

Human caused - security issues:

  • Vandalism
  • Fire (accidental or arson)
  • Bomb threat
  • Crowd problems/civil disturbance,
  • Sabotage

Operating Errors and Other Human Factors

This section is too broad to derive a specific checklist in advance. It requires the specific situation to be analysed in advance with respect to the types of topics and influences described below. This would be assisted by reference to a task analysis or accident review.

  • Base and vessel crew – manning levels
  • Task characteristics, information and workload
  • Errors (slips, lapses, mistakes) and violations
  • Ergonomics and work environment
  • Training and competence
  • Management, organisation – shift patterns, procedures, Personal Protective Equipment
  • Work practices (permits, testing, maintenance, inspections)


Hand-overs and controls:

  • Activity physical boundaries/responsibilities
  • Access authorisations/contractor issues
  • Communication of information at hand-overs

Inspection and Testing:

  • Material problems
  • Access and safety


  • Procedures and permits
  • Hot work, confined space entry
  • Electrical protections (e.g. 110 V, 220 V, other)
  • Scaffolds
  • Crane lifts
  • Monitoring/inspections/approvals

Measurement Errors

  • Navigational systems
  • Mechanical/electrical systems

Equipment/Instrument Malfunction

  • Structure
  • Machinery systems
  • Navigational equipment
  • Platform management systems and bridge systems

Loss of Integrity

  • Hull
  • Superstructure
  • Tanks/vessels

Emergency Operations


  • Clear definitions of emergencies
  • Implications for operations
  • Communications
    • changed roles, specific duties conflicts, equipment, etc.
  • Night, poor weather, etc

Utility Failures

Air failure:

  • Combustion
  • Heating and ventilation

Water failure:

  • Firewater
  • Cooling water
  • Drinking water
  • Sanitation

Effluent system failure:

  • Sewage system


  • Local communications, on board ship
  • External communications, to other ships, within the MOD

Other utility issues:

  • Mixing new utilities with old

Environmental and Health

Water contamination:

  • Cargo spillage (dangerous goods - fuels, chemicals, pesticides, explosives)
  • Storage (temporary/permanent)
  • Disposal


  • Dust and fumes
  • Noise and vibration

Health Issues:

  • Potential for injuries (accidental)
  • Potential for injuries (chronic)
  • Healthcare provisions
1.1.6. A Simple Example of a SWIFT Study Log Sheets

Logsheets for a SWIFT study of the fuel transfer operation:

Project: Fuel Transfer System Revision: 0 Node: 001           Page: 1
Date: Time:
Session: 0 Team:

Node Description:

Ship to Ship Fuel Transfer Operation



Organisation: XYZ
Location: Various

Design Intention:

To transfer fuel from the tanker storage to the ship storage tank. 

P&ID's Rev #'s

Normal Process Conditions (Range):

Temperature: Ambient 

Pressure: Negative static head from tanker, 3 barg maximum at pump discharge. Storage tanks are at atmospheric pressure. Capacity of tanker tanker is 50 m3, ship tank is 20 m3. 

Flow rate: 500 litres per minute

Team Members:

Project: Fuel Transfer System Node: 001 Page: 2

Node Description: 

Ship to Ship Fuel Transfer Operation

Question Category What If Consequences Safeguards Rec# Recommendation 
External Factors or Influences Heavy sea. Potential collision between tanker and receiving ship.

Transfer is not carried out in > force 4.  A gap of 50 metres is maintained between the ships during transfer.

Operating Errors and other Human Factors Operator connects up to thw wrong tank on the receiving ship.  Possible overfill of ship storage tank. Operator training and competence. R1 Ensure that destination fuel tank is correctly configured before starting transfer. This should be independently checked.
Loss of integrity Hose ruptures Discharge of fuel on tanker or receiving ship.  Potential fire and pollution incident. Inspection and testing of hoses.  Visual inspection before use.  6 monthly test as part of planned maintenance.  Operator can stop the transfer pump locally and isolate using the manual valves. R2 Provide actuated valves on the fuel delivery and receipt points (i.e. on each ship) such that the fuel supply can be quickly isolated in the event of a spill.
Pump casing fails due to cold weather. Discharge of fuel on tanker.  Potential fire and pollution incident. Annual pump inspection. R3 Check that fuel transfer pumps are not cast iron (cast iron pumps have been found to crack in cold weather).  If the pump is cast iron it should be replaced. 
Emergency Operations Tanker or ship has to manoeuvre in emergency. Possible hose rupture and discharge of fuels (fire and pollution incident). Tanker and/or receiving ship would instruct for hoses to be disconnected before manoeuvring. R4 Review the design of the hose connections and if necessary modify so that hoses can be quickly disconnected if needed in an emergency.  
1.1.7. Planning and conducting a SWIFT session

Planning and Preparation

A team comprised of 4 to 8 members including the SWIFT Leader and technical Recorder is recommended. At a minimum, the team should consist of one or more persons who have expertise in vessel technical issues (naval architect, marine engineer, etc.) and one or two who have relevant operating experience (Captain, Navigation Officer, etc.). Depending upon the precise nature of the system or the change being examined, additional team members might include representatives from maintenance, instrumentation, quality control, safety, and other disciplines.

The SWIFT Leader should compile a checklist of issues relating to the system based on legislation, accident / incident reports, standards, guidance documents, existing checklists, task analysis, etc. and circulate it to all the team members for review prior to the first session.

The reference documents necessary for conducting a SWIFT review are identical to those required for HAZOP. Just as with a HAZOP, the more comprehensive and up-to-date the data available to the team, the more efficient and effective the analysis.

In contrast to HAZOP, the leader of a SWIFT review does not have to refrain from participation in the team discussion. This is because the Leader may have been actively involved in generating the checklist. Depending upon the circumstances, a leader with a high level of expertise in the system can benefit the efficiency and effectiveness of the study. However, the leader should have SWIFT leadership training so he/she can recognise the importance of issues, control the flow of the study, and keep it on track. Also, he/she must still be careful to ensure that he/she does not assert undue influence over the direction and outcome of the proceedings, particularly because he/she is now a “participant”.

For studies of narrow scope, it is also acceptable for the SWIFT leader to double as the technical Recorder. However, if a study is likely to last longer than a half a day, it would probably be more efficient and effective if the proceedings are transcribed by qualified individual other than the SWIFT leader. The significant danger of combining the roles of SWIFT leader and Recorder is that incomplete minutes will be obtained due to time pressures. In normal circumstances it is routine for the Recorder to be typing the last discussion minutes, while the team moves on to the next item.

Initial Discussions

Once the preparations are completed and the SWIFT team assembles, the leader should spend a brief period of time reminding or training the team as necessary in how the SWIFT analysis will be conducted. Next he or she should orient the team to the basics of the design or system under review.

In many cases, the study is likely to involve the analysis of a proposed change in some part of the process or its mode of operation. If such is the case, the details of that change should be discussed. To ensure compliance with Management of Change procedures, this pre-analysis discussion should focus on, but not be limited to:

  • The technical reason or basis for the change.
  • The expected impact the change might have on safety and health.
  • The need to change or modify operating procedures / training.
  • The intended duration of the change and if possible an estimate of how long its start-up is likely to take.

As a result of this discussion, the scope and objectives of the study can then be established. At a minimum these should include setting the boundaries of the system(s) to be examined, specifying the types of on site and off site issues of concern (safety, health, environment, quality, productivity), and clearly defining any other objectives of interest to the organisation.

Selecting a Study Section

As necessary, the system to be examined should be divided into an appropriate number of smaller subsystems. Examining the unit at a systems level often makes it easier to recognise interactions of various components within the system or with other systems in the processing unit. However, since each item of equipment is not being individually treated as in a HAZOP, caution should be exercised – it is preferable to err on the side of caution and be too detailed rather than miss something critical. Usually, a team should be able to examine unit/operation- sized sections without difficulty. Some systems representative of those which typically can be analysed successfully as a single section might include:

  • Ship’s propulsion system.
  • Procedures undertaken from departure/arrival at a berth up to leaving/entering harbour.
  • All logically associated equipment on a single drawing / schematic.

However, smaller sections may need to be considered if:

  • Unusually high hazard materials are involved.
  • Extreme conditions are present.
  • The system or its controls are very complex.
  • Unusual types of equipment are involved.
  • The potential consequences are severe (Major Accident Hazards: multiple fatalities or loss of platform)

It may be appropriate to use HAZOP to evaluate specific sub-sections meeting these criteria should the SWIFT leader consider it advisable, as HAZOP is more systematic and rigorous than SWIFT and can identify failures that are not immediately obvious.

Just as when picking nodes or sections for a HAZOP, experience will enable the SWIFT leader to become adept at choosing systems for study which ensure both efficient use of team time and effectiveness in identifying the hazards.

Conducting the Discussions

Once the scope of a system section is defined, the design intent, conditions and other appropriate details should be discussed and entered into the logsheet. Except for the structured posing of “what if” questions, the discussion during a SWIFT review should be similar in all aspects to those encountered during a HAZOP study. All team members should participate and all should be permitted to express their opinions and concerns. Although the SWIFT leader will also be a participant in a SWIFT study, he or she must be careful not to dominate the discussions and ensure that the discussions are restricted to relevant topics.

The leader should begin the discussion by asking for and summarising team input for each of the regulatory requirements listed below:

  • Hazards of the activity or procedure
  • Previous incidents
  • Engineering and administrative controls.
  • Consequences of failures of engineering and administrative controls.
  • Siting/layout issues
  • Qualitative evaluation of safety and health effects.
  • Other regulatory issues.

Next, he or she should begin the discussion by stating the category of questions (below) for discussion and then by either asking the team to brainstorm “What If” questions or offering an initial question.

The structure for questioning in the original SWIFT (developed for process industry) is provided by the following categories:

  • Material Problems (MP).
  • External effects or influences (EE/I).
  • Operating errors and other human factors (OE&HF).
  • Analytical or sampling errors (A/SE).
  • Equipment/instrumentation malfunction (E/IM).
  • Process upsets of unspecified origin (PUUO).
  • Utility failures (UF).
  • Integrity failure or loss of containment (IF/LOC).
  • Emergency operations (EO).
  • Environmental release (ER).

For process industries, the categories would be tackled in the above order. For other industries, the SWIFT leader must get the group to prioritise the categories according to the hazards associated with the system under investigation. Once this has been established, the top category is addressed and then each subsequent category in turn.

Question categories summarises the intent of each of these question categories. If needed, the SWIFT leader or team member may obtain additional ideas of the types of questions which are appropriate for each category by consulting Structured Checklists. It is best, however, for the team to initially “brainstorm” each category individually and then to use the questions on the corresponding checklist to help ensure completeness. This approach will help minimise the tendency for the team to become dependent upon the SWIFT Checklists as a sort of “cheat sheet” which could stifle team creativity.

The “What if” Questions

The “What-if” questions often may often begin with the words “What-if” but they don’t have to. “How could”, “Is it possible,” or any other form of question is perfectly acceptable. The intent is to ask questions which will cause the group to carefully consider and think through the potential scenarios and ultimate consequences that such an error or failure might precipitate. When the multidisciplinary team is unable to draw upon or extrapolate their experience to imagine any additional “What-if” questions in a given category, they should consult the SWIFT checklists to prompt additional questions as appropriate.

Although the questions can be answered as they are raised, it is usually best to pose and record as many questions as possible in a “brainstorming” manner before trying to answer them. Interrupting the train of thought when brainstorming may result in questions being forgotten or perhaps never even being posed. Additional questions can always be added to the discussion list as they are raised. The SWIFT study leader needs to be aware that this is not an unusual occurrence during the discussions of the initial questions.

Answering the Questions

When the flow of ideas subsides, the leader should ask the Recorder to read each “What if” question in turn and ask the team to comment on how the system, adjoining systems or the whole unit is likely to respond. The Recorder should enter a brief summary of the discussion in the logsheet just as would be done during a HAZOP. Similarly, the possible consequences are then examined and if the team considers current detection/safeguards or mitigation to be sufficient, the next question should be discussed.

By applying his experience, the leader may further reduce the study time by selectively changing the order of discussion of the questions posed by the team. By first considering those questions which appear to involve the most severe potential consequences, the team can often make a more comprehensive recommendation which covers many of the same issues which will be identified during the discussion of the remaining questions. When this approach is used, however, care must be taken to adequately consider all of the “What-if” questions on the list to ensure that every known important issue has been raised, discussed and recommendations written where necessary.


Just as in a HAZOP, if the team is not satisfied with the level of protection or otherwise perceives a need for further analysis, recommendations for further action should be proposed for management consideration. Such recommendations need to include a brief description of the potential hazard, a description of what equipment, instrumentation or procedures currently in place are relied upon to prevent the development of the hazard and finally, the objectives which must be achieved to provide a solution to the potential problem. Care should be taken to provide enough factual information but not too many specific details of how the correction should be implemented. This provides the designers with as much flexibility as possible in providing a solution which will meet the objectives necessary to eliminate or manage the potential hazard.

It is important to remember that (as with HAZOP) a member of the SWIFT team has the responsibility of identifying and adequately explaining to management what hazards might be present and taking responsibility for moving forward with any recommendations.

Recommendations should always remain flexible. They should clearly state the perceived deficiency and the objectives which the team considers important for eliminating or managing the hazard. Ideas for a potential modifications which came to mind during the discussions can and should be documented, however, care must be taken not to state them in such a manner that can be construed as the only solution to the identified problem or as binding upon management.

Completing the Analysis

The procedure described above should be carried out for each question category. After the final category is discussed, the leader should ask the team if there is “anything else” which comes to mind that just didn’t come up in the discussions. If so, the questions should be posed and answered. When the analysis of a system or subsystem is complete, the procedure is repeated for any remaining sections until the agreed upon scope has been completely and satisfactorily addressed. To wrap up the study of the major system section, the leader should direct the team in reviewing and updating their thoughts on each of the regulatory requirements which were used to initiate the discussions. Finally, the review of an entire unit or plant may consist of a series of several studies, each having a scope comparable to the typical major section just described.

As with a HAZOP, the team should prioritise the issues identified by the SWIFT study to provide management with a clear understanding of the most significant issues to be addressed. The report format for a SWIFT analysis should be no different from that of a HAZOP, and the recommendations should be prioritised, tracked and completed in the same manner.

SWIFT Reporting, Documentation and Follow Up

The SWIFT analysis is recorded on a SWIFT logsheet which is very similar to that used for HAZOP recording. The main difference is that the left-hand column is completed with “What-if” questions rather than guidewords. The organisation of the report and follow up should be handled in a manner identical to that used for HAZOP.

1.2. Version Control

Version 3.0 to 3.1 Uplift

Links within Sources of Additional Information and Additional Comments have been updated.


Version 2.3 to 3.0 Uplift

Major uplift from the Acquisition System Guidance (ASG) to online version.