How to Start With the CMMI

If a private software company wants to do get a certificate of quality for CMMI Level 2, what must this company do in order to obtain Level 2? And also what are the steps that must be followed from the start (initial) to achieve CMMI Level 2 (Managed)?

First let me state that there is no certification of any type for the CMMI. Individual Lead Appraisers will issue something looks like a certificate to the organization that was appraised indicating the SCAMPI A results. But this is not a certification. The only things that the SEI certifies are the CMMI instructors and Lead Appraisers.

Here are the necessary steps for achieving Maturity Level 2 for the CMMI-DEV. These steps are not necessarily sequential, some can occur concurrently.

1. Hire an SEI-certified Lead Appraiser to conduct a Gap Analysis of the company to determine the current process strengths and weaknesses and help the company construct a Process Improvement Plan (PIP).
2. Obtain executive management sponsorship for the process improvement effort.
3. Train the people responsible for the company’s processes and for addressing the action items in the PIP on the 3-day SEI Introduction to CMMI v1.2 class.
4. Address the issues from the Gap Analysis, document the necessary processes and procedures, and begin conducting the PPQA process and work product audits.
5. Allow time for the new and/or modified processes to get some use on various projects.
6. Conduct a SCAMPI B appraisal as a dress rehearsal for the SCAMPI A. Identify any issues and weaknesses that are potential risks to achieving Maturity Level 2.
7. Create a new PIP to address the SCAMPI B identified weaknesses and risks.
8. Address these issues
9. Conduct the Maturity Level 2 SCAMPI A appraisal.

Using the CMMI-SVC to Transform an Organization into a High-Functioning, Customer-Driven Profit Center

For those of you who were not able to attend the 2010 North American SEPG Conference in Savannah, GA in March, here is a copy of my presentation on the CMMI-SVC.

As a company grows and matures from a startup entrepreneurial venture to a sustainable corporation, the departments and company services that begin as good ideas expand and evolve to support the company’s growing business. Many times these services simply develop without any strategic vision resulting in institutionalized behaviors that are incompatible with the company’s business goals and objectives. Consequently, the transition to a larger corporation becomes a challenge. A notable example is a company’s Engineering Services Department.

When people think of Engineering Services, the Customer Support or Help Desk team is what first comes to mind. However, other services such as Product Training, Field Services (product installation and troubleshooting), and Engineering Sales Support may be provided as well.

As a product development company begins selling product, the Customer Support function becomes one of its first service offerings whether or not it recognizes it as such. In addition, it is natural for the focus of the Customer Support function to be on pleasing their customer base, as many sales are contingent upon repeat business and word of mouth until the company and its product line become established in the marketplace. Nevertheless, without a clear idea of its charter and strategic direction to support business growth and identify new markets and service offerings, the Customer Support Specialists focus instead on supporting their customer base on non-company and non-product issues and questions that consume internal resources without any tangible benefit to the company. Once a company starts banging its head on the “glass ceiling” as it attempts to grow, the leadership may recognize that its current Engineering Services approach does not support its strategic business goals and objectives.

In these circumstances, the company is not necessarily interested in implementing the CMMI for Services (CMMI-SVC) and becoming appraised to either Maturity Level 2 or Maturity Level 3. However, by using the Continuous Representation, the CMMI-SVC can provide the needed guidance to help a company restructure and reorganize its Engineering Services approach in order to become a profit center or revenue generating function.

In this presentation, we will present a case study for OMNI Flow Computers, Inc., a company that specializes in the design, development, and manufacture of panel-mount multi-run, multi-tasking liquid and gas flow computers, and field-mount, hazardous area controllers/RTUs for liquid and gas custody transfer metering systems. The challenge facing OMNI was to develop its Engineering Services Department into a high-functioning, customer-driven profit center. OMNI’s Engineering Services Department consists of three groups: Customer Support, Training, and Engineering Field Services. Customer Support handles customer questions, concerns, and issues. The Training group provides training on the OMNI product line to its customers and users. Engineering Field Services provides on-site troubleshooting services on an as-needed basis.

As the Training and Engineering Field Services groups were recent additional capabilities, Customer Support presented the biggest obstacle to overcome. Noted management consultant Peter Drucker declared several years ago that Quality in a service or product is not what you put into it. It is what the client or customer gets out of it. Moreover, an obstacle to achieving this objective was one of the core challenges faced by the department: developing an appropriate customer focus and developing new service offerings. A major reason for these challenges is the nature of OMNI products. OMNI's customers integrate their products into custody transfer systems that involve a wide variety of large-scale hardware and electronic equipment from other manufacturers. OMNI’s customers usually develop and commission these systems for their clients and end users. Therefore, when calls come in to OMNI’s Customer Support group, the first challenge they had to overcome was determining if the customer’s issue was actually an OMNI product issue or the result of an external issue. The next challenge was to determine the root cause of the issue, so that the customer would receive a timely resolution of their issue.

