Chapter 5. Relationships Among Process Areas

In this chapter, we describe the key relationships among process areas to help you see the service provider’s view of process improvement and how process areas depend on the implementation of other process areas.

The relationships among multiple process areas, including the information and artifacts that flow from one process area to another—illustrated by the figures and descriptions in this chapter—help you to see a larger view of process implementation and improvement.

Successful process improvement initiatives must be driven by the business objectives of the organization. For example, a common business objective is to reduce the time it takes to deliver a service. The process improvement objective derived from that might be to improve incident management processes. Those improvements rely on best practices in the Service Delivery and Incident Resolution and Prevention process areas.

Although we group process areas in this chapter to simplify the discussion of their relationships, process areas often interact and have an effect on one another regardless of their group, category, or level. For example, the Decision Analysis and Resolution process area (a Support process area at maturity level 3) contains specific practices that address the formal evaluation process used in the Service Continuity process area (a Project and Work Management process area at maturity level 3) to select functions that are essential to the organization and must be covered in the service continuity plan.

Being aware of the key relationships that exist among CMMI process areas will help you apply CMMI in a useful and productive way. Relationships among process areas are described in more detail in the references of each process area and specifically in the Related Process Areas section of each process area in Part Two. Refer to Chapter 2 for more information about references.

The process areas of the CMMI-SVC model have numerous interrelationships that are based on a transfer or sharing of information, work products, and other resources by their associated practices. This section focuses on identifying only the relationships encompassing the service specific process areas. These relationships are best understood by functionally associating them into two distinct groups that span both maturity levels and process area categories:

• Establishing and delivering services

• Managing services

Process area relationships are illustrated in flow diagrams that focus on key dependencies for the sake of clarity. Not all possible interactions between process areas are shown and not all process areas are shown. The process areas that have been omitted from these diagrams (primarily the Process Management and Support process areas) have potential relationships with all of the process areas that are shown, and their inclusion would make it difficult to focus on the key CMMI-SVC relationships.

Relationships that Drive Service Establishment and Delivery

Figure 5.1 shows process areas associated with the establishment of service delivery capabilities as driven by requirements from service agreements with customers, as well as with service delivery.

Figure 5.1 Key Process Area Relationships for Establishing and Delivering Services

All of the process areas shown in this diagram are in the Service Establishment and Delivery process area category. Note that the Service Delivery process area occupies a central role in these relationships.

Service establishment and delivery process areas represent the “core” of the CMMI for Services model in a longitudinal sense; all of the relationships can be laid out over time in the form of interchanges that span a service lifecycle. Working through these relationships for each process area is one way to lay the groundwork for a discussion of service lifecycles, which is at the end of this chapter.

Although this is a useful way to describe the process areas and their relationships, there is no order of implementation implied in this discussion. The activities that support each of these process areas are often iterative in nature and affect the other process areas and their associated activities.

The Strategic Service Management (STSM) process area stands at the beginning of the metaphorical timeline. STSM practices cover collecting and analyzing information about customers’ and end users’ strategic service needs, and using this (and other) information to identify and define the requirements for standard services.

These requirements, their derived requirements, and requirements for nonstandard services are all handled by the Requirements Management (REQM) process area (which appears and is discussed in Relationships that Drive Service Management).

STSM practices also cover producing a service catalog that is used by customers and end users to select and request services, and is used by the organization to help regulate what services actually are delivered (covered by the Service Delivery process area).

Next in line is the Service System Development (SSD) process area. SSD practices start with service requirements and transform them via requirements development, design, implementation, integration, verification, and validation into a new service system (or into significant changes to an existing service system). This transformation often yields derived requirements that should be managed as well (by REQM).

The Service System Transition (SST) process area covers the deployment of the validated service system produced by SSD. SST practices move the service system into operational use while minimizing impacts on concurrent service delivery. During the preparations for this deployment as well as during the deployment itself, SST practices are guided by previously established requirements, and may generate additional derived requirements of their own.

