This article writen by one of the originators of LOPA, focuses on problems observed with LOPA. One the biggest issues is that organizations use LOPA without following the rules for LOPA, especially the rules related to maintaining, testing, and record-keeping for each independent protection layer (IPL) and for each "optimized" initiating event (IE). Another issue is that many companies and analysts overuse LOPA. The LOPA book authors expected the number of scenarios going to LOPA (after a HAZOP/PHA) would be 1 to 10% (max) of those uncovered in a qualitative analysis (maybe after 100 HAZOP nodes, you would do 1-10 LOPA). A PHA team would recommend (or use) LOPA only if the scenario was too complex for the PHA/HAZOP team. It appears that most companies are using LOPA for every scenario that has a severe consequence; this result in doing LOPA on much more than 10% of the scenarios. Many times, there is weak definition of the consequence that is being avoided, so an independent layer of protection does not always match up well with the consequence. LOPA is also overworked when it is used. Many of us on the original LOPA book authorship considered LOPA a single analyst job, after a PHA/HAZOP. Instead, the trend appears to be that companies (or perhaps their consultants) make LOPA part of the PHA (in situ), therefore involving the whole PHA team. LOPA is used in PHA team settings, which distracts PHA teams from their primary task of brainstorming to identify the accident scenarios that can occur. This article focuses on preventing these problems and also summarizes the many benefits LOPA has produced for the industry. (C) 2010 American Institute of Chemical Engineers Process Saf Prog 29: 103-107,2010