Fortunately, the release of the CMMI-SVC came at the right time for OMNI. Of the seven new services Process Areas (PAs), many of the Specific Practices and associated informative material proved useful in guiding the transformation of OMNI’s Engineering Services Department. The Service Delivery PA provided excellent guidance for establishing and documenting Engineering Services’ existing service offerings, ensuring that each group was prepared to deliver the defined service offerings, and delivering the service offerings. The Incident Resolution and Prevention PA provided excellent guidance for identifying, documenting, tracking, reporting, and resolving customer complaints, issues, and other service interruptions. The Service Continuity PA helped focus the Engineering Services Department manager to identify and prioritize the department’s essential functions and necessary resources. The Strategic Service Management PA brought the needed focus to establish the Engineering Services strategic needs and plans for its standard services.

The OMNI Engineering Services Department’s journey is not yet over. They are still growing, maturing, and learning what it means to become a high-functioning customer-driven profit center. However, along the way they learned some valuable lessons. This presentation will discuss some of the pitfalls they encountered, what strategies worked and what did not work, as well as provide some practical advice to aid other organizations facing similar challenges.

If you make customers unhappy in the physical world, they might each tell six friends. If you make customers unhappy on the Internet, they can each tell 6000 friends. - Jeff Bezos

Customer service is not a department. It is an attitude. – Unknown

This presentation provides a case study of a computer manufacturer that used the CMMI for Services to help transform its Engineering Services department (Customer Support, Training, and Engineering Field Services groups) into a high-functioning, customer-driven profit center. Challenges, successful approaches, lessons learned, and practical advice to aid other organizations facing similar challenges will be presented.

Using the CMMI-SVC to Transform an Organization into a High-Functioning, Customer-Driven Profit Center

View more presentations from Henry Schneider.

Process Improvement vs. Process Maintenance

An organization on its process improvement journey may include process maintenance activities under the heading of process improvement. Most organizations do that. As far as I know, CMMI does not talk of process maintenance activities. To me, a few examples of process maintenance activities are those required for metrics data collection, project monitoring, process definition, making plans, etc. On the other hand, process improvement will include activities like metrics data analysis, identifying significant variations from planned arrangement, process re-definition based on improvement suggestions and metrics analysis, revising the plans in line to changing requirements, and taking appropriate preventive and/or corrective actions.

Are there any benchmarks for healthy process maintenance vs. improvement activities for software organizations?

These two concepts in inextricably intertwined. I would find it hard to believe that an organization does not identify any process improvement suggestions by just doing process maintenance. Even if you are just maintaining your Maturity Level, you will still identify improvements to the status quo. And I contend that even for process maintenance you have to perform data analysis, identify variations, and identify appropriate corrective actions, otherwise how would you be able to determine that you are maintaining what you have already achieved? I do not understand the need to define these two items as separate activities. What would be the point of merely maintaining your processes?

Configuration Management - Change Request Number Traceability

I would like your help with understanding the following subject:

A change request is processed in a change control tool. Each change request has a number. If a proposed change is accepted, a schedule is created for making the change.

When it is necessary to store the configuration items modified in the configuration system, we have the option of describing what we have done. We record the implemented changes and the reasons for the changes, however we don't track the change request number.

Will the lack of tracing the change request number create a weakness in the Configuration Management Process Area? Is just recording the historical information about the changes in the comments and using the change control tool sufficient?

How important to your projects and business is it to track the change request number? Have you encountered issues with change control on the projects because you have not maintained this information? Recording and tracking the change request number is a very easy thing to do and I am wondering why you haven’t done that.

What also concerns me is that you imply that recording a description of the change made to a baselined item may be optional. If this is true, then it is then possible for someone to decide not to record this information. Recording the information should be mandatory.

Not tracing the change request number and the possibility of not recording a description of the change sound like high risk items that can cause you difficulties in the future. As a risk mitigation, I would record all change numbers and require that all changes made are clearly described in the event that someone else in the future needs to understand the nature and reasons for the change.

And since you are using a tool, which I assume is an off-the-shelf product, you may in fact be tracing the change request number and not even realize it. But from an appraisal point of view, it sounds like you might have most of Configuration Management covered and the problem you are asking about might be viewed by the appraisal team as a weakness. But is it a Goal breaking weakness? This a question that must be answered by the appraisal team.

Configuration Management - SP 1.3-1 , SP 2.2.-1

I would like your opinion in relation to situation below.

Once a change was been verbally approved, is there some problem in relation to CM SP 1.3 (Create or Release Baselines) - sub-practice 1 and CM SP 2.2 (Control configuration items) - sub-practice 2, if the record of the modification in the schedule and the change control tool are done in subsequent periods until a maximum limit of time of the defined period for monitoring of the project?

Example:

Verbal approval of the change - Monday

Beginning of the work - Tuesday, with storage of the configuration items in the configuration system (without baseline).

Register of the change in the change control tool and record of the activities in the project schedule - Friday

Collection of the progress and effort - Next Monday (weekly Monitoring, all monday)

In advance, thank you very much.

The first problem I see is the verbal approval. Verbal approvals are difficult to document or provide as evidence and over time can be forgotten or misremembered, not to downplay the risks associated by not documenting decisions.

