Saturday, June 27, 2015

Take SMS With You On The Road

A Safety Management System (SMS) is to take with you on the road, where action to safety is the focus point. SMS is not a tabletop exercise to conform to regulatory requirements, but a hands-on exercise to conform to safe operations.

It might be tempting to leave SMS back at the office with the stack of may other regulatory requirement for any operation. This could be as air operator,  transportation operator or just as simple as a private vehicle operator. What counts for safety is how operations are managed with processes, or how things are done.

Regulatory compliance keeps you floating, while safety management keeps you flying.
History of safety records is not guarantee of a future high safety rating.  Changes in processes are at times minor and almost not noticeable, but accumulative with several minor unnoticeable process changes over time. Without process monitoring there is no way to discover issues which could lead to incidents.  

When the regulatory compliant SMS system is left behind at the office it is not possible to detect operational process changes, or changes in how tings are done, until there is a breakdown in the system. This breakdown could be a simple administrative task, or a major system failure.  What is relevant is how an operator manages process to capture changes in expectations, or process goals. 

When SMS comes with you on the road the system becomes a natural part of day to day activities. SMS becomes the safety culture, the just culture and a culture to foster discovery of process changes, or non-punitive reporting. When decisions are based solely on history the outcome is not managed but assumed. When decision making is based on process review the outcome is managed. 

Safety operations from an office desk is like managing safety through a window.
This is how it goes; If you keep a regulatory compliant SMS on the shelves, it does nothing for safety in operations. You need to take SMS with you on the road to ensure you meet the bar of safety expectations, or safety goals.


Saturday, June 13, 2015

Perimeters vs. Parameters

Perimeters are directives, while Parameters are challenges. Both perimeters and parameters have their operational place in any organization with perimeter being task oriented and parameters are result oriented.

The perimeters are established to stay within confined area. 
Operational perimeters are evaluated to the limits of the perimeters. The issues are for tasks to be performed within the box, without deviation to venture outside the box. As long as all tasks are performed within the perimeters of the box, performance is acceptable.  This limits initiatives and operational decisions to assigned specific tasks. Tasks within the box may be applied in initial learning situations to instil knowledge and behaviour patterns, or to ensure regulatory compliance. This could be explained as when a person first learn to fly an airplane, the pilot-student has to stay within the box of assigned tasks to learn the aircraft's behaviour, and to understand the limits of operational regulatory compliance. As long as all operations are within the limits of the box, or perimeters, life is good.

Operational parameters are job-performance evaluation of results achieved. The limits are not lateral, as with perimeters, but limited to levels of complexity with initiatives and accountability. Parameters are result oriented, where one parameter must be completed before moving onto the next. Operational parameters requires skills, training and knowledgeable personnel. Assigned parameters are effective in  just-culture organizations, where results, or outcome of processes are evaluated.  

The parameters are established for results.
The difference between process parameters and process perimeters, is that process parameters tasks are linked and connected by individual activates,  while process perimeters tasks are individually independent and disconnected. An example of process perimeter could be the assembly line, where one robot has a specific independent task,  while an example of process parameter could be resilience to operational abnormalities.


Wednesday, June 3, 2015

Building A Safety Case

Building a safety case is not just a tabletop exercise, but a conglomerate of several operational hazard analyses of changes that may have safety impact on operations. The outcome of hazard analyses, or operational impact is unknown  until changes considered are entered into the blueprint tool and constructed as a safety case.  When a safety case is built and completed, it becomes a visualization of the future.

Safety case is to buckle up.
An airline may make a safety case for changes to new routes, aircraft or operational bases. Hazard considerations to route changes may include language barriers or regulatory operational standards. Other hazards to change in aircraft may be handling characteristics in manual mode, or display of automation. A new base may need to consider environmental hazards, or local workforce available. Hazards to consider for safety cases could be anything beyond limits of pre-determined assumptions.

Airports may make safety cases for operators, and build safety cases for aircraft movements. Airports as operational surfaces are static in nature, with aircraft movements as one of the variables. These variables could be less than ten movements per day or several hundreds of movements. In addition to variables in aircraft movements, the variables in itself are subject to non-scheduled variables, as aircraft diversion and weather delays. This make airport safety cases more complex in nature than often assumed.

During the summer months there are often construction activities at airports. This could be construction of public facilities or operational taxiways or runways. The upgrades could be simple excavations or major blasting projects where standard operations and obstacles are analyzed. Blasting may be assumed not to have an operational impact since there are no obstacles to evaluate. However, blasting has the potential of a severe malfunction where the emergency measures has to be included in safety cases.

Safety case is venture out with parameters.
Safety cases might not be what they appear to be when analyzing assumptions. Only when analyzing hazard facts can a true safety case be developed.