Implementing CMM: The people perspective

Organisations need a judicious mix of people, processes and tools to get work done. In early stages of their evolution, organisations may rely more on people with little dependence on processes and as they mature, implement processes to balance out their dependence on people.

Process frameworks, such as the software CMM, help in implementing processes as per international best practices. Setting up these processes and getting assessed or certified is the easy part. Unfortunately, getting people to participate enthusiastically in process improvement is entirely another matter!

Real benefits can be achieved only if people embrace a process approach in daily work and genuinely believe that process improvement will directly benefit them by helping achieve their goals.

So do go through the article....


 Best practices

The software CMM is a process framework focused on software projects incorporating the best practices found in successful software companies. These best practices are bundled together and presented in a five-layered model of process maturity.

The real strength of the CMM comes from the fact that the model mimics the ability of humans to learn from their experience and to store this information for future use. Shorn of technicalities, the five levels of maturity defined by the CMM are:

Level 1—The organisation depends mainly on people.

Level 2—The organisation implements basic processes at the project level. New projects can repeat the performance of previous projects.

Level 3—The organisation learns from the experience of its various projects and creates organisation-level processes. New projects use the organisation’s process repository and improve upon it with their own experience.

Level 4—The organisation learns to manage with numbers using data from past experience. It creates metrics baselines, which can be used to estimate, predict and establish goals. The baselines get refined with every new project experience.

Level 5—Organisations use knowledge from past mistakes to prevent them from happening in the future. They try to understand and eradicate the root causes of defects and create defect prevention repositories, which could prove useful to others in preventing mistakes in the first place.

Learning organisation

In essence, an organisation implementing a CMM level 5 quality management system is on the road to becoming a learning organisation. Working in such an organisation should be sheer joy!

However, it’s unfortunate that many people still treat the CMM as just another manifestation of the Quality Department’s efforts to make them do additional work for some form of certification.

The root cause of this attitude is that, while implementing the CMM, we often forget that process is not an end in itself. It is a way to enable people to do their work efficiently and effectively. People would enjoy working in a process-oriented learning environment if only they understood the essence of what they are doing and felt empowered to use and improve the system. Some best practices to ensure people align with the CMM are discussed below.

At the heart of the programme there should be training for people to understand the ‘essence’ of the system. People need to be told the ‘whys’ and ‘hows’ of the framework and not simply ‘what’ is expected from them. Training should enthuse people by focusing on how you can learn from and contribute to the knowledge repositories i.e. organisation processes, numbers and common causes.

Initiating changes

People must feel empowered and encouraged to initiate changes in the system for enhanced effectiveness and the process to request this change must also be simple and well understood. The change team, which manages the repositories, usually called Software Engineering Process Group (SEPG), should be drawn from the projects and supported by a few process consultants. Most crucially, the change team needs to move fast to implement changes suggested by people as nothing dampens the spirit of learning more than slow and tardy implementation of change requests, owing to elaborate document control procedures.

The metrics programme is a common ‘party pooper’. Nothing puts off people more than having to measure something they cannot relate to. Selection of standard industry metrics and applying them across the board only turns away people from using numbers. In the software services industry, diversity is a fact of life. Projects differ from each other, not only in what they deliver but also in how they deliver. The design of the metrics programme must take this diversity into account and ensure that measurements at the project level not only make sense to the team but also are relevant in that context.

Cause and effect relationships

People must see a clear linkage between their use of the system and the success of the organisation. This involves establishing cause and effect relationships between business goals and benefits of using the process. For example, growth of business in existing accounts has a direct relationship with a happy customer. Therefore, management needs to reinforce the link between on-time-defect-free-delivery, customer delight and growth in the account. Needless to say the metrics program should be designed to establish this relationship.

The defect prevention program is often viewed as additional work. Project teams under delivery pressure are keen to resolve a problem and move on. Carrying out root cause analysis seems like extra work, not relevant to the current project. Without this activity, the knowledge in defect prevention repository remains shallow and people do not find much use for it. Setting up a defect prevention team under the SEPG to periodically facilitate defect prevention activities with project teams can help to break this Catch-22 situation. Once people start using the repository and find it useful, they will start contributing to it on their own.

Finally, the Quality function needs to re-invent itself as a facilitator instead of the frequently viewed position of an auditor. The process group and QA folks play a key role by establishing a link between projects and the function. The function itself must go into communication overdrive. A monthly newsletter can do wonders. Establishing a help desk where anyone can call in with a question or a request for help in using the system is another great enabler!

To conclude, the success of any initiative is directly proportional to the enthusiasm it can generate in the people who use it. The CMM is a great learning system. It has a natural affinity to people’s desire to grow. It, but naturally, would be most beneficial to organisations to put people at the centre while implementing such a system.