The Optimal Workload

My work has changed a great deal since 1971 when I was the welder helper on the right side of the photo below. We were constructing a natural gas pipeline in Illinois that summer. My workload then was straightforward. My primary tasks were to prepare two weld ends as quickly as possible so they could be welded together and to assist the welder with completing the weld. And that job was repeated for at least ten hours a day seven days a week. It looks like I was pretty hot and the sweat was pouring out of me. That might have been the result of poor behaviors the night before. Those behaviors affected my ability to handle the workload; just as your off-duty activities affect you at work. The purpose of the tie-in crew was to complete as many welds as possible every day. No one was concerned about whether the workload was optimal or not. From the perspective of the foreman, my workload was always too low. There was little concern about fatigue levels. Since the workload was primarily physical, my 23-year-old self could do well for those ten or more hours of work.

Now a portion of my work is concerned with the workload of pipeline controllers and whether individual controllers of various ages can safely handle work that is primarily mental in nature. Task-related cognitive fatigue is a concern. It is important to understand if the workload is too high, too low, or optimal. How well do you and your colleagues handle the workload on your shift? Does anyone monitor what you do and how much time it takes to perform your required tasks? Is your workload low, high, or just right? Do you have to juggle tasks all day or all night long? Do you retain any spare capacity for unexpected, critical events?

We address these questions with a formal, structured, comprehensive method that measures time and tasks and the elements of the NASA Task Load Index. The purpose of this method is to address this statement from the Control Room Management (CRM) regulations 195.446 (e) (5) and 192.631 (e) (5):

  • Monitor the content and volume of general activity being directed to and required of each controller at least once each calendar year, but at intervals not exceeding 15 months, that will assure controllers have sufficient time to analyze and react to incoming alarms; and

The method we use provides a conclusion about whether or not each controller has sufficient time to analyze and react to incoming alarms. That is the crux of the matter. We have had the opportunity to evaluate a number of methods that companies have been using since 2011 to “monitor the content and volume of general activity.” Some of those methods do not involve the controllers. Others measure “hard data” but do not provide any assurance about whether or not controllers have time to respond to alarms. A few do not even consider alarm data and alarm response. Other methods display all types of charts and graphs that are created from data collected from the SCADA system but have little correlation to alarm response by controllers. A method should answer this question, “Does each controller have sufficient time to analyze and react to incoming alarms?”

Here are some deficiencies in this area noted in PHMSA CRM inspections and cited in publicly available Notices of Amendments (NOA) or other enforcement actions.

  • …did provide information on a work load analysis, but this was not inclusive of all tasks that a controller will perform (NOA 7-6-12)
  • …did not include adequate formality around monitoring the content and volume of alarms received per console and how various metrics will lead to additional console creation. The workload study discussed during the inspection and associated planning has not been implemented, finalized or reflected in the plan. (NOA 10-10-12)
  • The CRM plan needs to be amended to determine if the controller has sufficient time to analyze and react to incoming alarms. (NOA 11-28-12)
  • …inadequate because the program does not have a means of determining that the controller has sufficient time to analyze and react to incoming alarms. Much of this activity is being performed but not formalized in the plan. (NOA 7-18-13)
  • …failed to monitor the content and volume of general activity being directed to and required of each controller at least once each calendar year, but at intervals not exceeding 15 months, that will assure controllers have sufficient time to analyze and react to incoming alarms. Exceeded the interval of 15 months for 5 controllers. (Notice of Probable Violation 4-1-14)
  • …did not provide documentation for the calendar years 2012 and 2013, that the content and volume of general activity being directed to and required of each controller was being monitored at least once each calendar year not to exceed 15 months. XXX commissioned a Workload Analysis that was finalized November 11, 2011. The next documented Workload Analysis was completed on March 6, 2014. (Warning Letter 4-11-14)
  • …did not have adequate procedures to address how workload assessments will be performed. (NOA 3-4-15)

These examples appear to reinforce what I said above. Byron Coy from PHMSA said that deficiencies in this CRM area are the third highest in the PHMSA CRM inspections through the first quarter of 2015 (API Presentation 4-28-15 Savannah, Georgia). Evaluate the workload analysis method you are using and determine if it involves all of the controllers, demonstrates that controllers have adequate time to analyze and react to incoming alarms, and is being done each calendar year, not to exceed 15 months.

Since we have performed over 120 workload assessments since 2011, the benchmarks from those assessments indicate that a workload of between 60% and 70% of total time for operational tasks during a shift is optimal for sustaining controller interest. Those operational tasks can be grouped into control or operations, monitoring, logs and paperwork, sampling or proving, alarm response, response to abnormal events, and response to emergency events. Other tasks can be grouped into communications, administrative tasks, and time for breaks during a shift.

A NASA Task Load Index of 7 or below, based on data from those 120 assessments, is an acceptable score. The index measures Mental Demand, Physical Demand, Time Pressure, Effort Required, Frustration Level, and Performance Success. The measurements for time on tasks and the NASA Task Load Index should be taken across a period of time that includes both low workload and high workload times for the controllers on all days of the week and on all shifts.

The role of a controller can be a monotonous and routine job. Of course, that routine and monotony can be interrupted by periods of high activity accompanied by abnormal or emergency events. That is exactly why the method needs to involve each controller and why it needs to include an emphasis on response to both abnormal and emergency events that necessitate alarm response and the use of procedures as a result of those alarms. A successful juggler keeps all objects moving; a successful controller knows what tasks to prioritize at a particular time and what tasks to delay until a later time.

One of the reasons for the CRM requirements related to controller workload monitoring is because excessive workload might contribute to operational errors and/or pipeline accidents. Here are excerpts from two accident reports where controllers might not have had sufficient time to analyze and react to incoming alarms. The first is from the NTSB Pipeline Accident Brief Gramercy, Louisiana 1996:

  • The pipeline controller continued to receive alarms. Initially, he acknowledged each one individually, but believing that each subsequent alarm was related to operations at the refinery, he elected to simultaneously acknowledge all the alarms and the alarm text messages without attending to the nature of each alarm. The controller said he had anticipated a positive differential line balance alarm because of the shutdown of the pumping units. He said he therefore did not read the full alarm message on the SCADA screen and consequently did not notice that the line balance alarm was reporting a negative differential.

The second is from the TSB of Canada Pipeline Investigation Report Buick, British Columbia 2012:

  • As a result of multiple inputs and alarms relating to other events, the specific alarms that followed the rupture were not responded to in a timely manner. If excessive workload of system controllers is not properly managed, there is a risk that emergency response will be delayed.

Let’s agree to monitor our activities so that the work of controllers can be done in ways that assure pipeline safety and provide personal satisfaction. That is what is important to me. Although each of us may have different roles, the tasks we perform and the services we provide should contribute to operational excellence and improved performance.

Charles Alday © 2015 Please Distribute to Others.

Sign up for our Newsletter