How Not to be a CMMI Horror Story: A Simple, Scalable Process Architecture for CMMI that Works for Agile Teams, in Small Settings, and Everywhere Else.  Prove me wrong.  Please!!

Every organization implementing CMMI has struggled with the question: "How do we *do* CMMI?"  More to the point, "how do we *do* CMMI so that we don't slow projects down and cost our company dearly in performance and not add ourselves to the long list of CMMI horror stories?"

Horror stories that play out over and over again with cliché predictability.  An internal protagonist stuck with the job of herding cats through an appraisal, an outside consultant type-cast as necessary evil, process that doesn't fit, costs that bleed companies to the brink of life, cynical project teams who've lost faith in the company and don't believe process stuff can work without going bad -- and they're the ones on whom the bad will be going, and apathetic leaders who don't understand what commitment to process improvement means, implies, or looks like.

A common root among horror stories can be traced to one cause: lack of process architecture at the onset.

This session will walk through a simple, scalable process architecture that relies on one thing: Successful companies must be doing *something* right; it's our job to figure out what that is and engineer a process solution to fit that.

The process architecture includes a reality-based series of "cascading life cycles" that describe how projects actually get done.  First, there's the business development life cycle which defines the scope of work for the project.  This business life cycle passes certain attributes down ("cascades", as in HTML style sheets) to the fulfillment life cycle which is chosen by the project to best meet the needs of the business.  The fulfillment life cycle then begets a daily or weekly project oversight life cycle that, similarly, inherits attributes appropriate to the project from the fulfillment life cycle.

In this way, all projects (or so we seem to observe so far) are carried out.  If we can work to identify the three life cycles for each organization, we can then build a process architecture that satisfies not only CMMI, but can be mapped to any other process activity.

This approach is branded "Agile CMMI" because it is an agile-friendly CMMI approach as well as an agile implementation of CMMI.

The true enemy in the CMMI horror story is the "silo" approach to CMMI implementation.  The silo approach lurks in the dark, scheming behind the scenes in unknown and unseen ways.  Preying upon unsuspecting companies and consultants alike.  Luring its victims with the promise of quick implementation, fast appraisals and pre-designed templates.  The real conspirator behind all the madness and destruction is the silo.  It knows that an engineered process architecture is its mortal enemy.

This session will also describe the silo approach and why it is the enemy of all process improvement (especially for small and agile settings).  The session will compare and contrast the silo approach with the Agile CMMI (or cascading life cycles) approach to CMMI, but it will further explain, generically, how engineered process architectures are created and how they arrive at different implementations and better success than the silo approach, irrespective of whether the architecture described in the session is used or not.

The key to an engineered process architecture can be analogous to an integral equation (calculus) where one is literally working to integrate processes into an organization.  In the engineered process solution approach, the equation has the organization's formula for success as the constants and the processes for process improvement as the variables.  By contrast, in the silo approach the organization's formula for success, as the variables, becomes subordinate to the processes for process improvement, as the constants.  When the equation is run, the resulting solution is the organization's process solution.  Only, the engineered solution is far more suitable result than the silo solution.