About 15 months ago, Denise Robitaille and I met for lunch. Denise was explaining how she helped her clients implement a reasonable corrective action program. I explained how I'd helped some of my clients figure out what was really wrong when they had problems. We were struck by the similarities of our approaches. So, we wrote a handbook together.
Here's an example of how I've used this approach. A client was convinced that the testers took too long to complete testing, with the result that the testing was slowing down the release cycle. We first defined the problem statement to avoid blaming the testers, and then collected some data about who was finding defects and when. We discovered that for one product, the defect arrival rate was a hockey stick.
When we investigated why the defects arrived late, we found that the project manager wasn't managing the project, that the developers never knew which requirements were top priority, that the developers performed no peer review or other early defect-catching techniques. In fact, the testers were doing as good a job as they could.
For another product, we found a more even distribution:
The test time was still long, and the testers were still finding more defects than the developers had, but they had many fewer defects escape the release. This project manager had no release criteria, so the entire project was held hostage by the senior manager who kept requesting more data about the product state before he would allow release.
They had other projects with different problems. For one product. The testers hadn't learned about combinatorial test techniques, so they did take longer than necessary in the test part of the project. If they had stuck with their original problem statement, that the testers took too long for testing, they never would have seen each project's root cause, and would have been unable to take appropriate corrective action.
Corrective action involves defining the problem, gathering data (quantitative and qualitative) to understand the root causes, developing a plan (and obtaining buy-in for that plan), executing the plan, verifying that the plan worked with appropriate results, and then closing out the plan. This handbook helps you do so.
Thank you to Christian who explained to me that shrinking an image, specifying a specific size works much better than percentages.