Thursday, February 12, 2009

CMMI Implementation

I recently joined a company where there is no process and management recruited me to implement the CMMI. The organization has different business units. Though everyone sits together, they work very differently. I conducted a Gap analysis based on the CMMI Level 2 processes and here are the findings:

  1. Project Planning & PMC -- they create project plans and they have the regular project team meetings and they share the minutes. Each team has their own format and templates. The projects don't really do estimations. Can we satisfy the PP & PMC PA'ss without doing any estimation? I know it can't be that way, but can it be tailored?
  2. Requirements Management: Some of the business units have CCBs to discuss change requests and other business units discuss requirements changes in their project team meetings. The most significant gap I found is in Requirements Traceability. Traceability of Customer requirements to the Functional Requirements and Traceability of Use cases to the Test cases are missing. Is this reason enough to fail the RM PA? One of the Engineering directors asked me how much traceability you need to satisfy this condition. At that time I said 100% of all the requirements. Then I also read from somewhere that it is OK to define that we maintain traceability for at least the MUST BE CUSTOMER REQUIREMENTS. Traceability of other requirements can be made optional. Can it be possible like that?
  3. Configuration Management: The projects thought they have a CMP which is embedded in the project plan. What I found missing are the Configuration Audits ( PCA & FCA). Is it possible to satisfy the Configuration Management PA without doing Configuration Audits to check the document status, builds, and backup strategy?
  4. PPQA: One of the business units has a Software Quality Assurance plan, but it is done by one of the testers from another project. As a part of PPQA the SQA will do some spot checks based on a pre-defined checklist, which includes Project Planning, Risk Management, Project Monitoring and Control, Integration and releases. But I guess this can be improved by my role as a independent software quality engineer.
  5. M&A: I am very much worried with this process area, as of now the organization status is nil with respect to metrics collection, they don't have a metrics database and no metrics have been defined yet. Is it OK to start now to form a team to do some reasearch and come up with metrics definitions, deploy them and start collecting data? My question is how much data do we need to collect to satisfy this PA? And do we need to provide evidence of analyzing these collected data and show some improvements steps taken at the time of SCAMPI apprisals? How long will it take in general to satisfy the Measurement & Analysis PA?
  6. SAM: can we tailor this PA if we are not dealing with suppliers? If yes how can it be possible?

The directive from the Leadership team is to acheive CMMI Level 3 by end of 2009. I was baffled to hear this. Under these circumstances, what are the chances of getting CMMI Level 3 or my traget is at least CMMI Level 2? That is what my initial target. Can I acheive CMMI Level 2 by the end of 2009? If so, what are the things I need to address?

Here are some of the things I have already started:

  1. CMMI Overview training to all the teams
  2. Dailogue session on metrics identification
  3. Looking into some Requirements tools which provide Traceability
  4. Need to push the project team to have configuration audits.

In addition we already have established a process data base and the processes are defined and templates are being used from the parent organization. Since our company is a multi-site company, one of our counter parts has already acheived CMMI Level 3. We will be using the same process database and their templates. I thinking of providing their training on each Process Area as well. Is this a correct way to use the processes and templates of our parent organization? If not, do we need to establish our own local process data base?


