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 Manager should create a Needs Analysis prior to next trade show.||Needs Analysis for Demo to be added to Sales Binder.|
An additional benefit of this approach (besides the logical workflow and simplicity), is the ability to monitor progress continually. Successive processes that have applied the correction, or implemented the innovation, can be tracked and confirmed (or refuted as the case may be) to obtain a longer-term benefit. As new Lessons are learned, the criticality of those lessons can be inserted into the existing S-L-A-C-K matrix (SLACK-tracking).
An approach like this can be applied in situations beyond product development. For example, Vendor Management is an important consideration, as more products are integrating solutions and applications from third-parties. As a consequence, the reliability and functionality of the product is limited by the shortcomings of negligent or deficient subcontractors.
To mitigate supply chain problems, purchasers can use the S-L-A-C-K method to bring their vendors up to the level needed to ensure quality and consistent performance. After each purchase or delivery, a Summary can be captured to track the problems as well as the unexpected innovations. Lessons could be applied, not only to that particular subcontractor, but to any vendor providing a similar product or service. The purchaser can coordinate the Actions and Commitments with the vendor as a condition of continued purchase, and the changes could be applied to the Knowledge Base by expanding the details for contracts and purchase agreements.
The example below shows in a very brief way how the proper and timely tracking of a product delivery issue can be constructively applied to justify the modification of receiving and billing practices, and can set expectations for future purchases. Capturing this information will support consistency across the organization. When this is leveraged, addressing the smallest of issues or improvements can have a positive cumulative effect of 10-25% of costs, which may be the difference between loss and profitability.
|Summary||Lesson Learned||Lesson Learned Action||Commitment||Knowledge Base|
|The delivery of the computer hardware did not include the correct service releases of the operating system, making it unusable without extra configuration.||Instruct the purchaser to install the operating system and service pack prior to delivery.||Specify the acceptance criteria for hardware to include O/S components. Get vendor commitment to deliver.||Purchasers to assign a value and deduct time and material charges if software is missing at next order.||Revisions to purchase order and contract. Update vendor file. Revision of pricing and penalties for vendors.|
|Allocate time for systems configuration as a buffer.||Project Manager needs to add systems configuration to the workflow.||Product Manager should create a revised project template for next shipment.||Modification of project plan to add activity. Add to QA checklist for part.|
To summarize, this is a method that is consistent with nimble project management approaches like Agile. It is simple enough to be applied by anyone on the team without the intervention or facilitation by a dedicated quality practitioner. It also provides coverage of this important area which is necessary for Continual Improvement. Next time your project or process has shortcomings, Pick up the S-L-A-C-K!
- ISO 90003:2003 Quality Management Systems–Guidance for Software
- Software Quality Project Management–Futrell, Futrell, Shafer
- Agile Modelling: Effective Practices for Extreme Programming and the Unified Process.
- 21 CFR 820.100 Corrective and Preventive Action System
- CSSBB Primer–Quality Council of Indiana