This article demonstrates the workflow for Summary, Lessons learned, Actions, Commitments, and Knowledge base--otherwise known as SLACK. The author believes this process is more suitable for agile development than the conventional Corrective and Preventive Action (CAPA) systems.
This article is for the benefit of Quality Professionals who would like to obtain the benefits of a Corrective and Preventive Action (CAPA) system, but do not have the time or resources to dedicate to the initiative. This is particularly true with companies involved in "Agile Product Development", where there must be a minimum of administration and all of the work must be performed by those actually responsible for the design and implementation, rather than a layer of quality assurance specialists.
"Picking up the Slack" is a term that is often used in team management to describe the practice where the productive members compensate for the shortcomings of their peers. This provides a short-term improvement, but may lead to long-term problems. As an alternative, rather than concealing the shortcomings and missing opportunities for improvement, this approach embraces such opportunities. In this concept, SLACK is an acronym denoting: S-Summary, L-Lessons Learned, A-Actions, C-Commitments, K-Knowledge Base.
After an event or process, it is important to capture the information. A Summary should be recorded within 48 hours of the event so that key details are not forgotten. Unlike a formal CAPA system, this Summary need not follow any structured format, but can be flexible to suit the needs and priorities of the organization. This is critical as we do not want to create a clutter of trivial details that may obscure the vital facts.
From the Summary, the team can derive Lessons Learned. The Lessons will be those items most relevant to the people directly affected. In contrast, a CAPA system uses people separate from the process to allocate and determine the priorities of the situation. Also, while issues from a CAPA system are generally perceived as negative shortcomings, the Lessons Learned can be either negative or positive, allowing the team to not only fix its problems but rapidly adopt successful innovations as permanent practices.
Each Lesson should engender an Action. As a result of a Lesson, something must be done. This bias for action over analysis is consistent with the Agile methodology, and ensures that there is always progress. However in order to deliver the desired Action, Commitments are necessary. By assigning the Action to an individual and setting a specific deadline, the Action and Commitment are powerful change drivers.
The risk of any team is that the departure of key members will mean a reduction in collective knowledge. To mitigate that risk, the final step is to apply the improvement into the Knowledge Base. While a conventional CAPA system mandates the specific method and approach, this method applies flexibility and common sense. In an unstructured environment, Standard Procedures are infrequently updated or referenced, and make a poor repository for current knowledge. Different prompts or reminders (i.e. content of readme files in the directory, comments within software applications, updates to Intranet pages) that apply technology can be used to communicate and entrench the knowledge so that it remains within the team, no matter who stays or goes.
SLACK (Summary-Lessons Learned-Actions-Commitments-Knowledge Base) is a linear model that can be formatted into a simple table or matrix. Below is an example of this application.
|Summary||Lesson Learned||Lesson Learned Action||Commitment||Knowledge Base|
|The product demonstration revealed software deficiencies. The customer was unimpressed and did not purchase.||Demo software should be tested prior to demonstrations||Programmers and testers must test software prior to demo, and indicate usable release.||Testers must create Demo Test Plan within 14 days.||Demo Test Plan to be added to Test Library.|
|Customer expectations should be known before presentations.||Product Manager should perform needs analysis as requirements for demo.||Product|