http://blog.rawsthorne.org where solutions architecture meets instructional design methodology Thu, 09 Sep 2010 15:10:53 +0000 http://wordpress.org/?v=1.5.1.2 http://blog.rawsthorne.org/?p=59#comment-5 Thu, 09 Feb 2006 05:04:43 +0000 http://blog.rawsthorne.org/?p=59#comment-5 Peter, this is an article I wrote about drafting a Corrective And Preventive Action System for Agile. Presently this area is not covered so I thought I would give it a try. __________________________________ This post is for the benefit of those 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 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). 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. http://blog.rawsthorne.org/?p=46#comment-4 Fri, 18 Nov 2005 18:55:25 +0000 http://blog.rawsthorne.org/?p=46#comment-4 You should check out Ray's new blog too ... http://spaces.msn.com/members/rayozzie/ http://spaces.msn.com/members/rayozzie/]]> http://blog.rawsthorne.org/?p=41#comment-3 Sat, 05 Nov 2005 10:34:41 +0000 http://blog.rawsthorne.org/?p=41#comment-3 Even though your learning fast and forgeting fast I think some amount of powerful residual knowledge remains. Wisdom, intuition, gut feelings I think these are the meta-storage mediums we use. I haven't followed that intelectual capital link yet but I will check it out.