Everything comes together in the Service Delivery (SD) process area. SD practices include working with customers to identify their specific service requirements and establish service agreements. Service catalogs established by STSM may make this easier. The deployed service system is then operated (also covered by SD) to produce service value (i.e., delivered services) in response to specific service requests that are covered by the established agreements. SD practices include providing status information on these requests back to the originating customers, as well as providing overall operations and service delivery measures to other service management process areas. Feedback from service management practices then regulates ongoing service delivery. Finally, information about how incidents are being handled enables an effective operational integration of incident and service request responses.

To handle actual or possible interference with the delivery of services, the Incident Resolution and Prevention (IRP) process area practices include receiving information about such incidents from customers and end users (as well as from internal sources). IRP practices cover determining how best to respond to each incident, doing whatever is needed to enable incident closure, keeping the customers and end users updated with incident status, and addressing incident causes to reduce the impact or occurrence of future incidents.

The depiction of these process areas and relationships in Figure 5.1 should be interpreted with caution. They are not the only important ones for effective service establishment and delivery. A few other significant process areas and relationships include the following.

• The Configuration Management (CM) process area covers keeping configurations and configuration items of service system components produced by SSD under control.

• The Organizational Process Definition (OPD) process area covers creating the standard processes needed to deliver the standard services defined in STSM processes. OPD also covers providing these processes and related service lifecycles to SSD processes to guide the design of service system development.

• The Organizational Training (OT) process area covers implementing the training strategy created by SST processes to prepare staff members for the rollout of a new or changed service system.

• The Causal Analysis and Resolution (CAR) process area covers identifying and addressing the root causes of problems identified during IRP processes.

Relationships that Drive Service Management

Figure 5.2 shows process areas associated with the management of services at the work group level. Most of the process areas shown in this diagram are in the Project and Work Management process area category, with the exception of Service Delivery. The reason that this diagram refers to “service management” rather than “work management” is that the Service Delivery process area contributes both to Project and Work Management as well as to Service Establishment and Delivery, but can only be part of a single process area category in a CMMI model.

Figure 5.2 Key Process Area Relationships for Service Management

The process areas that are most central to the management of services have their own critical relationships, many of which are illustrated in Figure 5.2. Because they cover activities that are performed more or less throughout the entire service lifecycle, there’s no particularly obvious order for considering them, so an alphabetical sorting is used.

The Capacity and Availability Management (CAM) process area receives information about capacity and availability requirements, service system operations, and other service delivery data. CAM practices are used to analyze this information to produce estimates of the types and quantities of resources needed over time to deliver services, based on the use of service system representations. These analyses may also yield modifications to previously established requirements.

The Work Monitoring and Control (WMC) process area is driven by work plans, as well as by operational-level plans (not shown in Figure 5.2) created on the fly during service delivery, and by service system operations and service delivery data (also not shown in Figure 5.2). WMC practices determine whether current and anticipated service system operations are consistent with overall work plans, and establish corrective actions or needed revisions to resource constraints or service thresholds. In addition, customers and end users are kept informed about overall operations.

The Work Planning (WP) process area represents the logical foundation of work management in a services context. WP practices develop and maintain a work plan that builds on resource analyses performed by CAM and covers all the service system resources. WP also establishes commitments to the plan from necessary stakeholders. This plan is constrained by the overall service requirements established for the work from one or more service agreements with actual or anticipated customers. As other work related plans are developed (e.g., a service continuity plan), WP practices ensure that they are harmonized and consistent with the overall work plan. Finally, WP establishes the data measurement needs of the work group that determine what data should be collected during service system operations.

The Requirements Management (REQM) process area is the focal point for tracking requirements for any aspect of the work. REQM practices both collect requirements from and distribute requirements to many other process areas, including those originating in service agreements with customers. This coordination facilitates requirements change management, bidirectional traceability, and the detection of inconsistencies between requirements and the full range of work products created or used by the work group.

