One of the criticisms I've heard about CMMI from Ivar Jacobson is that just because you have a highly mature (e.g. level 5) process doesn't mean it's better than someone else's level 2 process. Of course, this begs the question of what constitutes 'better' - for a particular business purpose, what's right for one business model and scenario might be completely wrong for another. So in general, I think Ivar's right - the CMMI is a model for maturing a capabitility for continuous improvement, but you could be level 5 shop and produce a very low quantity of high quality code per period of time, when your business situation really needed a high-output, 'good-enough' approach that agile methods are so popular for producing. This is why a 'one size fits all' model does not work very well. Of course, it also just might be that the level 2 shop producing the higher quantitity of code could be producing the wrong lines of code, and might not have the foundations in place to get better from where they are, but Ivar isn't really making that point, believing that focus and good intentions will help most groups to do the right thing.

One way to unravel this seeming dicotomy is by exploring what the requirements for good processes should be, focusing on those that generally would be not in debate, because they just represent sound engineering practices. This is one place that I think the CMMI community has missed a golden opportunity, as there is a considerable wealth of good requirements for processes embedded in the CMMI model definition - it's just hard to access and make use of the details of that, given the complexity of the model! Companies often believe they have some proprietary advantage in their own best practices, when in fact the only real benefit they likely have is from knowledge they've been able to extract from applying and tailoring those practices over time. From most company best practices I've seen (and I've seen a lot), the content of those practices generally mirror what's in the body's of knowledge assembled by industry working groups.

I believe there is another way to look at frameworks such as CMMI - as a source of requirements for effective processes. Consider the CMMI itself. First, the model provides for a standardized set of requirements that flow down across all processes and that are essential in order to implement continuous improvement. Unfortunately, it repeats these (in an abbreviated sense) in every process area in the standard, which tends to make the document unwieldy, and the user's frustrated. Second, the model provides an excellent set of specific requirements per process area (see the list for requirements management, for example); each of these is further broken down into 'subpractices' that represent more detailed requirements. Finally, by providing multiple 'paths' to end-points (to be flexible), the model often confuses potential users (see here for good answers about how to unravel some of these mysteries).

This 'difficult to access' problem is why I've begun to implement a capability to browse such potential process requirements through the above links, to allow an easier way to navigate to specific requirements for different process areas, and thus to provide a foundation for the effectiveness of a particular process. Support for a separate assessment mechanism which draws from this material is something I hope to implement as a future enhancement to this material and web site overtime.

Meanwhile, here's an example risk management process that has been developed from such requirements, to demonstrate how they can be used to build a process, and highlight how traceability could be demonstrated to such requirements. I hope to be able to expand this process requirements collection across other improvement frameworks, not just CMMI, so you really could get to a true best practice over time from such a cross-framework suite of requirements.

Satisfying the specific requirements for a particular process area isn't adequate to produce a coherent set of integrated processes that are useable by a community. The generic requirements that form the 'standard set' mentioned above provide the additional infrastructure and features you need for what the CMMI model calls 'institutionalization', which is essentially the management, culture, and infrastructure aligned for improvement activities. Thus, for consistently improving processes, you really need a closed-loop management system that's designed to achieve that. This is where the CMMI can help - by providing an excellent source of requirements to support creation, monitoring, and guiding development of such a management system - but only when the material is made more accessible, and doesn't require a week of training to even begin to understand the model itself!