I don't understand CAR - isn't it just preventing issues and defects?

Isn't CAR (Causal Analysis and Resultion) just issue and defect prevention? Why is it ML5?


It’s true that CAR can be applied to “any issue,” but that’s not the whole story. CAR is way more than simple “defect prevention” or “root cause analysis” and this PA is oft misunderstood.

To understand CAR we need to put it into the context of “high maturity” and remember that the quantitative data that we establish and analyze using OPP feeds the data we use to identify the actual cause of the problem, or even the problem itself, that we are trying to solve (sometimes we don’t really know, right?). CAR guides us through the process of the “problem solving process” (e.g.; select data, analyze causes, implement action proposals, evaluate effort, record data). This is much like how DAR guides us through the process of creating a decision making process.

CAR is intended to help us manage a “process lever” that we turn, pull, push and otherwise manipulate to change or adjust the process, so that problems or inefficiencies are avoided, rather than fixed after the fact, by improving the process itself. That “lever” is created and pulled by a grand trio of OPP, CAR, and OID that work in concert to design, create, and pull the process lever that solves our problem. In the end, we update our baselines (OPP) so we know that it is indeed making us perform better. True, it says in the CMMI Intro class that we can use CAR if we are a “low maturity” organization, but then it points out that the benefits will be minimized. So, as you can see, “defect prevention” in high-maturity terms is an integrated process that includes OPP, CAR, and OID. CAR is only one of three important components.

I once worked with a CIO that was unhappy because his “estimate to actual” report on project delivery was all over the map (it was a scatter diagram). After slamming his fist on the table and insisting that it get “fixed” he proclaimed “we need a better estimating process!” And so they went off and spent close to 1 million dollars on developing an estimating process and deploying tools. Guess what? It was the same chart next year. Estimating wasn’t his problem. After developing some baselines and models (using OPP) we learned that Requirements churn was one of the likely causes – and we piloted a number of small, innovative process changes using CAR and OID – all the time updating our baselines and models. We even simulated some outcomes using different process components that were sitting in the PAL already – and guess what? After deployment of the improvement to the process, his scatter chart had the dots all along the mid-line.

So, you see, CAR is most valuable when performed using data generated from OPP. Like many of the other PA's in the CMMI, it's not as simple as one Process Area. You need to think big!

http://www.broadswordsolutions.com/