Secondly, since you are asking about the sub-practices, that makes me wonder if you have taken the SEI’s Introduction to CMMI class. If you have taken the class, your instructor should have made clear to you the distinction between the required, expected, and informative components of the model. The sub-practices are informative components and are therefore provided only as information to help you understand the intent of the Specific and Generic Practices and Goals. To be clear, you are neither required nor expected to implement the sub-practices.

If the weekly schedule you described works for your projects, then you should be able to map it to the Configuration Management (CM) Specific Practices (SPs). However, the described weekly schedule sounds like it may have some gaps.

I strongly suggest that you have an SEI-certified Lead Appraiser conduct a Gap Analysis (Class C appraisal) of your organization, especially CM, to determine the gaps between your implementation and the CMMI.

Appraisal Scope Question for Agile Development

I am preparing for an appraisal coming up in a few months and I have run into an interesting question that I would like to ask you about.

Some of the projects in the Organizational Unit (OU) follow an Agile method for development. It is really a modified combination of SCRUM and XP. One of the questions they asked me was whether they would have to provide evidence for all of the Process Areas (PAs) in the scope of the appraisal? I was perplexed by this question because it seemed rather obvious to me, so I replied "of course." But this question stuck in the back of my mind so I dug into the SCAMPI Method Definition Document (MDD) for more clarification.

From the MDD, Method Assumptions and Design Principles, page I-19 and I-20: "The extent to which an organizational unit has implemented appraisal reference model practices can be determined only by considering, in aggregate, the extent to which those practices are implemented within the organizational unit by project and support groups. This process, in turn, necessitates the consideration of objective evidence for each instantiation, for each model practice within the appraisal scope."

This seems fairly clear to me, we must examine objective evidence for all practices of all instantiations within the scope of the appraisal. However, under the process definition in part 2 of the MDD you can find less convincing information under the Parameters and Limits section of 1.1.3 Determine Appraisal Scope. "Sample projects and support groups selected to form the organizational scope (i.e., the combination of focus and non-focus projects and support functions) must represent all critical factors identified for the organizational unit to which the results will be attributed." So it seems that as long as the combination of all focus and non-focus projects represent all the critical factors it should be sufficient. I know, critical factors are different from the PAs in the model scope. :-)

Also, in Parameters and Limits it clearly states: "Focus projects must provide objective evidence for every PA within the model scope of the appraisal..." "Non-focus projects must provide objective evidence for one or more PAs within the model scope of the appraisal..." So it seems that if an Agile project was a non-focus project they would not have to provide evidence for all PAs. Do you think this is correct?

The MDD goes on to further say in the Parameters and Limits: "In appraisals where the reference model scope includes any project-related PA, the organizational scope must include at least one focus project. If the organizational unit includes more than 3 projects, then the organizational scope must include sufficient focus projects and non-focus projects to generate at least 3 instances of each practice in each project-related PA in the model scope of the appraisal."

So, conceivably, you could have only 1 focus project, and say maybe 6 non-focus projects with each only having a few PAs to "generate at least 3 instances" of the practices that need to be covered in the scope of the appraisal.

I know this may seem a bit extreme, but believe me, I have run into stranger scenarios than this one. lol :-)

Ideally, all projects would cover all PAs. But the role and function of non-focus projects really seems to muddy the waters in my opinion.

What are your thoughts?

There is an SEI Technical Note CMU/SEI-2008-TN-003 published in November 2008 titled CMMI® or Agile: Why Not Embrace Both! by Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, and Sandy Shrum that contains a lot of pertinent information about Agile and the CMMI, as well as Hillel's recently published companion article in Crosstalk Love and Marriage: CMMI and Agile Need Each Other http://www.stsc.hill.af.mil/crosstalk/2010/01/1001Glazer.html

In my opinion, if Agile is one of many different development methods in use by the organization and the Agile projects do not cover all of the PAs in scope of the appraisal, then it is not in the spirit of the MDD and non-focus projects to mix and match a number of Agile projects just so there is evidence for all the PAs. The way that I look at non-focus projects is that there may be some projects in the appraisal scope that do not have evidence because the projects have not reached that part of the lifecycle yet, NOT that they are not performing the practice.

And, just because a project is using Agile in a Maturity Level (ML) 3 organization does not mean that they don’t have to perform all of the PAs. There should be evidence available though they may be using terminology that is not obviously mapping to the CMMI. Someone with deep CMMI and Agile knowledge should work with the organization to show them how what they are doing does comply with the CMMI.

High Maturity Reference Books

I would like to read and understand more about High Maturity practices and I am also very keen to develop statistical skills so I will be able to construct a PPM. Can you please recommend some good reference books and/or links?

I would recommend the following books:

“Statistical Methods from the Viewpoint of Quality Control” by Walter A. Shewhart

“Understanding Variation: The Key to Managing Chaos” by Donald J. Wheeler

“Measuring the Software Process” by William A. Florac and Anita D. Carleton

“Building Continual Improvement” by Donald J. Wheeler and Sheila R. Poling

“Metrics and Models in Software Quality Engineering” by Stephen H. Kan

“Practical Software Measurement” by John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, and Fred Hall

These are all excellent reference books to better your understanding of statistical and quantitative thinking.