19625Antwort: RE: [CMMi Process Improvement] Causal Analysis and Resolution at Organization
- Sep 20, 2013Pat, brilliant, as usual.
But please let me add another viewpoint, to stress the "Process Improvement" aspect of the CMMI:
Everybody should perform analysis of problems, searching root causes for issues, and resolve them all the way long. In projects, on organization level, always. Everybody does ist. If you don't do that, you will end in desaster, short term or later.
By setting up the levels, CMMI gives a guideline, WHEN it is important to improve that CAR process. And experience says, that you should try to align project and organizational processes qualitatively, then quantitatively. SG2 in PMC tells you to do CAR, but very lean. MA tells you, to think about measurements (of that CAR process, if necessary).
If problem resolution is critical for project or organization, Level 4 tells you to set up a process performance baseline. Finally, you should try to make that problem analysis and resolution process more effective, and that's where CAR is defined.
But remember as a vision: you do CAR all the day long, as you perform DAR every minute of the day, informally. CMMI only tells you, when and how to improve your process of CAR.
Von: "Pat OToole" <PACT.otoole@...>
Datum: 19.09.2013 21:32
Betreff: RE: [CMMi Process Improvement] Causal Analysis and Resolution at Organization
Gesendet von: firstname.lastname@example.org
Where do I begin…
First, “if a project objective is not met, a project must perform CAR to address a root cause…” The word “must” is overstated. “Root cause analysis,” the words actually used in QPM SP2.3, MAY be used, or some other type of analysis may be more appropriate. Don’t let the model dictate the type of analysis you perform. Use root cause analysis or CAR where it is the best analytical tool, use other types of analyses if they are more likely to yield valuable insight. In addition, because QPM is at ML4 and CAR is at ML5, it is conceivable that an organization is performing root cause analysis without truly have full-blown CAR capability.
Second, “doing a CAR at the project level only satisfies QPM SP2.3.” I don’t understand why you would think that. Remember that performing “root cause analysis” in QPM was just introduced with CMMI v1.3. So in prior versions of the CMMI, CAR at the project level would have counted as CAR, but now it doesn’t? Do you believe that the ongoing capture and analysis of a project’s size, effort, cost, and schedule results is “only” PMC, and does not count toward MA? CAR is CAR, whether it is performed at the project level or the organizational level, CAR is a support process area that should be used to understand and eliminate the root causes of problems (AND to understand exemplary results so they can be repeated on future projects).
Which leads me to my last concern. Using CAR to address QPM SP2.3-related issues is appropriate to heighten the project’s probability of achieving its objectives. But remember that it’s really QPM SP2.1 and SP2.2 that are likely to trigger the root cause analysis in QPM SP2.3. That is, either the statistical data being captured and analyzed by QPM SP2.1 has detected a signal that warrants investigation - i.e., something may be wrong right now, OR the PREDICTED outcomes stemming from QPM SP2.2 indicate that there may be trouble in the future. Whatever the case, QPM SP2.3 provides the means to really understand what is going on and what might be done to address it.
CAR may also be used at the organizational level to evaluate similar data, but in such cases it is typically performed on aggregated groups of data, not on a one-by-one basis as it is when using statistical techniques to manage a project. That is, one might perform Pareto analysis to classify defects, and then conduct analyses on the highly populated classes to PREVENT such defects from occurring in the future.
So root cause analysis/CAR is typically used episodically by the projects to keep the project on track, or to make appropriate adjustments when trouble is predicted for the future. CAR is typically used systemically at the organizational level to analyze aggregated data in a preventative capacity and/or to propagate exemplary practices and outcomes.
One final thought – you really aren’t doing the “R” part of CAR if you are constantly analyzing the same types of things over and over again repeatedly and redundantly – the same types of defects, or the same episodic exemplary outcomes. The “Resolution” part of Causal Analysis and Resolution is to FIX the problem or to PROPAGATE the exemplary practice once and for all, so that you have eliminated that root cause from causing additional problems in the future, and that you have institutionalized the exemplary practice so all future projects that would benefit from the exemplary practice do it as part of their standard way of working.
If you are REALLY performing CAR as the model intends, then you should be able to demonstrate that your quality levels are improving over time because you have ELIMINATED classes of issues from re-occurring and you have INCORPORATED the really good practices that lead to enhanced results – and that’s precisely the kind of evidence that should be provided for OPM SP3.3.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of binhlong@...
Sent: Friday, September 13, 2013 1:31 AM
Subject: [CMMi Process Improvement] Causal Analysis and Resolution at Organization
I have one question related to CAR that needs your help.
During project execution, if a project objective is not met, a project must perform CAR to address a root cause and come up with an action plan to resolve that root cause. Doing a CAR at project only satisfies QPM SP2.3. To satisfy ML5, an organization must perform CAR periodically. Assuming that I want to perform CAR for defects at organization, do I need to collect all defects from all current projects and analyze them to find out a root cause? If we do that way, I repeat unintentially what projects did when they conducted CAR for their projects. Can I treat root causes of projects as outcomes so I just need to gather all root causes from projects and only analyze common root causes?
ESG Elektroniksystem- und Logistik-GmbH
Rechtsform/Legal Form: Gesellschaft mit beschränkter Haftung
Sitz/Registered Office: München
Handelsregister/Commercial Register: Registergericht München, HRB 8130
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Mario Paoli
Vorsitzender der Geschäftsführung/CEO: Dipl.-Math. Gerhard Schempp, Geschäftsführer/Managing Director: Dipl.-Kfm. Götz Graichen
- << Previous post in topic