To provide assurance that critical services can be delivered no matter what happens, the Service Continuity (SCON) process area implements a specialized form of risk management. This work is often performed across an organization rather than in any single work group, because the risks created by major disasters frequently have an organization-wide scope. SCON practices are used to identify essential service resources and functions based on priority service requirements, and then to prepare, verify, and validate plans to ensure that catastrophic events will not completely wipe out a service provider’s ability to deliver all services.

The Service Delivery (SD) process area appears in the discussions of both types of process areas and relationships (service delivery and service management), because SD includes both types of activities. From a service management perspective, SD practices include the creation of service agreements with customers. The service requirements from those agreements, plus the resource constraints and schedules identified in the work plan, allow SD to establish a targeted service delivery approach that will satisfy all stakeholders. This approach guides the operational-level responses to service requests during ongoing service delivery.

As with the process areas and relationships that drive service establishment and delivery, the service management process areas and relationships that appear in Figure 5.2 are not the only ones relevant to effective service management. The CMMI for Services model contains cross-references between these and many other process areas that identify these types of relationships. As you learn and understand the distribution of goals and practices across the entire model, you will probably realize the existence of other relationships that are not explicitly identified.

Lifecycles

Anyone who has managed or worked in a service business knows that work activities change over time in a way that reflects the dependencies among those activities as well as their dependence on the activities of other relevant stakeholders. For example, from a high-level perspective, you need a service agreement in place before you begin delivering services; you have to create a service system of some kind before you roll it out into operational use; and so on. These types of time-phased relationships can be organized and abstracted into groups of activities called “phases,” and the phases can be structured and ordered into patterns called “lifecycles.”

Although the concept of a lifecycle is fairly commonly used and understood in the context of domains such as manufacturing and product development, it is less often considered in the context of service delivery. Because the CMMI for Services model makes a variety of references to lifecycles, and because a proper understanding of them is helpful for achieving higher levels of process maturity, service lifecycles and ways of modeling them are worth an extended discussion.

The Importance of Lifecycles

Lifecycles are valuable because they provide a consistent and improvable basis of planning for any repeatable pattern of work activities over time. They provide a common framework within which business processes can be ordered. Organizations that don’t use lifecycles may have to create from scratch the plans needed to accomplish new work each time, without the benefit of prior experience and the knowledge of a normal order of events. This type of approach to work planning over time can lead to wasted effort, lower-quality plans, and higher risks.

Rather than describing every last detail of a set of related work activities and events over time, lifecycles usually abstract the most significant information into a manageable number of chunks or phases. For different types of lifecycles, these phases can cover different degrees of scope ranging from single tasks to entire lines of business. Lifecycle phases can also have a varying granularity ranging from minutes to years in length, depending on the scope of the phase and nature of the service domain. For example, contrast the likely phases of a service request lifecycle in a service domain that emphasizes speedy response (e.g., fast food restaurants) with those in a service domain that emphasizes extreme caution (e.g., historical artifact conservation).

Effective and balanced abstraction of information is what determines the value of lifecycles. Too much detail and a lifecycle will likely require too much modification to be used repeatedly. Too little detail and a lifecycle may be missing important guidance. To be valuable, a lifecycle must have the necessary reusable information for your organization. With the right balance of information, good lifecycles allow you to more effectively plan for needed changes, smoothly transition from one phase of activity to another, and consistently control the pace of your work over time.

Lifecycles in CMMI for Services

The CMMI for Services model mentions a number of different types of lifecycles, including those for products, projects, services, incidents, and service systems. (Sometimes these are referred to as “lifecycle models,” which indicate the existence of a relatively small set of standardized lifecycles created, selected, or adapted by an organization.) However, little guidance is provided on how these and other lifecycles might be defined in a services context, or how they may interrelate, so it may be difficult to know where to begin.

This discussion outlines some examples to help you get started with your lifecycle definitions, but caution is warranted: These are only examples of what is possible. Some of these examples may be more broadly useful than others, but it is important for you to tailor them to meet the needs of your organization, or create other lifecycles that may be specifically relevant to your situation. The Organizational Process Definition process area contains a practice that specifically focuses on the creation of effective lifecycle models by your organization.

