Home > Articles > Process Improvement

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.


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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020