Make Lessons Learned a Part of Your Culture

An organization with process maturity will close the loop on Lessons Learned.

By closing the loop, I mean that the organization will ensure the capture, distribution, and institutionalization of the lessons taught by the school of hard knocks.

While the Project Manager should identify and collect Lessons Learned, Quality Assurance should categorize and preserve them.  QA should take further steps to communicate the lessons.

First, leaving it to everybody to go searching the LL database does not work.  Like that will ever happen! Ha!

Instead, QA should sort the LLs by function and subject and distribute the information to affected functional managers across the organization.  This ensures that, for example, the Integration Engineers in different programs and at different locations receive the expensively acquired knowledge.  If the functional managers fail to communicate the lessons to their people, upper management should give QA the authority to do so.

Second, QA should incorporate applicable improvements to the Organizational Process Assets.  This way, QA does not merely deposit critical knowledge into the Tribal Knowledge Bank, but actually institutionalizes it.  This introduces accountability when QA audits process compliance.  It also allows the lesson to be moved to a section of the database that lists rationales for historical purposes.  Not every Lesson Learned needs to be researched for normal operations.

Note that this involves Change Control at both the project level and at the organizational level.

As an example, engineers delivered documents to a customer without the necessary review and approval of the Chief Engineer.  The incident led to rework and incorrect customer expectations.

Tribal knowledge had established a channel that would have ensured proper review before release.  However, new employees did not know it, and management had nothing in writing that allowed them to discipline experienced employees who knew better.

Engineering stepped in where corporate management had left a gap.  They instituted processes for document review and approval and for an engineering communications manager to coordinate release of documents to clients.

Thus, an incident led to a Lesson Learned.  The Lesson Learned led to policy and procedural changes.  The new practice became part of the formal procedures and did not get lost in a database that ever researched.

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Understanding the Rule of Seven

Context: Discussion of the Rule of Seven in statistical process control 

Problem: In some industries, one cannot wait for repeatable errors as defects and errors lead to loss of life. I was told that, in pharmaceuticals, a certain % of death is acceptable and almost expected. The waiting process or period of time before halting tests or evaluations is where I am stuck.

First, let's use the terms specified value and control limit rather than errors or defects.

 

Also, we would normally discuss this topic in terms of parameters that have numeric values such as temperature, weight, and speed. In this conversation, we want to deal with measurable characteristics long before they result in catastrophic failures.

Rule 1. Out-of-bound conditions

If you have just one value outside the control limits, such as a severe side effect from a drug, you stop the process and figure out what went wrong. 

Rule 2. Calibrating the results

The Rule of Seven (or Run of Seven) does not apply to parameters that go outside the control limits. The Run of Seven applies when seven consecutive, acceptable values lie on the same side of the specified value. Such a situation indicates that the average has deviated from the desired value and you need to recalibrate the process so that the average is close to the specified value.

Illustrating with a made-up scenario

Suppose the scientists at Schpooky Pharmaceuticals want to test an inoculation against the HG (Heebie Geebie) virus. In order to train the immune system to fight off a full invasion of Heebie Geebies when somebody sneezes on us, the inoculation has to cause a fever of at least 0.5 degree F. They calibrate the variables in making the vaccine and in the dosage to cause a 1.0 degree F fever, or a temperature of 99.6 degrees F.  In this test, they set an upper control limit of 3.0 degrees, or a temperature of 101.6 degrees F.

 

Specifications:

• T = 99.6 degrees F, average
• 99.1 degrees F < T < 101.6 degrees F

Using the first rule, just one person develops a temperature of 103.0 degrees F. We stop the tests to see what's gone wrong because 103.0 > 101.6, the upper control limit.

 

Using the second rule, if we have seven consecutive people develop fevers between 99.6 and 101.6, we stop the tests to see what's gone wrong. These temperatures are all acceptable, but they are all greater than the desired value.

 

The Run of Seven indicates a special cause -- that is, one or more variables in the process need to be controlled. Maybe the dose is too large and needs to be reduced. Perhaps the HG virus needs to be baked five minutes longer. So we make the adjustments and then resume the trial.

 