Service Lifecycles

Because the primary focus of CMMI for Services is on services rather than on products in general, we can use the concept of a service as the entry point into the discussion of lifecycles. The lifecycle of a service might best be interpreted as lasting the entire period of time that a particular service is actually available plus the additional time needed to make that service available and remove it from availability. A service lifecycle covers the fullest possible extent of events and activities related over time in any way to the actual delivery of a service, and might therefore include the following phases:

1. Conceptualization: determining what services must be provided for different types of customers

2. Development: determining how services will be provided and establishing the resources needed to do so

3. Actualization: establishing agreements to deliver services and actually delivering services to satisfy those agreements

4. Retirement: removing a service that is no longer needed

Since a service lifecycle encompasses the complete scope of all activities related to service delivery, it’s quite reasonable to expect that all the different process areas of the CMMI for Services model are potentially applicable in one or more of these phases. However, one process area stands out as being of interest primarily in service lifecycles and less so in other lifecycles: Strategic Service Management. This process area focuses on the conceptualization of services in ways that are independent of service agreements with individual customers. Strategic Service Management practices help you to define a standard foundation of services for all of your customers.

Project Lifecycles

The CMMI for Services model handles the concept of a project in a flexible way. Some organizations have a single ongoing project that operates a service system for different customers through different service agreements over time. Other organizations might have a separate project for each major service agreement with a different customer. Still other organizations may consider their service related work to take the form of ongoing operations rather than one or more projects. Even for these organizations, however, some major types of work have a specific beginning and end, and can be managed as projects (such as the creation of a new service system).

Service provider organizations follow so many different business models that it’s impossible to establish a meaningful single project lifecycle to cover them all. The project lifecycles you define should reflect your own project and related work management needs. For example, if your organization treats each service agreement as a separate project, your project lifecycle might include the following phases:

1. Agreement: negotiating with your customer and establishing your service agreement

2. Preparation: planning, organizing, and allocating your resources, as well as establishing your service delivery approach and your service system (if needed)

3. Delivery: providing services to your customers in response to service requests, handling incidents, and managing and maintaining your service system

4. Termination: completing your service agreements, disposing of service system resources, and archiving project data

These same phases might occur in a different order if your organization has projects that cover multiple service agreements; preparation might precede agreement, and you might have multiple agreement phases.

Like a service lifecycle, a project lifecycle is broad in scope, and most process areas of the CMMI for Services model have practices that are applicable to project lifecycles. However, several service specific process areas stand out as being particularly relevant to most project lifecycles:

• Service Delivery, which covers responding to service requests and maintaining your service system, as well as the establishment of service agreements and your service delivery approach

• Capacity and Availability Management, which monitors, analyzes, and reports on the capacity and availability of your service system

• Incident Resolution and Prevention, which resolves service incidents and helps to keep your service operation running smoothly

Service System Lifecycles

The lifecycle of a service system may fall completely within a single project lifecycle, it may span several project lifecycles, or it may be more sensibly related to an overall service lifecycle. Alternatively, a single service or project lifecycle might span several service system lifecycles. However your service system lifecycles are aligned, you should define their phases to comprehensively cover all the necessary processes. For example, a “waterfall” type of service system lifecycle might have the following phases:

1. Analysis: determining what your service system will do by developing and refining the requirements for services to a sufficient level of detail

2. Design: identifying the types of service system components, functions, and interfaces needed to address identified requirements, and allocating those requirements to appropriate components

3. Implementation: assembling, building, and integrating components into a working service system

4. Transition: placing a new or changed service system into operational use

5. Operation: delivering services, handling incidents, and maintaining the service system

6. Retirement: removing service system components or the entire service system from active use

