A cause and risk calculcation example for lessons learned is shown here. Source: IBS America


Advanced Product Quality Planning (APQP) and Production Part Approval Process (PPAP) activities can be likened to the Herculean task of cleaning the Aegean stables translated into the world of quality systems.

There is never enough time or enough people to apply to the various tasks and it can seem to be so endless that mere completion and survival of a project is a significant cause for celebration.

Given how much energy and time is absorbed by the primary tasks colleagues, management, compliance auditors and customers are eagerly demanding, how much real gusto and commitment do employees have left for the more nebulous APQP tasks such as lessons learned? Is it approached as a value-added activity with real potential for future projects or is it just another tab in the PPAP binder?

Assume the “lessons learned” process sits somewhere on the low side of robust and value-added for this particular set of activities. What makes for a successful, value-added lessons learned process, and what will it take to adopt some of what is considered best practice?

Lessons Learned

Most organizations try to document what they learned during a project rather than lessons to potentially be learned from the experience upon analysis and reflection.

If employees pull back and look at what did not go well and what was unanticipated, resulting in a series of unplanned reactions and actions from the team, it opens up their thinking. Consider not only what was learned but also what can be learned for the future.

Remember that the organization is not trying to establish a set of requirements with this process but rather a backward and forward looking analysis of issues that take into consideration the future needs of engineers and technology among other criteria.

Framework and Timelines

When do employees begin documenting potential lessons learned? Who documents them and what sort of frameworks can they potentially use?

A lot of organizations simply add a column or two to design and process matrix documentation that permits operators to log potential lessons learned and responsible parties against the various line items.

One group in NASA uses a format that includes the headings “Design Flaws” and “Technology Surprises.” This is a good framework for allowing people to begin the process of logging lessons learned early in the program. It is important to remember this is the beginning of the process and not the complete process. This method used alone has potential taxonomy-based flaws inherent in the approach.

First, taking a one-to-one approach of process or design line item to potential lessons learned eliminates the ability to triangulate root causes that can be discerned from a pattern of causal clusters that have impact, positive or negative, on multiple line items.

Starting granular and then moving through a comprehensive review and analysis of the resulting information and supporting data for the whole project-related body of work takes organizations to that next level.

This shows action details, which may help operators quickly understand the situation. Source: IBS America

Selecting a Tool to Support the Process

The ultimate effectiveness for potential lessons learned depends on a single, central, accessible repository of data for granular logging of potential lessons, supporting records and data. This repository also would contain the final completed review, summary and recommendation report.

This central accessibility is all but impossible with conventional paper-based systems. Items end up scattered and filed away in various cabinets or in a project binder that can be accessed by only a few folks at a time at a single location. It also is difficult to quickly create understandable and accessible links and associations to supporting data and records such as inspection and test results, nonconforming material reports and the all-important completed 8-Disciplines problem solving, among others.

There are several software applications available to help bring access, coherence and order to all this information. Some are designed for APQP functionality and some are designed for project and documentation management but function well in support of this particular process.

At a minimum, the software selected should allow operators to:

  • Control access.

  • Confirm authorship and dates for entries and actions.

  • Permit attachment and links between supporting data and records to reduce the need for redundant entries and develop a cross-reference index.

  • Establish key dates, reminders and escalation for overdue actions.

  • Provide look-across views for the project that display status and timing, including features such as traffic lighting.

  • The ability to configure and run useful reports that finally turn this data into business knowledge.

    It is amazing how much time and energy is consumed trying to locate and manage all this data before a single recommendation or decision can be made.


  • The Human Element

    A strong case can be made for including different people in the process of analyzing and documenting the final lessons learned in addition to the group that developed the original failure modes and effects analysis and project documentation. Look for people who are patient enough to research issues, sift through data and make those causal connections. Additionally, aim for people who are objective and possess strong written communication skills.

    It is critical to stay fact-based and focused on man, method, machine and materials, avoiding singling out individuals or organizations for responsibility of issues. The people who are in a position to endorse applying resources to address lessons learned will respond much more positively to rational analysis particularly if the project did not go well and the bruises are still fresh.

    Analysis and Conclusions

    Use tools for ranking issues and objectively determining the potential risk associated with not addressing each lesson opportunity. Turtle diagrams, fishbone charts and other tools will help do everything possible to ensure one is addressing the root cause associated with each lesson and accurately assessing contribution of risk in the recommendation and not just higher level symptoms.

    When writing the conclusion and recommendation report it will give those in a position to authorize action a clearer sense of what poses the most serious risks and which actions will maximize positive impact without having to repeat their own independent analysis in most cases.

    Write to be understood by the audience. This is not the time to bury the analysis in techno-speak and needlessly obtuse, complex rhetoric. Management, if they are really engaged, will not be impressed and people with potentially valuable information and insight could be too confused or intimidated to challenge the information or add critical data.

    Conduct a draft review among the people directly involved before recommendations are passed along to management or customers. Time is something that few, if any organizations, have in abundance but it is a necessary element for building consensus. Do not ram conclusions through just to get it done. The output will be substandard and key people will be less open to participate the next time around.

    Do not just list the problems and causes identified with each lesson. Be sure to detail positive benefits anticipated as a result of corrections and improvements.

    The Future

    Correctly documented and maintained, lessons learned analysis could become an important source of information when scoping and assessing risks for new projects going forward. Poor documentation and half-hearted attempts at lessons learned have little value for future projects and are seldom, if ever, referred to as anything but an auditable artifact of minimal compliance.

    Moving beyond a stay-the-course approach to tackling issues head-on can be a real paradigm shift for all levels of an organization. Everyone involved needs to be on board, trained on the process, and have appropriate expectations concerning involvement and results. Do not take this path if management is not prepared to provide feedback, particularly in cases where there are sound reasons certain actions cannot be taken. If these reports are going to be met with silence and inaction then there is no real point to expending the extra effort this will entail. The results tend to build over time providing an extremely useful body of knowledge that can result in lessons both learned and applied and ultimately that will be a benefit for everyone involved.Q

    Quality Online

    To learn more about APQP, visit www.qualitymag.com to read these articles:
    • “Web-based APQP Keeps Everyone Connected”
    • “APQP: Not Just for Document Creation”
    • “Create Alignment Synergy for Core Tools”


    Tech Tips

    There are several software applications available to help bring access, coherence and order to this information.

    At a minimum, the software selected should allow operators to:

  • Control access.

  • Confirm authorship and dates for entries and actions.

  • Permit attachment and links between supporting data and records to reduce the need for redundant entries and develop a cross-reference index.

  • Establish key dates, reminders and escalation for overdue actions.

  • Provide look-across views for the project that display status and timing, including features such as traffic lighting.

  • The ability to configure and run useful reports that finally turn all of this data into business knowledge.