In a recent meeting at a client, a very intelligent conversation took place among seasoned process professionals about their own process improvement efforts. This conversation helped crystallize a thought in a way that's so simple, merely stating it comes across as being so obvious as to leave one wondering why I'd mention it.
So many implementations of CMMI become so NON agile and so bureaucratic simply because when setting out to use CMMI, the organization doesn't have processes/ procedures/ standards of their own, and endeavor (whether knowingly or not) to use CMMI as the
definition of their processes rather than as the model to
improve their processes.
This same misapplication of CMMI can be blamed for so many organizations (and individuals) perceiving CMMI as being a process
method or development
standard. Certainly, this is what CMMI becomes when processes are defined by it, rather than improved by it.
It's this simple: organizations need to
have processes
before using CMMI to improve them! Of course, if an organization doesn't have their own processes, it's a great opportunity to create really great ones when they build the improvement activities (a la CMMI)
into their processes while they're designing/ constructing those processes.
This is what we end up doing with most of our clients, only we're very lucky. Most of our clients don't need us to discover their processes while we're at it, they just have us coach them as to how to re-factor their processes with CMMI as an ingredient.
Labels: Bureaucratic, Construct, Definition, Design, Ingredient, Re-Factor
-200.jpg)
