Why Isn't the SEI Implementing the CMMI for Itself?

Why doesn't the SEI use its own model- CMMI for all its different product development and services? Even for SEI projects and program management it is crucial, and they have customers the world over. If the SEI goes for CMMI ML3 Appraisal it will be great for the user community and they can achieve their mission in a planned manner, right?

Do Lead Appraisers & SEI Partners feel that they can benefit if the SEI gets CMMI ML3 (defined Process)?

In such a case, who will appraise the SEI? (sorry for such a hypothetical Question)

As the SEI does not develop software, but delivers services, the CMMI-DEV doesn’t apply. That is why the SEI has not been previously appraised to the CMMI. However, the SEI is now implementing the CMMI-SVC for the services it delivers. This is a good thing and the SEI Partners are noticing some of the improvements. Obviously, by the SEI’s Conflict of Interest policy, a CMMI-SVC Lead Appraiser external to the SEI organization being appraised would have to lead the appraisal team.

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.

CMMI for Modeling and Simulation Efforts

I am interested in applying CMMI techniques to modeling and simulation efforts. I do not mean the modeling and simulation of the software engineering process (I have plenty of information, models etc. on that).

We do modeling and simulation work (e.g. growth of the biofuel industry, migration issues, watershed management) to inform policy makers. We have a grassroots 'best practices' movement and are looking for suggestions, ideas, etc. to improve our process. We do not use 'popular' tools and the niche software we do use is not conducive to configuration management tools etc. In addition, we rarely have a requirements document. We are essentially doing research.

Do you have any suggestions?

In my experience, a pure R&D shop has difficulty implementing the CMMI-DEV because of the free form nature of the environment and work. However, what makes more sense for you to investigate is the CMMI-SVC. It sounds like you are performing engineering or research and analysis services for policy makers.

As you may not have a requirements document for your niche software, you most surely have requirements for the research you are performing for your clients. If not, then you run the risk of having your results called into question.

Therefore, I think that you would be better served by the CMMI-SVC than the CMMI-DEV as it sounds like you may not be doing a lot of development, but instead providing research services.

Application of the CMMI for Services

I am in the process of preparing a "justification" presentation that talks about why the CMMI is important and how it can be applied. Though I have enough material and data to substantiate this, I don't have data that is contextual. I am looking for data, links, or any input that would point me to where the CMMI was applied to a Staff Augmentation organization or a comparison where I can see how each CMMI constellation (DEV, ACQ, and SVC) can be applied (Development Orgs, Support and Maintenance Org, Outsourcing Org, Staff Augmentation Org).

Though I could be wrong here, but I seriously doubt that the kind of information you seek exists at this point in time. Keep in mind that the CMMI for Services (CMMI-SVC) was only released in late February 2009 and the first appraisals to this constellation cannot occur at least for another 2 or 3 months. So there won’t be any anecdotal evidence or case studies available to provide the information you seek. I would imagine that the first opportunity to see any information of the type will be at the 2010 North American SEPG Conference. And since you are asking about applying the CMMI to a Staff Augmentation organization, the applicable CMMI constellation would the CMMI-SVC. There just isn’t a lot of information about its benefits right now, not enough time has elapsed since its release.

Evaluating the CMMI for Services

I'm currently involved in an evaluation of different types of assessments for the area of IT Service Management (ITSM) and therefore challenging the CMMI for Services 1.2 (CMMI-SVC).

A major problem I see in CMMI-SVC, is the disregarded sufficient differentiation of practices over different maturity levels. Maybe I´m wrong with my opinion and someone can help me fixing this mess.

I´d like to give a background for a better understanding o f what I mean:

1. In my opinion many (internal) IT service units in mid-size companies don´t have any official agreements (nor contracts) with their business customer to specify service content, service levels or support. Sometimes these things are partly available and if at all, then often are informally and silently accepted.
2. In such (above) described IT service units you will find quite often an official HelpDesk (mostly official because it´s a specific function within IT) or minimum some guys necessary for service support (like handling service incidents) to keep the business process running.

Now take a look at the CMMI-SVC Process Areas and their associated Maturity Levels. You will find Service Development (SD) at Maturity Level 2 including specific practices:

SP 1.1 Analyze Existing Agreements and Service Data
SP 1.2 Establish the Service Agreement
SP 2.1 Establish the Service Delivery Approach
SP 2.2 Prepare for Service System Operations
SP 2.3 Establish a Request Management System
SP 3.1 Receive and Process Service Requests
SP 3.2 Operate the Service System
SP 3.3 Maintain the Service System

and you will find Incident Resolution and Prevention (IRP) at maturity level 3 including specific practices:

SP 1.1 Establish an Approach to Incident Resolution and Prevention
SP 1.2 Establish an Incident Management System
SP 2.1 Identify and Record Incidents
SP 2.2 Analyze Incident Data
SP 2.3 Apply Workarounds to Selected Incidents
SP 2.4 Address Underlying Causes of Selected Incidents
SP 2.5 Monitor the Status of Incidents to Closure
SP 2.6 Communicate the Status of Incidents
SP 3.1 Analyze Selected Incident Data
SP 3.2 Plan Actions to Address Underlying Causes of Selected Incidents
SP 3.3 Establish Workarounds for Selected Incidents

To come to an end I would expect that it is an essential part of any IT unit to solve service incidents, to fulfill the main goal of the company, and keep the business process working. Therefore I would assign half of the listed IRP practices to Maturity Level 2 and would other way around assign half of the SD practices to Maturity Level 3. The CMMI-SVC therefore seems for me to be not sufficient in differentiating practices over Maturity Levels, and would lead to the conclusion that CMMI-SVC is not useful for Maturity Level determination.

I appreciate any explanation if there is a misunderstandig or if there exists a grain of truth.

Your position is much the same as the kind of statements we heard regarding the engineering practices being at ML 3 in the CMMI-DEV. Just because these practices are at ML 3 does not mean that they are not important and are probably even performed at ML 1. What you have to bear in mind is that the CMMI is a set of process improvement guidelines , as well as the definition and purpose of ML 2 and ML 3. At ML 2, projects establish the foundation for an organization to become an effective service provider by institutionalizing basic project management and service establishment and delivery practices. Basically, ML 2 is about gaining control over the projects and service delivery and that is why there is only one service PA at ML 2. You have to get delivery under control before you can focus improving the other aspects of services like Incident Resolution and Prevention. And at ML 3, service providers use defined processes for managing projects. They embed tenets of project management and services best practices, such as service continuity and incident resolution and prevention, into the standard process set.

CMMI-SVC vs. CMMI-DEV

I have some questions about the CMMI-SVC. As I understand it, the CMMI-SVC is scheduled to be released in March. My company performs IT systems maintenance by adapting the CMMI-DEV to process improvement and conducting appraisals. Of course the CMMI-DEV is good for IT system developement organizations. But I want to know which CMMI constellation, the CMMI-DEV or CMMI-SVC, is a better fit for IT system maintenance organizations. In our case, IT system maintenance provides IT service and maintenance at the same time.

What is the logical basis to switch constellations from CMMI-DEV to CMMI-SVC, especially if the CMMI-SVC is more adequate for IT system maintenance organization?

Also I am now confused about the CMMI-DEV focus. It is only focusing on System development organizations and not System maintenance organizations with the release of the CMMI-SVC?

Some people in my organiztion now think that we have been using the wrong CMMI constellation for our IT maintenance organizations.

Yes, you are correct, the CMMI for Services will be released in March, at the same time as the 2009 SEPG Conference. I think that many maintenance organizations have the same questions and problems with the CMMI-DEV.

The problems arise with the engineering Process Areas (PAs) Requirements Development (RD), Technical Solution (TS), Product Integration (PI), Verification (VER), and Validation (VAL), especially TS and PI. In a maintenance environment, there are not very many opportunities for new development and Technical Solution. The only time that occurs is when there are major changes or updates to the existing product. Then it makes sense to perform the engineering PAs. But the majority of the time the organization is fixing defects, basically delivering a maintenance service. In this situation, it may make more sense to use the CMMI-SVC and its PAs Capacity and Availability Management (CAM), Incident Resolution and Prevention (IRP), Service Continuity (SC), Service Delivery (SD), Service System Development (SSD), Service System Transition (SST), and Strategic Service Management (SSM). It is also possible to blend constellations CMMI-DEV and CMMI-SVC to address both software development and software maintenance.

It is a bit difficult to provide the proper guidance and advice regarding which constellation is the best fit without knowing more information about the specific organization. But in my opinion, I would suggest that if there is very little to no new development work being done by the projects and the organization, then the CMMI-SVC should be examined to see if it provides a better fit for the organization. Being appraised to the CMMI-SVC or CMMI-ACQ is just as prestigious as being appraised to the CMMI-DEV as 16 of the PAs are shared by all three constellations.

And as a final point, there in no change in the focus of the CMMI-DEV with the release of the CMMI-SVC. The CMMI-DEV still applies to the same situations as it always has.