A Word from Our CMMI Chief Architect: Sustaining Habit and Persistence – Intentions and Approaches for Implementation Infrastructure (II) and Governance (GOV)

2020/05/04

 
Assuming everyone has read and understands the CMMI V2.0 Overview (you all have read it right? 🤨😃), I won’t bother to repeat the differences between an ad hoc, performed or managed process.  But let’s step back for a bit and ask some simple questions:

• Why do we think processes are so important?
• Are all processes created equal?
• How repeatable, consistent and persistent should processes be?

To answer these questions, it’s important to understand a key difference between an ad hoc process and a managed process—namely that a managed process is “a performed process that is recorded, followed, updated, and made persistent and habitual in its use.” (Reference CMMI V2.0 Glossary).

So what do persistent and habitual really mean in context of the above three questions?  In the CMMI V2.0 model, the term "persistent and habitual" describes the routine way of doing business and following and improving processes that an organization uses as part of its corporate culture. Conversely, when people ignore a process or abandon it under pressure, or if disciplined execution of the process erodes over time, then it is neither persistent nor habitual.

If people continue to consciously follow the process for several iterations, they ultimately transition to the point where they are unconsciously following the process. They no longer need to think about it; it is simply the way business is done in the organization. At this point, the processes have become persistent and habitual, just like brushing your teeth every night before bed, or submitting your timecard to your boss weekly.
 
You should mentor your newcomers to the organization until they too habitually follow the process. Even for a more mature organization, when introducing an improvement, the organization can potentially regress and must consciously establish and reinforce the new or modified habit to achieve performance and improve capability. This means that the project, work effort or organization must identify, address and provide the means, resources and infrastructure for ensuring that the processes they deem important enough to perform the work consistently, with as slight variation as possible.
 
Additional insight into these ideas can be found through exploring two additional Practice Areas (PAs): Implementation Infrastructure (II) and Governance (GOV). These two critical PAs are where the CMMI V2.0 architectural “rule of orthogonality” really becomes important. Orthogonality in math is when two lines are at right angles (90ᴼ), or perpendicular, to each other. 
 
In the CMMI V2.0 Product Suite and architecture, orthogonality is an architectural rule to not repeat content in the product suite, unless that repetition is needed to emphasize an important concept or point.
 
So let’s look at two specific examples of where orthogonality was applied with specific intention. Consider two practices from CMMI V1.3, the prior version of the model:

• Generic Practice (GP) 2.6 – Place selected work products under appropriate levels of control
• GP 2.7 Identify and involve relevant stakeholders of the process as planned.  

Did they go away entirely in CMMI V2.0?  They did not.  They are clear and present in the Configuration Management (CM) and Planning (PLAN) PAs, namely in the following CMMI V2.0 practices:

• CM Practice 2.1 - Identify items to be placed under configuration management.
• PLAN Practice 2.4 - Plan the involvement of identified stakeholders. 

Since a Practice Group Level 2 managed process includes a plan, that plan should identify what items need to be placed under various levels of configuration control, as well as who the stakeholders are and how they are involved. A Responsible, Accountable, Support, Consulted, Informed (RASCI) table is just one of many example activities and work products in the model of how to document some of this information. It’s really that simple.

Additionally, there is not a 1:1 correlation from the GPs to II and GOV (or from other PAs/practices in V1.3). This is clarified in the Introduction Tab of the CMMI V2.0 Practice Mapping spreadsheet; the mapping document purposely does NOT include a mapping from the GPs in CMMI V1.3 to II and GOV, to counter “old” CMMI V1.3 thinking around the redundancy of the GPs and their application to the PAs vs. II and GOV being applied to an organization’s or project’s processes. Some of the “old” CMMI V1.3 practices were eliminated, some were subsumed, and some were completely overhauled.
 
Finally, having heard loud and clear that Partners and customers wanted a new major revision of CMMI and not a minor revision, i.e., V1.4, there are elements in the CMMI model that are simply not backward compatible, and since II and GOV (and their approach) were not in CMMI V1.3, that would be one of those components not fully backward compatible.

So what about those original three questions we were exploring?  Processes are important because they help us to consistently define and then perform and manage the work. And yet, not all processes need to be at the same level of rigor and control.

It all boils down to an organization spending conscious thought and effort on determining what work processes are critically important to their business and solutions, in consideration of their operational risks.  Throw predefined maturity level thinking out the window for a moment, and it helps to shift the thinking to CMMI V2.0 vs. V1.3.
 
Stay tuned for more and submit your requests for future topics to [email protected].