Our search result was simultaneously encouraging and disheartening. We found not one or two, but three instances where a problem had been identified and “fixed.” The encouraging part was that the data had been entered into the databases in all three cases, so there appeared to be a solid base of captured errors that we could now build on. The disheartening part, of course, was that the problem recurred a second and third time. The first occurred on the first design, the next on the second, and the third on a much later revision.
How did this happen? In all three cases, a design flaw was found after the design had been finalized and frozen, and after the first article sample had been produced, which forced our client to do a costly re-design. With the second and third instances, this costly error should have been avoided, or at least identified and investigated prior to the design freeze.
The portal search results highlighted two important points: Data entries were varied in completeness and accuracy; and once data was entered into the database, it wasn’t accessed.
We now had a set of actions: put a corrective and preventive action (CAPA) plan in place to address the existing but faulty CAPA system and thereby improving the infrastructure; and validate the relative merits of the entries in the system, improving implementation.
We developed a multitiered approach involving the following actions:
• Assess the databases for completeness of lessons learned.
• Consider transferring the information to a newer database, if feasible.
• Develop a methodology to simplify and improve the accuracy of the databases search function.
• Train engineers and managers to review the lessons learned database when beginning a design or redesign, and review it again at major checkpoints.
Company personnel reviewed a sample of database entries for the last two years to determine the significance and quality of the information captured.
Problem: This varied widely, depending on the engineer inputting the information. If the engineer was detail-oriented and had sufficient time, the database captured major and minor problems, triumphs, actions taken, and recommendations for follow-on products. If the engineer entering the data had focused mainly on the big picture, was new to the company, was unaware of the implications of design errors to other parts of the design, or was simply in a hurry to get off this project and on to the new one, the report wasn’t detailed and had little concrete data to support findings and recommendations. Generally, these recommendations weren’t well thought-out and proved of limited or no real value.
Action: Develop a guidance document for lessons learned database input, including examples of complete and incomplete entries. Train all engineers on this procedure and ask managers to hold their employees accountable for complete and comprehensive data input.
Sign In to get started!
