I attended the Introduction to CMMI 1.2 course, I learned that the goals only are mandatory and practices are expected. Last week I attended a formal appraisal, we mapped each practice to a direct evidence and indirect evidence, so in reality the practices are taken as mandatory.
In order to skip some practices you should apply alternatives and provide rationale behind your decision.
The question is, have you meet any situation where practices are skipped in favor of other alternative practices? or can you give me examples of doing so?
Ahh .... the 'ol "SPs are only expected but seem to be required" routine again eh? You're not the only one to make this observation. Some say it's the SEI's attempt at trying to be funny . .. hmmm, not sure they were successful.
While Goals (both SGs and GGs) are "required" and Practices are "expected" it would be impractical to evaluate only the goals, which are pretty broad, without some sort of practices that allow for the collection of detailed evidence in order to be sure they are satisfied.
This "rollup" method appears to be an attempt by the SEI to "standardize" the appraisal method. In other words, a Lead Appraiser may not understand your business and domain enough to really understand whether of not you are performing the "Manage Requirements" Goal satisfactorily, so the SP's are a "map" that will lead them to a conclusion (note to self: don't engage a Lead Appraiser that cannot demonstrate an understanding of your business and domain).
So, the SPs are simply a set of practices that we would expect you to perform in order to satisfy the goal. But the SEI was smart enough (and forward thinking enough) to allow for "Alternative Practices." This was an acknowledgement that maybe, just maybe, there might be another way to approach something that they had not anticipated (unfortunately I've met too many LA's that scoff at the notion that they may not get it . . . but that's another story :)).
Have I seen these "Alternative Practices" while working with clients? You bet! Sometimes it comes in the form of "compressing" practices from different PAs or Goals into a single practice, and sometimes it's just a brand new idea.
One example is the integration of "Configuration Audits" into the PPQA process. The key here is that neither the practice related to configuration audits, nor the practices associated with PPQA, are performed in a "traditional" manner. The PPQA process has to be robust enough to support it, but it is still an alternative way to perform the process (this can really only work if the methodology is "deliverable based" by the way).
Another is estimating and planning using Agile methods. Remember, in the Agile world, scope is flexible while cost and schedule are fixed. In the waterfall world the inverse it true - cost and schedule are flexible (usually grow), but scope tends to be fixed. By definition Agile projects are estimated and planned using releases and iterations as their foundation (not tasks), and "features" are allocated across those iterations in very small "chunks." When the iteration ends, whatever "value" is created is delivered to the customer, the rest is put on a backlog for the next release. This way estimates are limited to: how many people do I have for how many releases?
Of course, the customer has to be on board with this :)