First of all, I sympathize with you and the challenges you face. I applaud the fact that you had the foresight to conduct a Gap Analysis of the organization. You have highlighted a number of key weaknesses within the organization. However, to provide you meaningful feedback on all of your points would require working directly with you and your company.
  1. What is your CMMI experience? Have you taken the SEI’s Introduction to CMMI class? If not, I strongly recommend that you and possibly those others in your company who are responsible for your processes take the three day class. The class should provide you a more thorough understanding of the CMMI, its interpretations, and material for constructing an internal Overview class.
  2. You have identified some serious deficiencies within the organization in all of the ML 2 Process Areas. These need to be analyzed, addressed, corrected, solutions implemented, and then re-evaluated some months into the future before you can consider a formal SCAMPI at any Maturity Level. The length of time before the next evaluation is a function of a number of factors: number of people in the organization, number of projects, typical project duration, how much time and other resources are dedicated to process improvement, etc.
  3. The organization needs to first implement Maturity Level 2 to form a firm foundation before considering moving to Maturity Level 3. The issues you have identified are fairly typical. Basically, it sounds like your organization does not perform PPQA or MA and is challenged with Project Management, Requirements Management, and Configuration Management. The first steps here should be to identify the necessary skills-based training classes you need to bring in-house and train your staff on these concepts. If you just purchase tools and push for audits, you most likely will not achieve the desired effect. You have to understand your process first and the reasons for why it is important to perform each of the steps.
  4. Since another division has already achieved ML 3, it is a good idea to learn from their mistakes. But be very careful of the temptation to “clone” their processes and procedures. You have to implement the processes and procedures that match the way you conduct business today.
  5. Based on what you have outlined, and given how much time and effort it could take just to address the ML 2 issues, I would say that ML 3 is out of the question for 2009. You could conduct a ML 3 SCAMPI A by the end of this year, but in all likelihood it would not be successful.
  6. The best suggestion I have for you is to hire a CMMI consultant and Lead Appraiser to provide you with the proper advice and guidance. Otherwise, you could be spending a lot more time and effort than originally anticipated.

4 comments:

Derek Vansant said...

You may consider taking a look at Artifact Software. We built an inexpensive web-based software project workspace for managing the entire life cycle of software projects.

We set out to build a workspace that provides a single database for managing project plans, tasks, resources, requirements, tests, defects, change requests, issues, etc. because of the many benefits that come from having a single repository for project data. For example, any and all project artifacts can be linked, including requirements, making traceability through the entire life cycle simple.

When we began we did not have CMMI goals in mind, but we have since noticed more and more customers adopting our software to achieve CMMI goals, particularly in the government space.

If you are interested, you may visit our CMMI-DEV Version 1.2 page.

-Derek

Henry Schneider said...

Hi Derek,
Artifact Software has an intriguing product. Though I do have a bit of an issue when it appears that you can buy a product that will make you compliant with the CMMI. Working with the CMMI is more than just an exercise in documentation and collecting evidence. I contend that the major portion of implementing the CMMI is getting people to accept and follow the documented processes to where it becomes institutionalized in the organization. And the Generic Practices are the indicators of the level of institutionalization. So maybe what your product does is enable the organization to collect and store the necessary artifacts of execution in an easily accessed repository, thus making evidence collection very simple. There a number of other similar products available on the marketplace.

My advice to anyone who is considering acquiring a tool like this is to first understand your business practices and processes. (The same thing that you should do before acquiring any tool.) Evaluate 3 or 4 similar tools and select the one that best fits your needs.

Derek Vansant said...

I could not agree more, and please forgive me if I implied you could simply buy CMMI adoption. Tools are just one component of CMMI adoption, but so are people and procedures.

I think of it as a three legged stool. Without all three, people, procedures and tools, you will fall on your face. Furthermore, the stronger each of those legs is, the better your chances of staying upright.

Henry Schneider said...

Hi Derek,
Thanks for the clarification and knowing that we are on the same page.

In the software development and IT worlds we have long recognized the importance of people, process, and technology and the impact on quality. But usually the process focus suffers.

It is important to focus on the process because it complements your focus on tools and technology. Many people think that if they just have the right tool, all of their problems go away. But a tool or technology in and of itself will most likely not be used effectively. You need to have a good understanding of your work flow to make the best use of any tool or technology.

A process focus also complements your people focus. You can strive to hire the best qualified and most knowledgeable people in the industry, but experience and training are not always enough. You may think that working harder will bridge this gap, but that is not the answer. Instead a well-defined and documented process can provide the means for working smarter, not necessarily harder. And one of the side benefits of a documented process is that it tends to shift the “blame” for the problems you are facing from the people performing the work to the process.