Other service system lifecycles can be similarly adapted from other product development lifecycle models such as incremental or evolutionary models. You should also consider that different service and work contexts may require very different emphases and time scales for the various phases. For example, an organization providing professional services with a simple service system might have the operation phase occupying the bulk of the service system lifecycle. Another organization might build custom complex service systems under contract for each customer, in which case the analysis, design, and implementation phases might be more significant.

Two service specific process areas stand out as being particularly relevant to most service system lifecycles:

• Service System Development: analyzing, designing, developing, integrating, verifying, and validating your service system

• Service System Transition: preparing to deploy your service system into operational use, and actually deploying it

In addition, the Service Delivery, Capacity and Availability Management, and Incident Resolution and Prevention process areas all contribute useful practices to the operational phase of a service system’s lifecycle.

Service Request Lifecycles

Depending on the length and complexity of the service requests your organization handles, the lifecycle of a single service request may be so simple that you might choose to describe it as a single process rather than as a lifecycle with multiple phases and processes. Either way, your service requests are likely to include at least the following steps or phases:

1. Initiation: receiving and recording a communication from a customer of a particular need for a service

2. Analysis: determining an initial appropriate method for responding to the request, and identifying and assigning resources sufficient to execute the response

3. Resolution: providing the requested service

4. Closure: confirming that the customer received the anticipated service, and recording appropriate service information, including customer satisfaction data

Some service requests may involve lifecycles with the possibility of iterations of analysis and response, or the response phase may itself be divisible into further phases. In any case, the Service Delivery process area is the one process area of the CMMI for Services model that is most relevant to service requests and their lifecycles.

Incident Lifecycles

For some organizations, the lifecycle of an incident may often be similar in outline to a service request lifecycle, with the exception that incidents are not usually “initiated” intentionally. And some incident lifecycles may also be so short as to be best addressed through a single process. The necessary activities will probably include the following steps or phases:

1. Detection: identifying and recording the existence of a possible interference with service delivery

2. Analysis: determining an initial appropriate method for responding to the incident, and identifying and assigning resources sufficient to execute the response

3. Resolution: performing the identified method for correcting or mitigating the incident

4. Closure: confirming that the incident has been resolved and recording appropriate incident information

In many incident management contexts, the initial response may be inadequate to bring the incident to closure, and cycles of analysis and response may be necessary (including escalation that identifies and assigns additional resources). The Incident Resolution and Prevention process area is the one process area of the CMMI for Services model that is most relevant to service incidents and their lifecycles.

Putting Lifecycles Together

With so many different types of lifecycles to consider, you may have some difficulty imagining how they are interrelated. A lifecycle diagram is useful for this purpose, and it can serve as the starting point for defining your own lifecycles. Figure 5.3 provides an example of one way that these service related lifecycles can be integrated and aligned.

Figure 5.3 An Example of Service Related Lifecycle Alignment

In this hypothetical example, the service provider organization provides a separate set of services independently to each major customer based on a separately negotiated service agreement. Each service agreement defines the scope of a separate project. A separate service system is developed for each project, and that system is ready for use by the time the service agreement is finalized. Service delivery then occurs whenever the provider organization handles customer-generated service requests; different requests take different amounts of time and resources to handle (see the “+” bars in the diagram). Sometimes service delivery is incomplete or inadequate, and there are incidents that need to be handled as well (see the “-” bars in the diagram); these also can require different amounts of time and resources to achieve closure.

Of course, your own organization may have one or more ways of integrating these and other lifecycles that are quite different from this example. A service system lifecycle might span multiple projects with the same customer or with different customers. A single long-running project might span multiple service system lifecycles, or might need to include a product development lifecycle for tangible items that are delivered to customers along with services. Some types of service requests might be resolved across the entire duration of a service agreement, and some might be resolved through automated processes. Your organization may not consider a project lifecycle to be important at all; instead, an additional separate lifecycle for pursuing major business opportunities may be appropriate. In the end, your own business structure and work patterns are the primary drivers that determine what lifecycles are needed, how they should be defined, and how they should be tied together.