This chapter is from the book
This chapter is from the book
This chapter is from the book
Important CMMI-SVC Concepts
The following concepts are particularly significant in the CMMI-SVC model. Although all are defined in the glossary, they each employ words that can cover a range of possible meanings to those from different backgrounds, and so they merit additional discussion to ensure that model material that includes these concepts is not misinterpreted.
Service
The most important of these terms is the word service itself, which the glossary defines as a product that is intangible and nonstorable. 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 usage 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 nonstorable, 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 with a background in information technology, especially those familiar with disciplines such as 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 nonstorable 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 may 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 may still have trouble with this interpretation because they may feel 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 may in some cases be true for service provider organizations with relatively immature practices, part of the difficulty may 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 may belong to customers or suppliers, and some may 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 or 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 CMMISVC 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 personnel for service delivery from a broad systems perspective may 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 among 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.
Services and Service Systems in CMMI for Services versus SOA and SaaS
If you know something about SOA or SaaS, you might be a bit nonplussed by the preceding briefly stated distinction between the various meanings of the term service, followed by a forward reference to a discussion of the term service system, where neither SOA nor SaaS is mentioned at all. Here's some additional clarification. (If you're not interested in SOA or SaaS, you can skip over this discussion.)
Although there are a variety of interpretations of SOA and SaaS, they all tend to focus on information systems of one form or another and how they are designed to deliver value. SOA emphasizes certain characteristics of the architecture of these systems (e.g., the alignment of components with business functions), whereas SaaS considers different aspects of system architecture while emphasizing the flexibility of how software capabilities are delivered to end users. Because CMMI for Services, SOA, and SaaS practitioners all use the terms service and system somewhat differently, and because it's quite possible for CMMI for Services, SOA, and SaaS to all be employed in a single context, some confusion is likely if you are not sensitive to those differences.
In the CMMI for Services perspective, a service is the result of a process, and system (i.e., a service system) refers to all the resources required to deliver services. When done properly, the operation of a service system causes service delivery. Service systems may incorporate subsystems that are themselves information technology systems, but these IT systems might represent only a small fraction of a total service system infrastructure.
In the SOA perspective, a service is an IT system component that provides a distinct and loosely coupled function accessible through a standard, contractually governed interface. At the top level, the structure of these services is expected to correlate well with the structure of business functions that an organization performs, and SOA designs often involve analyses of one or more enterprise architectures to establish needed commonalities. No matter what level of abstraction, the term service in SOA is most likely to be applied to actions, methods, functions, and "things that are done" rather than to their results; and the term system typically refers to something that at its core is an IT system of some kind.
In the SaaS perspective, software is delivered as a service (e.g., a subscription service) without the need for the customer to pay for the full cost up front. The term service in SaaS therefore seems closer to the CMMI for Services usage than the SOA usage, but it's important to be clear. A SaaS service is not a software component that is made available (as in SOA), but rather is the on-demand availability of that component (and others) along with capabilities such as dynamic updates, tailorability, and load balancing. SaaS services are delivered via an IT system, but this may be only a portion of a larger service system that supplies other services, such as help desk support or network management.
Service Agreement
A service agreement is the foundation of the joint understanding between a service provider and a 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 refers to terms and conditions described elsewhere, to complex multipart 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 the 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 require only that the customer organization notify the service provider organization when certain services are needed. Service agreements for public services provided by governments, municipal agencies, and nonprofit organizations may 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 glossary for additional discussion of the terms service agreement, service level agreement, customer, and end user.
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 nonverbal signals (e.g., pressing a button to call a bus to a bus stop).
However 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 the request is actually within the scope of agreed services.)
Sometimes specific service requests may be incorporated directly into the 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 or a network management service that must provide 99.9 percent network availability for the life of the service agreement). Even in these situations, ad hoc service requests may 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 may occur that are unwanted. Some instances of service delivery may have lower than expected or lower than acceptable degrees of performance or quality, or may 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 may 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, personnel, 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 have to 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
While it refers to a concept that is used across all CMMI models, the term project deserves some special clarification in the context of the CMMI-SVC model. It is likely that no other single word in the model has the same potential to raise misunderstandings, questions, and even objections.
Those with prior experience using other CMMI models, or who routinely think of their work as part of a project-style work arrangement, may wonder where the difficulty lies. The CMMI glossary defines a project as a managed set of interrelated resources that delivers one or more products or services to a customer or end user, and continues by declaring that a project has a definite beginning (i.e., project startup) and typically operates according to a plan. These characteristics are conventional of a project according to many definitions, so why is there an issue? Why might there be a difficulty with applying terms such as project planning or project management in some service provider organizations?
One simple reason is that many people work on or know of projects that have a definite end as well as a definite beginning; such projects are focused on accomplishing an objective by a certain time. In fact, the glossary in prior versions of CMMI models (i.e., prior to V1.2) specifically included a definite end as part of the definition of project. This more restrictive definition reflected the original focus of CMMI (and the other maturity models that preceded it), which was principally on development efforts that normally come to some expected end once an overall objective has been reached. While some services follow this same pattern, many are delivered over time without an expected definite end (e.g., services from businesses that intend to offer them indefinitely, or typical municipal services). Service providers in these contexts would naturally be reluctant to describe their service delivery work as a project under this definition.
However, for the latest (V1.2) CMMI models, the definition of project was deliberately changed to eliminate this limitation, in part to allow the term to be applied easily to the full range of service types. Projects must be planned, but they do not need to have a planned end, and this broader definition can therefore make sense in the context of all service delivery (provided that CMMI model users are willing to suppress an expectation that all projects must come to an end).
Even given this adjustment, some people may still have difficulty thinking of the delivery of services as being a project, which often carries the connotation of trying to accomplish an overall objective by following some preset plan. Many services are delivered in response to what are effectively small independent objectives established over time—individual service requests—in ways that are not planned in advance according to predetermined milestones. In these circumstances, service providers are often not used to thinking of a single objective to be accomplished. Therefore, characterizing their work arrangements as projects may seem awkward at best.
For this reason, the CMMI-SVC model explicitly interprets the term project to encompass all of the resources required to satisfy a service agreement with a customer. Satisfaction of the terms of the service agreement becomes the overall objective under which individual service requests are handled. Planning the effort to satisfy the service agreement is required in the form of work structures, resource allocations, schedules, and other typical project planning work products and processes. If you think of a service agreement as outlining the scope of a project in this way, the use of project in a service context becomes less of a problem.
Even better, the glossary includes notes explaining that a project can be composed of projects. These additional notes mean that interrelated sets of service agreements or service agreements covering multiple customers can be treated as projects, as can distinct subsets of work within the scope of a single service agreement. For example, the development of a new version of a service system or the transition of a new service delivery capability into operational use can be treated as a project as well.
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 consistently and clearly to the fundamental groupings of resources that organize work to achieve significant objectives. Given the glossary definition and the preceding discussion, the term project is still adequate and effective for this purpose, although its meaning has had to grow in scope over time. This adaptation is not a surprise, because CMMI models themselves have grown in scope over time, and are likely to continue to do so in the future. CMMI-SVC users are strongly encouraged to consider how they too may adapt their way of thinking to reflect greater flexibility, and thereby gain the benefits of different ways of improving services.
Stakeholder, Customer, and End User
In the model glossary, a stakeholder is defined as a group or individual who is affected by or is in some way accountable for the outcome of an undertaking. Stakeholders include any and all parties with a legitimate interest in the results of service delivery, such as service provider executives, staff members, customers, end users, suppliers, partners, and oversight groups. Remember that any given reference to stakeholders in the model covers all types of stakeholders, and not just the ones that might be most obvious in the particular context.
The model defines a customer as the party (individual, project, or organization) responsible for accepting the product or for authorizing payment. A customer must also be external to the project that develops (delivers) a product (service), although both the customer and the project may be part of the same larger organization. While this concept seems clear enough, the glossary includes some ambiguous language about how the term customer can include "other relevant stakeholders" in some contexts, such as customer requirements. Although this caveat reflects an accepted legacy usage of the term from earlier versions of CMMI models, it could be potentially confusing in a service context, where the distinction between customers and other stakeholders (especially end users) can be especially significant.
The CMMI for Services model addresses this concern in two ways. First, it avoids the term customer requirements except in those contexts where it refers to the requirements of customers in the narrow sense (those who accept a product or authorize payment). Second, the model includes added material in the glossary to distinguish between customers and end users, and to define the term end user itself.
The model defines an end user as the party (individual, project, or organization) that ultimately receives the benefit of a delivered service. While end users and customers therefore cover distinct roles in service establishment and delivery, both can often be represented by a single party. For example, a private individual who receives financial services from a bank is probably both the customer and the end user of those services. However, in health care services, the customers often include organizations such as employers and government agencies that negotiate (or dictate) health care plan coverage for the ultimate health care beneficiaries, who are the end users of those services. (Many of these end users may be customers as well, if they have a responsibility to pay for all or part of some services.)
To summarize: It's important to keep in mind the actual scope of the terms stakeholder, customer, and end user as you review and apply the CMMI for Services model in your unique service context so that you don't overlook or confuse crucial interactions and interfaces in your service system.