Saturday, February 9, 2008

I'm new to CMMI 1.2 and I don't understand the distinction between direct and indirect evidence.

I am in my first year of learning CMMI v1.2 and have participated as an ATM on a few appraisals; however, I still have trouble fully understanding the distinctions between direct and indirect evidence. I do not understand why the concept of ‘direct’ and ‘indirect’ flips in certain work/product instances. Why is this, and can you provide some assistance here?

First, welcome to the world of CMMI! It's a fascinating place where the more you learn about it, the more you'll understand how it can help improve software performance.

It sounds like you already know the basics: direct evidence is something that is the direct consequence of a process being performed. Note: these are the things that organizations who are trying to "game the system" create in order to "prove" they're performing at MLx. This, of course, is nonsense. It's FAR easier to just perform the process and accept what naturally falls out of it as the "right" evidence, but you just can't reason with some people!

The formula for achieving a "fully implemented" characterization on a practice is: Direct + (Indirect or Affirmation). So an indirect is not always required.

Indirect evidence is something that corroborates the direct evidence. If a task in a work plan and a meeting invitation on a calendar both refer to a code walkthrough, they are indirect evidence of the code review (e.g.; we planned for it and we invited people). Other indirect evidence may be meeting minutes, notes, and an agenda for the code review.

Using that example for VER SG2 the direct is the code review results and the indirect is any or all of the examples I gave.

When would this be flipped? Well, for VER SG1 we are "preparing" for peer reviews. Part of preparing is planning for them and inviting people, right? So the indirect for SG2 could be the direct for SG1! And an indirect for "prepare" - VER SG1) COULD be the code review results (they happened as planned, so we must have prepared for them).

There is a larger point here - one that will greatly reduce your overhead and increase efficiency. When planning and designing your process, think in terms of these "flipped" and "shared" work products. If you do, you'll end up with 50 instead of 400 artifacts - and your engineers will be pretty pleased about that!

Finally, remember that CMMI isn't about "evidence." We shouldn't create evidence to "pass" an appraisal. We should execute the process appropriately, and the evidence will take care of itself.

http://www.broadswordsolutions.com/

No comments: