As Welsh singer and septuagenarian heartthrob Tom Jones might say, "It's Not Unusual" for organizations to have lists of preferred suppliers, or for work to be issued under task orders. This isn't explicitly acknowledged in CMMI Version 1.2. In Version 1.3, some informative material -- not a lot -- has been added under the following specific practices:
OPD SP 1.1 Establish Standard Processes (all 3 models)
SAM SP 1.1 Determiner Acquisition Type (DEV and SVC only)
SSAD SP 1.1 Identify Potential Suppliers (ACQ only)
Example: "Examples of types of acquisition include... obtaining products from a preferred supplier." [SAM SP 1.1, informative material]
Sure, this may sound like small potatoes compared to some other items on this list. Still, it's a nice acknowledgement of a reasonable best practice.
7. Prioritized Customer Requirements
I have a way-too-long list of things to do around the house this coming weekend. So I've prioritized my tasks to make sure I at least accomplish the most important ones... like downloading new music!
Prioritization is not exactly rocket science. However, if you peruse your dog-eared CMMI v1.2 book, you'll have a tough time finding much on priorities (specifically, customer priorities).
This changes in CMMI v1.3, by bringing prioritization to the forefront in RD SP 1.2 and by adding informative material to the following process areas:
CMMI-DEV: OPD, PP, RD
CMMI-SVC: PP
CMMI-ACQ: PP
Example: "SP 1.2 Transform Stakeholder Needs into Customer Requirements. Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements." [RD]
6. Lifecycle Needs and Standards
Perhaps to you, a "lifecycle" is a machine you hop onto at the gym to log your 20 minutes of daily cardio. Well, for Version 1.2 of CMMI-DEV, the lifecycle is focused on development. It doesn't say much about other lifecycles that could be applicable to your organization, such as manufacturing, deployment, operations, maintenance, support, and disposal.
In Version 1.3, Part 1 of CMMI-DEV now explicitly references CMMI-SVC for lifecycles such as manufacturing and maintenance. References to relevant standards have also been added, in the Appendix and in an example box in OPD SP 1.1:
"Examples of standards include the following: ISO/IEC 12207 Systems and Software Engineering - Software Life Cycle Processes [ISO 2008a], ISO/IEC 27000 Information Security Management Systems [ISO/IEC 2009], ..."
5. Customer Satisfaction
The concept of "satisfaction" may figure prominently in a certain Rolling Stones song, but it's rarely mentioned in CMMI v1.2 -- especially in CMMI-DEV. You still won't see customer satisfaction measures required by CMMI v1.3; however, you'll find informative material added to these process areas:
CMMI-DEV: MA, OPF, PMC, RD
CMMI-SVC: MA
CMMI-ACQ: ARD, OPF
Customer satisfaction, and the related concept of customer loyalty, plays a significant role in driving my business -- and hopefully yours as well. The added material is welcomed.
Example: "...Candidate improvements to the organization's processes and process assets are obtained from various sources, including... results of customer satisfaction evaluations" [OPF, Introductory Notes]
4. Causal Analysis at Low Levels of Maturity
At the 2008 NDIA CMMI Technology Conference and User Group, I delivered an impassioned presentation on Using CAR to Rescue a Sinking Process Improvement Program. In my talk, I discussed how I used causal analysis to assist a client organization in solving an important problem -- despite their "low maturity." (I won an award for that presentation, although my friend Angie claims that my skillful inclusion of a shirtless Brad Pitt photo unfairly swayed a few key voters.)
In CMMI Version 1.3, there's now more explicit encouragement to do just that: use causal analysis at lower levels of maturity, without the use of statistics and process performance baselines. To help with this, the Introductory Notes of some high maturity process areas have been revised. Also, a new specific practice has been added to QPM (SP 2.3 Perform Root Cause Analysis), and a few low maturity process areas have been tweaked.
Example: "Address causes of selected issues that can affect project objectives" [IPM, SP 1.5, subpractice 5 (new)]
3. Teaming Concepts
In CMMI Version 1.2, Integrated Process and Product Development (IPPD) is formally known as an addition to the model. Think of it as an option you might add to that yellow Lamborghini of yours, but one that can have a significant impact on your driving. IPPD's use is targeted for complex projects building complicated products. From an appraisal perspective, you could be appraised against CMMI-DEV, or CMMI-DEV + IPPD, although the latter has happened only in about 5% of recent CMMI-DEV appraisals.
What's changed in Version 1.3? The IPPD addition, as well as the concept of integrated teaming, is now gone. A more general concept of teaming has taken its place, making this new approach to teaming consistent across the three constellations. (CMMI-ACQ v1.2 and CMMI-SVC v1.2 already had incorporated generalized concepts from CMMI-DEV's IPPD addition.) You'll find a few new specific practices in CMMI-DEV.
Example: "Establish and maintain teams." [CMMI-DEV, IPM SP 1.6 (new)]
2. Modernized Development Practices
Like the model itself, much of the engineering content of CMMI-DEV is as old as Buddy and Koko combined (ten). Because the other two constellations (SVC and ACQ) essentially used DEV as their starting point, they're similarly lacking.
Version 1.3 has added, or in some cases simply beefed up, concepts such as quality attributes (non-functional requirements or "ilities"), product lines, systems of systems, allocation of product capabilities to release increments, architecture-centric development practices, and technology maturation. Key changes include:
Glossary updates, including new terms and revised definitions
Informative material updates in all three constellations (especially in RD, REQM, VAL, and VER) to bring more balance to functional vs. non-functional requirements (e.g., quality attributes)
Additional informative material updates to address other modern engineering approaches (e.g., product lines)
Minor required and expected content updates (RD SG 3, RD SP 3.2, and SSD)
Example: "quality attribute: A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterized by some appropriate measure. Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture."(Glossary)
1. Agile Interpretive Guidance
Say the word "Agile." Great! Now say "CMMI." Super! Quick question: which sounds sleeker... smoother... sexier? Even the authors of the CMMI would have to admit they lose that battle every single time!
Now, I certainly can't claim to be an agile expert, based on the fact that once-upon-a-time I read a book and then I kinda-sorta applied it. (Along with a dose of the CMMI for Services, though, it did help to turn my little company around.) But I'd be a fool -- and so would you -- to ignore the fact that agile methods such as Scrum have taken the development world by storm in the past decade. Yet, agile developers often don't see how CMMI can help them. Reasonable people have said it can, and publications like CMMI or Agile: Why Not Embrace Both! have explored the ability of CMMI to compliment or improve agile methods.
CMMI-SVC: SSD
CMMI-ACQ: AM, ATM, PMC, and PP
- Agile interpretive guidance
- Modernized development practices
- Teaming concepts
- Causal analysis at low levels of maturity
- Customer satisfaction
- Lifecycle needs and standards
- Prioritized customer requirements
- Organizational-level contracts
For more detail:
