• 
  

	Trinity Management Consultants Limited
	34 Fountains Place
	Peterborough
	PE6 7XP
	01733 222814
The CMMI Technical Reference	enquiry@trinity-cmmi-co.uk

Home Trinity Online Trinity Management Consultants About About the Models Services Model Development Model Acquisition Model About CMMI Process Improvement CMMI Framework Using CMMI Models Representation and Levels Representations Capability Levels Maturity Levels About Process Areas About Generic Goals Glossary Acronyms Copyright and Usage

SVC Key Concepts SVC Process Areas Maturity Level 2 Configuration Management (CM) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM) Service Dellivery (SD) Work Monitoring and Control (WMC) Work Planning (WP) Maturity Level 3 Capacity and Availability Management (CAM) Decision Analysis and Resolution (DAR) Incident Resolution and Prevention (IRP) Integrated Work Management (IWM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM) Service Continuity (SCON) Service System Development (SSD) Service System Transition (SST) Strategic Servive Management (STSM) Maturity Level 4 Organizational Progress Performance (OPP) Quantitative Work Management (QWM) Maturity Level 5 Causal Analysis Resolution (CAR) Organizational Perfromance Management (OPM) SVC Generic Goals GG1 Achieve Specific Goals GG2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assigne Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherance GP 2.10 Review Status with Higher Level Management GG3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Process Related Experiences DEV Process Areas Maturity Level 2 Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurances (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM) Maturity Level 3 Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Maturity Level 4 Organizational Process Improvement (OPP) Quantitative Project Management (QPM) Maturity Level 5 Causal Analysis and Resolution (CAR) Organitaztional Performance Management (OPM) DEV Generic Goals GG1 Achieve Specific Goals GG2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherance GP 2.10 Review Status with Higher Level Management GG3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Process Related Experiences ACQ Process Areas Maturity Level 2 Agreement Management (AM) Acquisition Requirements Development (ARD) Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Solicitation and Supplier Agreement Development (SSAD) Maturity Level 3 Acquisition Technical Management (ATM) Acquistion Validation (AVAL) Acqusition Verification (AVER) Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM) Maturity Level 4 Organizational Process Performance (OPP) Quantitative Project Management (QPM) Maturity Level 5 Causal Analysis and Resolution (CAR) Orgnizational Performance Management (OPM) ACQ Generic Goals GG1 Achieve Specific Goals GG2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherance GP 2.10 Review Status with Higher Level Management GG3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Process Related Experiences

Key Concepts

Understanding Key Concepts in the Use of CMMI for Services The concepts and terms explained so far, such as process areas, capability levels, and equivalent staging, are common to all CMMI models. However, there are some additional terms that are particularly significant in the CMMI for Services model. Although all are defined in the glossary, they each employ words that can cover a range of possible meanings to users from different backgrounds, and so they merit some additional discussion to ensure that model material that includes these concepts is not misinterpreted. Service The most important of these terms is probably the word “service” itself, which the glossary defines as a product that is intangible and non-storable. While this definition accurately captures the intended scope of meaning for the word “service,” it does not highlight some of the possible subtleties or misunderstandings of this concept in the CMMI context. The first point to highlight is that a service is a kind of product, given this definition. Many people routinely think of products and services as two mutually exclusive categories. In CMMI models, however, products and services are not disjoint categories: a service is considered to be a special variety of product. Any reference to products can be assumed to refer to services as well. If you find a need to refer to a category of products that are not services in a CMMI context, you may find it helpful to use the term “goods,” as in the commonly used and understood phrase “goods and services.” (For historical reasons, portions of CMMI models still use the phrase “products and services” on occasion. However, this use is always intended to explicitly remind the reader that services are included in the discussion.) A second possible point of confusion is between services and processes, especially because both terms refer to entities that are by nature intangible and non-storable, and because both concepts are intrinsically linked. However, in CMMI models, processes are activities, while services are a useful result of performing those activities. For example, an organization that provides training services performs training processes (activities) that are intended to leave the recipients of the training in a more knowledgeable state. This useful state of affairs (i.e., being more knowledgeable) is the service that the training provider delivers or attempts to deliver. If the training processes are performed but the recipients fail to become more knowledgeable (perhaps because the training is poorly designed, or the recipients don’t have some necessary preliminary knowledge), then the service—the useful result—has not actually been delivered. Services are the results of processes (performed as part of a collection of resources), not the processes themselves. A final possible point of confusion over the meaning of the word “service” will be apparent to those who have a background in information technology, especially those who are familiar with disciplines like service-oriented architecture (SOA) or software as a service (SaaS). In a software context, services are typically thought of as methods, components, or building blocks of a larger automated system, rather than as the results produced by that system. In CMMI models, services are useful intangible and non-storable results delivered through the operation of a service system, which may or may not have any automated components. To completely resolve this possible confusion, an understanding of the service system concept is necessary. Service System A service is delivered through the operation of a service system, which the glossary defines as an integrated and interdependent combination of component resources that satisfies service requirements. The use of the word “system” in “service system” can suggest to some that service systems are a variety of information technology, and that they must have hardware, software, and other conventional IT components. This interpretation is too restrictive. While it is possible for some components of a service system to be implemented with information technology, it is also possible to have a service system that uses little or no information technology at all. In this context, the word “system” should be interpreted in the broader sense of “a regularly interacting or interdependent group of items forming a unified whole,” a typical dictionary definition. Also, systems created by people usually have an intended unifying purpose, as well as a capability to operate or behave in intended ways. Consider a package delivery system, a health care system, or an education system as examples of service systems with a wide variety of integrated and interdependent component resources. Some users may still have trouble with this interpretation because they may think that the way they deliver services is not systematic, does not involve identifiable “components,” or is too small or difficult to view through the lens of a systems perspective. While this difficulty can in some cases be true for service provider organizations with relatively immature practices, part of the difficulty can also be traced to an overly narrow interpretation of the word “resources” in the definition of service system. The full extent of a service system encompasses everything required for service delivery, including work products, processes, tools, facilities, consumable items, and human resources. Some of these resources can belong to customers or suppliers, and some can be transient (in the sense that they are only part of the service system for a limited time). But all of these resources become part of a service system if they are needed in some way to enable service delivery. Because of this broad range of included resource types and the relationships among them, a service system can be something large and complex, with extensive facilities and tangible components (e.g., a service system for health care, a service system for transportation). Alternatively, a service system could be something consisting primarily of people and processes (e.g., for an independent verification and validation service). Since every service provider organization using the CMMI-SVC model must have at a minimum both people and process resources, they should be able to apply the service system concept successfully. Service providers who are not used to thinking of their methods, tools, and staff for service delivery from a broad systems perspective can need to expend some effort to reframe their concept of service delivery to accommodate this perspective. The benefits of doing so are great, however, because critical and otherwise unnoticed resources and dependencies between resources will become visible for the first time. This insight will enable the service provider organization to effectively improve its operations over time without being caught by surprises or wasting resources on incompletely addressing a problem. Service Agreement A service agreement is the foundation of the joint understanding between a service provider and customer of what to expect from their mutual relationship. The glossary defines a “service agreement” as a binding, written record of a promised exchange of value between a service provider and a customer. Service agreements can appear in a wide variety of forms, ranging from simple posted menus of services and their prices, to tickets or signs with fine print that refer to terms and conditions described elsewhere, to complex multi-part documents that are included as part of legal contracts. Whatever they may contain, it is essential that service agreements be recorded in a form that both the service provider and customer can access and understand so that misunderstandings are minimized. The “promised exchange of value” implies that each party to the agreement commits to providing the other party or parties with something they need or want. A common situation is for the service provider to deliver needed services and for the customer to pay money in return, but many other types of arrangements are possible. For example, an operating level agreement (OLA) between organizations in the same enterprise may only require the customer organization to notify the service provider organization when certain services are needed. Service agreements for public services provided by governments, municipal agencies, and non-profit organizations can simply document what services are available, and identify what steps end users must follow to get those services. In some cases, the only thing the service provider needs or wants from the customer or end user is specific information required to enable service delivery. See the definition of “service agreement,” “service level agreement,” “customer,” and “end user” in the glossary. Service Request Even given a service agreement, customers and end users must be able to notify the service provider of their needs for specific instances of service delivery. In the CMMI-SVC model, these notifications are called “service requests,” and they can be communicated in every conceivable way, including face-to-face encounters, phone calls, all varieties of written media, and even non-verbal signals (e.g., pressing a button to call a bus to a bus stop). Regardless of how it is communicated, a service request identifies one or more desired services that the request originator expects to fall within the scope of an existing service agreement. These requests are often generated over time by customers and end users as their needs develop. In this sense, service requests are expected intentional actions that are an essential part of service delivery; they are the primary triggering events that cause service delivery to occur. (Of course, it is possible for the originator of a request to be mistaken about whether or not the request is actually within the scope of the service agreement.) Sometimes specific service requests can be incorporated directly into service agreements themselves. This incorporation of service requests in the service agreement is often the case for services that are to be performed repeatedly or continuously over time (e.g., a cleaning service with a specific expected cleaning schedule, a network management service that must provide 99.9% network availability for the life of the service agreement.) Even in these situations, ad-hoc service requests can also be generated when needed and the service provider should be prepared to deliver services in response to both types of requests. Service Incident Even with the best planning, monitoring, and delivery of services, unintended events can occur that are unwanted. Some instances of service delivery can have lower than expected or lower than acceptable degrees of performance or quality, or can be completely unsuccessful. The CMMI-SVC model refers to these difficulties as “service incidents.” The glossary defines a “service incident” as an indication of an actual or potential interference with a service. The single word “incident” is used in place of “service incident” when the context makes the meaning clear. Like requests, incidents require some recognition and response by the service provider; but unlike requests, incidents are unintended events, although some types of incidents can be anticipated. Whether or not they are anticipated, incidents must be resolved in some way by the service provider. In some service types and service provider organizations, service requests and incidents are both managed and resolved through common processes, staff, and tools. The CMMI-SVC model is compatible with this kind of approach, but does not require it, as it is not appropriate for all types of services. The use of the word “potential” in the definition of service incident is deliberate and significant; it means that incidents do not always involve actual interference with or failure of service delivery. Indications that a service may have been insufficient or unsuccessful are also incidents, as are indications that it may be insufficient or unsuccessful in the future. (Customer complaints are an almost universal example of this type of incident because they are always indications that service delivery may have been inadequate.) This aspect of incidents is often overlooked, but it is important: failure to address and resolve potential interference with services is likely to lead eventually to actual interference, and possibly to a failure to satisfy service agreements. Project, Work Group, and Work CMMI models must often refer to the organizational entities that are at the foundation of process improvement efforts. These entities are focal points in the organization for creating value, managing work, tailoring processes, and conducting appraisals. In CMMI-SVC, these entities are called “work groups,” while in CMMI-DEV and CMMI-ACQ these entities are called “projects.” The glossary defines both terms and their relationship to each other, but it does not explain why two different terms are needed. Those who have prior experience using CMMI-DEV or CMMI-ACQ models, or who routinely think of their work as part of a project-style work arrangement, may wonder why the term “project” is not sufficient by itself. The CMMI glossary defines a “project” as a managed set of interrelated activities and resources, including people, that delivers one or more products or services to a customer or end user. The definition notes explain that a project has an intended beginning (i.e., project startup) and end, and that it typically operates according to a plan. These notes are characteristics of a project according to many definitions, so why is there an issue? Why might there be a difficulty with applying terms like “project planning” or “project management” in some service provider organizations? One simple reason is that projects have an intended end as well as an intended beginning; such efforts are focused on accomplishing an objective by a certain time. While some services follow this same pattern, many are delivered over time without an expected end (e.g., typical municipal services, services from businesses that intend to offer them indefinitely). Service providers in these contexts are naturally reluctant to describe their service delivery work as a project under this definition. In prior (V1.2) CMMI models, the definition of “project” was deliberately changed to eliminate this limitation (i.e., that projects have a definite or intended end), in part to allow the term to be applied easily to the full range of service types. However, the change raised more questions and objections than it resolved when interpreted by many users (even in some service contexts), and so the limited meaning has been restored in V1.3: projects now must have an intended end. For organizations that do not structure their people and other resources into projects with intended ends, or that only do so for a portion of their work, the original problem remains. All of the common CMMI practices are useful whether or not your work is planned to have an intended end, but what can we call a fundamental organizational entity that implements CMMI practices if it is not a project? How can we refer to and apply the practices of process areas such as project planning when we are not discussing a project? The CMMI V1.3 solution is to introduce some new terms that take advantage of two distinct senses of meaning for the English word “project”: as a collection of resources (including people), and as a collection of activities performed by people. CMMI-DEV and CMMI-ACQ continue to use the term “project” for both senses, because this use reflects the typical nature of development and acquisition efforts. CMMI-SVC replaces “project” with “work group” (when it refers strictly to a collection of resources including people) or with “work” (when it refers to a collection of activities, or a collection of activities and associated resources). The glossary defines a “work group” as a managed set of people and other resources that delivers one or more products or services to a customer or end user. The definition is silent on the expected lifetime of a work group. Therefore, a project (in the first sense) can be considered a type of work group, one whose work is planned to have an intended end. Service provider organizations can therefore structure themselves into work groups (without time limits) or projects (with time limits) depending on the nature of the work, and many organizations will do both in different contexts. For example, development of a service system can be performed by a project, whereas service delivery can be performed by a work group. The glossary also notes that a work group can contain work groups, can span organizational boundaries, and can appear at any level of an organization. It is possible for a work group to be defined by nothing more than members of an organization with a particular common purpose (e.g., all those who perform a particular task), whether or not that group is represented somewhere on an organization chart. In the end, of course, organizations will use whatever terminology is comfortable, familiar, and useful to them, and the CMMI-SVC model does not require this approach to change. However, all CMMI models need a convenient way to refer clearly to the fundamental groupings of resources that organize work to achieve significant objectives. In contrast to other CMMI models, the CMMI-SVC model uses the term “work group” rather than “project” for this limited purpose, and uses the term “work” for other senses of the word “project” including combined senses. For example, a “project plan” is called a “work plan” in CMMI-SVC. (In a few cases, the word “project” is retained in the CMMI-SVC model when it explicitly refers to a true project.) Consistent with this usage, the titles of some important core process areas are different in CMMI-SVC compared to CMMI-DEV and CMMI-ACQ: Work Planning, Work Monitoring and Control, Integrated Work Management, and Quantitative Work Management (cf. Project Planning, Project Monitoring and Control, Integrated Project Management, and Quantitative Project Management). Despite these differences in terminology in different constellations, Integrated Work Management and Integrated Project Management cover essentially the same material and are considered to be the same core process area in all three CMMI constellations; the same is true for other equivalent process area pairings.