1.1.1.2.

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.

1.1.1.4.

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.1.

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.1.

Advantages

• 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

1.1.5.2.

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.

1.1.5.4.

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

1.1.5.6.

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)

1.1.5.8.

Measurement Errors

• Navigational systems
• Mechanical/electrical systems

1.1.5.10.

Loss of Integrity

• Hull
• Superstructure
• Tanks/vessels

1.1.5.12.

Utility Failures

Air failure:

• Combustion
• Heating and ventilation

Water failure:

• Firewater
• Cooling water
• Drinking water
• Sanitation

Effluent system failure:

• Sewage system

Communications:

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

Other utility issues:

• Mixing new utilities with old

1.1.6.2.

1.1.7.2.

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.

1.1.7.4.

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.

1.1.7.6.

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.

1.1.7.8.

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.

1.1.7.10.

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.

1.1.7.12.

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.

1.1.7.14.

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.

1.1.7.16.

Conducting the Discussions

1.1.7.18.

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.

1.1.7.20.

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).

1.1.7.22.

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.

1.1.7.24.

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.

1.1.7.26.

Answering the Questions

1.1.7.28.

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.

1.1.7.30.

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.

1.1.7.32.

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.

1.1.7.34.

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.

1.1.7.36.

SWIFT Reporting, Documentation and Follow Up