Archive for August, 2010


Coming soon: CMMI v1.3 for Development

August 29, 2010

1      Overview

In a couple of months, CMMI v1.3 will become a reality. This is a welcome development for many as it aims at standardizing the model, incorporating the variations that currently exist between the three different CMMI “constellations” (development, acquisition and services). It also clarifies and (possibly) rationalizes some of the high-maturity practices which in the past have cause problems with interpretation and implementation.

For high-maturity organizations (maturity levels 4 and 5), this is a major evolution as the requirements change significantly from version 1.2 of the product. But, what about the organizations at maturity levels 1, 2 and 3? Appraisals based on the current version (1.2) can continue to be used for twelve months following the release of the new version, and will be valid, as all appraisals, for a period of three years. So, theoretically, this only becomes a major roadblock by the third quarter of 2014. However, the question can be asked now as to whether you want to make the jump to the new version and be one of the early adopters, or let things continue as they are for a while…

I would like to discuss here the differences regarding the most popular version of CMMI: the CMMI-DEV or “CMMI for Development” constellation, at “lower” maturity levels. The lower maturity levels generally focus on the implementation of a manner in which best practices in the organization can be identified and shared in order to repeat successes and learnt from failure.

2      Additional Practices and Expectations

The concepts of IPPD have been moved from being a model addition to be integrated in the core of the model. While this means that IPPD is no longer something optional, it has also been downgraded again into something less meaningful. The original concepts were found in a separate model, within CMMI v1.1, they were inserted into the model as a series of additional process areas that could be included or not. In v1.2, the process areas were downgraded to goals and the goals to practices, while remaining as an optional addition to the model.

In v1.3, IPPD has been taken away as an addition and included in the core of the model. At the same time, the (required) goals have been downgraded to (expected) practices and the (expected) practices have been classified as (informative) sub-practices. The “integrated teams” have been replaced with “teams”. As a consequence, while it may appear that IPPD is now part of the core model, the fundamental concepts that made the strengths and usefulness of the IPPD approach have been so watered down and dissolved that very little usefulness remains. Basically, all that remains is that you should have teams working together.

I do not believe that this should have any impact on any organization moving from v1.2 to v1.3.

3      General and Cosmetic Changes

A number of changes have been included in the new version which should have no impact on the result or the implementation. This includes changing terms like “typical work products” to “example work products” – which may clarify that you are not expected to produce all the products listed, but that these are included to help understand what the practice is referring to and what products one should expect.

Amplifications have been removed from the model. These were examples and clarifications of practices for organizations or teams that focused specifically on engineering software, hardware or systems. In version 1.2, it was considered an improvement to extend the amplifications to include hardware specific aspects; in version 1.3, it is considered an improvement to simplify the model by removing them…

Other clarifications and simplifications include distinguishing product lifecycles from project lifecycles, replacing “work products, measurements and improvement information” with “experience”, updating the glossary and more.

Some new material has been included in the model, this includes references to agile methodologies and architecture-centric development, the notions products, systems of systems, release increments and quality attributes and the long awaited and much needed reference to customer satisfaction.

Some minor changes to the changes to the generic practices include clarification of terms in a few areas. The most noticeable changes in this area are the removal of the high-maturity goals and practices (GG4 and GG5) and the fact that all the generic goals and practices have been consolidated into a single section of the documentation.

This latter change is (in my opinion), the unsatisfactory choice between the three possibilities that were present in the v1.2 constellations: CMMI for Development had the description of the generic goals and practices consolidated at the beginning of section 2, with examples of what this means and amplifications included in each process area; CMMI for Acquisition removed all examples and amplifications from the process areas, leaving the description of the practices grouped together at the beginning of section 2 of the model; CMMI for Services had the layout that has been maintained with each description completed with a long list of additions and clarifications for all the process areas. A consequence of this approach is that it becomes a lot more difficult to find the information within this list of examples which can reach several pages for each practice.

The process area called IPM (Integrated Project Management) has been renamed to IWM (Integrated Work Management).

4      What has not been included

A number of expected improvements have finally not been included in the model:

Requirements development (RD) was to be moved to maturity level 2, which would have been more logical, in line with the reality of most engineering organizations and coherent with the other constellations. This appears to have been dropped.

The project strategy was a welcome addition to project planning activities in both CMMI for acquisition and for services (even though it was unfortunately included in the estimating activities rather than in the planning activities), this has not been included in CMMI for development, leaving the numbering of the identical practices to differ between the constellations for what is supposed to be a shared process area.

I have long been hoping for a reinforcement of the peer review practices. I do not believe that these are given appropriate weight as a goal within the verification: peer reviews can be used for validation purposes as well as for verification, peer reviews are one manner for V&V and should not be a required goal separate from performing verification activities. The description of the reviews is too light to be of any use and I would like them to be expanded into a full process area (at maturity level 3) and included as a generic practice, ensuring that key products in all process areas are reviewed. This will not (yet?) be happening in this release of the product. I understand that there are number of people who would want to see reviews removed completely from the model as they have not understood their potential value. I will file another change request on the same subject, in the hope that it will be read this time around.

