site map Root Cause Methodology and Tools for Improved Operations
Home
About TapRooT®
Course Info
Summit Info
Software
Equipment Troubleshooting
Weblog
Store
Support
Contact Us

Archive for February 6th, 2008

Columbia Gulf Transmission Co. Natural Gas Pumping Plant Hit By Tornado - Catches Fire

Wednesday, February 6th, 2008

A line of storms and a tornado may have set off a huge fire at a natural gas pumping plant in Tennessee.

 Photos 1980 01 01 9888148 311Xinlinegallery
(Not a sunrise, that’s the glow from the fire!)

Would this qualify as a “Sabotage/Natural Disaster” category on the Root Cause Tree®? check your Root Cause Tree® Dictionary before you answer!

For the story about the fire, see:

http://www.chron.com/disp/story.mpl/nation/5517482.html
http://www.wtopnews.com/?nid=104&sid=1339964

http://tennessean.com/apps/pbcs.dll/article?AID=/20080206/NEWS01/80206104

Job Opening: UK - Parity - Network Engineer - Needs Root Cause Analysis Skills

Wednesday, February 6th, 2008

For information, see:

http://www.computerweekly.com/jobs/job/network-engineer–10338586.htm

Job Opening: Clarksville, MO - Holcim - Reliability Engineer - Root Cause Analysis Skills

Wednesday, February 6th, 2008

Holcim (US) Inc has an immediate opening for a Reliability Engineer in Clarksville, Missouri.

Specific responsibilities include management of the preventive/predictive maintenance programs (Inspection, Vibration, Oil Analysis, NDT, thermography) to ensure optimum equipment availability; preventative maintenance work order system with coordinated execution of the maintenance teams; analysis and elimination of repetitive problems through root cause analysis, Pareto analysis, statistical review, FMEA and similar techniques; and facilitation of continuous improvement processes around equipment availability and reliability.

For more info see:

http://maintenancetalk.com/blog.php/viblog/reliability_engineer_clarksville_missouri/

NRC & Operator Integrity - Could This Happen to You? - And What is the Root Cause?

Wednesday, February 6th, 2008

Article about an actual event written by Mark Sharp:

What Was I Thinking?

“… former senior reactor operator who mistakenly entered incorrect information into a plant computer during a maintenance operation on Nov. 8, 2006, and subsequently attempted to cover up the mistake by falsifying the record…” NRC news release, October 22, 2007

After 25 years of working in the nuclear power industry in both operations and operations training, you would think that I would have had a handle on operator fundamentals. Self-checking, placekeeping/logging, and error reduction techniques were a part of my every day activities. One of these fundamentals, the trustworthiness and honesty of the employees, became a stumbling block for me one night in the early hours of the morning. Before I can talk about that, I need to give you some background information, including some aspects of human performance/operator fundamentals that need to be reviewed and that could be applied to all nuclear plants.

The multi-unit site I was working at requires a few manual inputs into the plant computer(s) for maintaining the secondary calorimetric up to date. One of these inputs is to account for the Steam Generator Blowdown flowrate from each steam generator. Every time you change the flowpath, and thereby the flowrate, you have to update the computer with the Engineering supplied flowrate constant. This maintains the secondary calorimetric indicated power equal with actual power level. Optimum plant power levels can then be maintained without exceeding limits.

So, what happened that night shift back in November 2006? Following maintenance, our crew was tasked with restoring piping associated with the Steam Generator Blowdown heat exchanger. This would require realigning the blowdown flowpath. Following the required alignment, I made an error in pulling the Steam Generator blowdown constant number off of the operator aid (multiple column/multiple rowed 3” x 4” card) taped to the side of the computer screen and inputting this wrong number into the computers. I also logged this same incorrect number into the constant change log book. The person performing the independent verification (IV) of the action failed to identify my mistake.

(more…)