These rules and others like them serve to stop a process long before it reaches catastrophic failure such as the death of a patient.

But catastrophic failures do happen

You might wonder, What about the catastrophic failures? They do happen! What about the one in 10,000 who dies? How can that be acceptable?

 

This takes us to other techniques such as Decision Tree analysis (p. 299 of the Project Management Institutes Project Management Body of Knowledge (PMBOK) Guide, 4th edition).

 

Suppose withholding the vaccine results in 1,000 deaths per 10,000, but giving the vaccine causes one death in 10,000. If you distribute the vaccine to 10,000, you save 999 lives.

 

Unfortunately, many drug companies withhold such drugs because that one in 10,000 will sue them, and the juries will severely punish the companies.

 

This issue, tort reform, is one of the dividing lines between the political parties in the US. A project manager needs to use various decision-making methods and maintain awareness of a wide range of environmental factors.

Difference between Quality Assurance and Quality Control

Major Differences between QA and QC

The difference between Quality Assurance (QA) and Quality Control (QC) can easily get lost among all the words. Some simple contrasts will help separate the two in your mind.

 

1. QA is primarily proactive. QC is primarily reactive.
 
2. QA focuses on the methods. QC focuses on the results.

 

3. QA uses some statistical methods to analyze how work is done, but QC uses a lot of measurements and statistics to make sure you get the right results.

 

4. QA's scope how the project gets done, whereas QC's scope includes how well the work got done and how well the product or service meet the requirements.

 

Putting those together, Quality Assurance assures you will get the product or service right by making sure the work gets done using the best methods. Quality Control measures and analyzes to control the quality of the product, service, or project execution, and to verify whether it meets the requirements.

 

If you view your studies of QA and QC with this framework in mind, the rest of the differences will make a lot more sense.

 

Example

 

I like food, so let's use a restaurant as an example.  Normally a restaurant would be Operations (not Project), so let's assume that our fine establishment will cater an event and, therefore, Chef Boyardee has a project to manage.

QA (proActive Execution) may find weaknesses in processes or standards due to problems that have occurred. For example, Waiter A wanted to take a break, but Waiter B did not know to whom to deliver the food. We have identified a new stakeholder requirement: Waiters need the ability to hand off orders to each other.

The head waiter improves the process by requiring all waiters to include the table number and seat code for each order. Thus, QA reacts to the problem, focuses on the processes and tools, and enables improvements to the project.

QC (reactive Control) may find a trend indicating an approaching problem. The Chef inspects the food before it is served and notices less steam rising from the tandoori vegetables. Although the food is still acceptable, the temperatures are trending downward.

Before customers start receiving food below the Lower Control Limit of temperature, the Chef determines that the tandoori cook's burners are not getting enough propane. The Chef alerts the cook, who swaps in a fresh propane tank.

Thus, QC Monitored the product, analyzed the data, performed a Root Cause Analysis, and enabled proactive control of an issue before it became a problem.

 

Warnings about Generalizations

 

Remember, "proactive" and "reactive" are generalization to differentiate the two processes. QA (proActive Execution) can be reactive and QC (reactive Control) can be proactive, as well.

Is it safe to say that QA involves polices and procedures ... while QC involves actual work on a product or service?

Yes, as a generalization, it is "safe to say that QA involves polices and procedures ... while QC involves actual work on product or service."

 

One important note: Process and procedure are ambiguous terms, and every organization has its own definitions of them. Both QA and QC can initiate improvements to (processes or procedures).

 

For example, one level of (process or procedure) might instruct personnel to collect the materials and drawings, then have the machinist construct the widget, then have QC inspect it.

 

Another level of (process or procedure) might instruct the machinist how to program the machine, mount the raw materials, push the buttons, release and label the widget, dispose the scrap, and prepare the machine for the next task.

 

From that point of view, QA might perform quality audits to verify that a high level (process or procedure) is being followed, but QC might verify that a detail-level (process or procedure) was followed correctly and with the right results. Both QA and QC involve (processes or procedures).

 

Reminder:  This discussion is just about the major differences. When you look at the details and the ambiguous terms makes it confusing, refer back to the big picture for perspective.