11. July 2014 · 2 comments · Categories: CMMI · Tags:

In continuation to the earlier article Easily ignored certain key points in CMMI implementation,  this article talks more on misconceptions in CMMI implementation. Misusing the model results in unproductive or unnecessary process, waste of resources, loss of credibility towards upcoming process improvement events and finally frustration and dissatisfaction. These could be avoided through proper senior management attention and clear understanding of the standard/model. The common misconceptions observed during CMMI implementation are explained below.

1. Treating CMM as a fast answer for short-term problems

We have a tendency to reach a Maturity Level ‘N’ soon. Adopting the CMMI will not double the productivity all of a sudden. In fact during the initial period of implementation, there will be negligible improvements or rather we can say that there will be an inverse relationship. But once the improved practices are incorporated into the current development process and sustained these practices, visible improvements are observed with CMMI adoption.

2. Treating CMMI as a standard rather than as a process improvement guide

Days and nights of hard work resulted in the successful completion of CMMI appraisal. What is next? Parties and get-together. We can hear people telling like ‘let us relax now’. But sadly the relaxation period/ break time extends till the next SCAMPI A. And it is often seen companies going down instead of improving after the appraisal, because everyone gets relaxed and next audit is far away, so people tend to move away from the processes that were created with lot of hard work. It is because the improvement efforts were put on the projects in the focus of appraisal only rather than on meaningful long lasting organizational wide improvements. Senior management must pay special attention on the value of process improvements rather than the value of rating.

3. PA implementation team focusing merely on specific PAs

Normally it is observed certain work division in the form of Process Areas (PAs) in the CMMI implementation team. And interestingly these mini teams tend to do exactly that. i.e. they focus on specific PAs. They simply ignore the relationship with other PAs which they are not supposed to do. They prepare and define processes without having any common connection with other processes. These process definitions are written as if a person or a team would perform one process in total isolation from other organizational processes. Another problem is that these PA focused team either ignore the sub practices or implement them literally. They use the CMMI language itself while making procedures or policies. They make process audit Check Lists using the CMMI sub-practices /CMMI terms directly. At a later point of time when these are deployed in the organization, it won’t be easy for the people and customers to tie it to their work. Also these PA focused team tends to ignore the institutionalization aspects of process improvement. CMMI provides more explicit guidance for addressing the institutionalization aspects of processes through its Generic Practices.

4. Treating Requirements management (REQM) same as Requirements Development (RD).

Requirements management, a ML 2 PA, focuses on establishing and maintaining an agreement between the customer and the project team on the requirements. It also covers documenting requirements changes and maintaining bidirectional traceability between source requirements, all product and product component requirements, and other specified work products. However, this PA does not deal with requirements development, the tasks of eliciting the requirement, analysing them and documenting them, and so forth. These tasks are handled by RD

5. Measuring everything, but not the required

We start any new model implementation with high spirit, energy and good support from senior management. But later, most often, less involvement of management is found. They tell like they are not getting any benefit from the system. In other words, process improvement is not visible to them. Implementation team is not able to answer to their questions which are pointing on return on investment or cost benefit ratio. A qualitative answer won’t satisfy them. Here what we need is a reply in terms of ‘useful numbers’. We might be measuring something, but is that required for the senior management/ is that useful for the organization? Most probably we might have ignored those aspects and we simply measured as it is measurable.

6. Considering tailoring as a way to escape from certain defined process

People often apply organizational standard process to different projects uniformly without tailoring. In such cases organizations don’t offer project a choice of process elements with a range of capabilities to select with. Another case is people think that having a “tailorable” process means, one can do whatever he/she wants. At the Defined Level, a standard process is developed for the organization, as well as guidelines and criteria for tailoring this standard process for each project. Each project’s defined process must be adapted in a structured way from the bigger organizational standard process.

7. ML 5 PAs interpreted qualitatively and not quantitatively.

It is easy to interpret Maturity Level 5 Process Areas as qualitative. One can assume that: Casual Analysis and Resolution (CAR) is all about brainstorming causes and Organizational Performance Management (OPM) is about making qualitative improvement. But in fact qualitative improvement is the focus of ML3 Organizational Process Focus (OPF) PA. Maturity Level 5 practices must be built upon the stable ML 4 practices.

8. Hoping a metric or statistics wiz can do it all

Managers often assume that a metrics person can do all Quantitative Project Management (QPM) and thus allowing project managers to focus on their regular day-to-day tasks. But it is primarily the managers’ job to run projects quantitatively and sub processes statistically. It is the managers who have to take base decisions and predict ahead. Definitely metric team can support these managers.

9. Senior managers merely focussing on ordinary project status reviews

Getting full support from senior management is crucial for the success of any new model implementation. The company executives need to be well clear on the advantages, requirements and costs etc. But in majority of the cases, it is found that senior managers are merely focussing on ordinary project status reviews rather than involving in process issues. They often fail to see the value of incremental improvements. CMMI implementation effort must receive high priority and continuous senior management attention.

10. Assumption: No need of training, our team can handle it

Considering the short term cost benefits or so, employees (implementation team) are often imposed to have self-study of the new model instead of a formal training. Ultimately it may lead to wrong interpretations and unwanted results (Exceptions could be there). Implementing a change is never a small thing and it can happen only when the team implementing it is trained to handle the change. So investing on appropriate trainings is always a better move. Managers at all levels , leaders of CMMI efforts and implementation team must have basic understanding of what the CMMI is and how it should be used

11. Assumption: The QA team can take it forward

A common trend that we have observed over years is that project manager does not really take responsibility of process activities in the project and it is left to some QA Manager or Process team. These managers are often forgetting the fact that ‘it is the team effort that brings in real benefits’. If they are not serious about process improvements, how can they expect the team to do it?

12. Assumption: The CMMI mandates wasteful paperwork

The CMMI states often about carrying out an activity according to a documented procedure. This doesn’t mean that we need a number of procedures. Processes are defined to ensure repeatable, consistent and effective output. Defined processes are not intended to be barriers to productivity. Rather than dogmatically applying everything in the CMMI to every project, apply the activities that will add the most value to each project.

13. Appraisal Preparation: Cooking up evidences

When the appraisal date approaches, people are engaged in creating lot many evidences. In fact they are wasting a lot of time chasing down documents. If practices are institutionalized appropriately, the evidence needed already exists. Evidence should never be created to please an appraiser. Artifacts examined must be the real work of the organization

14. Appraisal Interview Preparation : Conducting mock interviews

In many a cases, it is seen some master brain interviewing the appraisal participants / project team and thereby trying to make them equipped for the real appraisal interview. In fact these mock interview sessions will spoil the real stuffs of the team who are actually practicing the processes. Also time to practice for an appraisal takes away the team from getting real work done. Participants should be able to answer the questions because the answers describe how they do their jobs.

15. Thinking that CMMI Institute certifies an organization.

CMMI Institute does not produce any certification as a part of CMMI appraisal. CMMI Institute maintains a database of SCAMPI A appraisal results. An organization can have a certificate issued by the transition partner organization with whom they are associated and not by CMMI Institute

2 Comments

  1. Hi there just wanted to give you a quick heads up.
    The text inn your content seem to be running off the screen in Opera.
    I’m nott sure if this is a formatting issue
    or something to do with web browser compatibility but I thought I’d post to leet you know.
    The style and desihn look greeat though! Hoope you get the problem fixed soon. Thanks

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


1 + = ten

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>