A proposal was originally made that some key high-maturity practices, like causal analysis, should be included at lower maturity levels, in a simplified manner. These have been discarded.

5      Conclusion

The value of moving from v1.2 to v1.3 of the model at lower maturity levels is certainly minimal at best. This release does not really correct any weaknesses in the lower maturity levels as the changes are largely purely cosmetic. Few organizations will want to make the investment of upgrading to the new version until they have to perform a reappraisal. The value of being “one of the first appraised in the new structure” may have some interest from an advertising point of view, but the expense and effort to upgrade, get the new training, etc. may dissuade most.

I do not believe that CMMI-DEV v1.3 will significantly revitalize the process improvement industry.

CMMI is a registered trademark of Carnegie Mellon University, Pittsburgh PA, USA


Policy? What policy?

August 15, 2010

Getting started in a process improvement effort is always a challenge. The two most common mistakes that lead to failures are:

1. management trying to make this too simple (“just go and do it correctly”) and

2. engineers trying to make this too complicated (“let’s document everything that needs to be done so that there are no questions”).

In fact, the starting point that we should see if we want to have any real improvement should be management demonstrating that they understand their own role and needs in the improvement programme. The objective of an improvement programme should never be certification or evaluation at CMMI Maturity Level something. On the contrary, the objective should be something useful which can be readily communicated to both the engineering staff and the customers: we want to reduce the number of defects delivered, we want to reduce the cost of quality, we want to reduce the time to market, we want to reduce the overtime… These are all clear business objectives that would justify an investment in an improvement programme.

On the other hand, “implementing CMMI level 3” will rapidly be identified for what it really is: feel-good by bureaucracy.

Any change / improvement programme is a change of corporate culture that needs to be managed, it has to be inspired and led by management. As long as management do not demonstrate and explain what they hope to achieve, they cannot expect results. The policy is the formal enactment of the desire to change the corporate culture and should be a clear explanation, from a management point of view, we to what are the real objectives. Writing a policy is not a simple task and should be performed carefully. A few recommendations on what needs to be done are shared hereunder.

1. The upper management team needs to take time to reflect on the future of the organization. What are they trying to achieve, where do they hope to be in a few years time and how do they believe both their marketplace and their place in that market will change. How will they be perceived and what will make their customers come to them rather than go elsewhere? In order to achieve this evolution, a number of things will have to change within the corporate culture, in the way people work. This is the basis for the policy statement.

2. Document the key features of the previous exercise: what is the purpose of the organization, how does it need to evolve in order to achieve this purpose. As a consequence, what are the expected attitudes, tasks and products that management is expecting from their staff. This should be expressed in real terms. If the management objective is to “improve quality”, there need to be clear definitions of what is quality, what is the baseline and how the improvement is going to be monitored and demonstrated.

3. Identify the key measurements, metrics and analyses that will allow the management team to visualize the change of the culture and ensure that the organization is evolving in the right direction. Identify how these measurements will be used to improve the work practices within the organization and how to ensure that they will not be used to punish people who are not being given the means to do their work. In other words, people whoa re not being given the training, the tools, the time, the budget to perform to expectations should not fear to report their own lack of success, but understand that their reporting will be used to identify the causes of failure and seek to redress them, not to punish or reward the individuals within the system.

4. Identify the reward system that is related to the respect of this policy. Generally, I would recommend a simple explanation that the policy is integral part of the job definition of all people effected by it, and, therefore, it is to be considered in the normal staff (yearly) review.

5. Identify the key roles and responsibilities that will be required to assist in improving the culture of the organization: what is the responsibility of senior management, project leaders, QA staff, engineers, measurement specialists…?

The policy document needs to be produced in a manner that can be read and understood. It should be structured in such a way that there is a clear relationship between the various sections, so that there is a clear understanding that what someone is being asked to do is not just bureaucracy, but the basis for the future development of the organization. The policy needs to be widely communicated to ensure that people understand the contents and are clearly aware of what management expects them to be doing and producing. If the policy is not clearly communicated and known, it cannot be considered as an organizational policy: it is just a document.

One is entitled to expect the policy to evolve over time, however this is not something that should change as frequently as the tools and practices that are used to implement it.

Finally, the policy should be considered as “constitutional law” of the organization and therefore needs to originate and be owned and controlled by senior management. If the “policy” is produced by staff (e.g. the change management staff), management will not feel compelled to respect it themselves, in which case, the staff will rapidly understand that this is just a communication of wishes, but not a real policy – the real policies are the ones that talk about expenses and holidays…

%d bloggers like this: