Sign in

Accountabilities in a complex service relationship White Paper

White Paper

Accountabilities in a complex service relationship White Paper

White Paper

  • White Paper
  • Collaboration
  • Communication
  • Business solutions
  • Customer needs
  • IT Services
  • Service management
  • Value
  • ITIL

Author  Angie Pederson

July 16, 2019 |

 22 min read

  • White Paper
  • Collaboration
  • Communication
  • Business solutions
  • Customer needs
  • IT Services
  • Service management
  • Value
  • ITIL

This paper describes how to define roles within the SVS through the use of a responsibility assignment matrix, or RACI chart. RACI charts are flexible and scalable to meet your needs at any level of maturity






Introduction

Typically, internal IT organizations are complex; partners provide services to a varied set of consumers. Each provider-consumer relationship is unique in its ongoing management, including how the contract is structured, the desired outcomes, and who is accountable on each side.

ITIL® 4 introduces the concept of the service relationship, which focuses on interactions between service providers and service consumers across the overall service value system (SVS). The SVS represents how the organization’s components and activities combine in order to facilitate value creation.

This paper will describe techniques to define roles within the SVS through the use of a responsibility assignment matrix, or RACI chart. RACI charts are flexible and scalable to meet your needs at any level of maturity.

RACI charts

2.1 WHAT IS A RACI CHART?

RACI charts facilitate an understanding of the connections between provider-consumer relationships. They define role expectations and categorize the involvement of each role across activities. In a typical matrix, activities are displayed in the left column and roles along the top row. Each cell in the chart shows the expected engagement level for each role against each activity. There are four possible engagement levels:

  • Responsible (R): the person in this role performs the activity. There may be more than one responsible person per activity.
  • Accountable (A): the person in this role is the ultimate decision maker and is responsible for the outcome of the activity.
  • Consulted (C): the person in this role provides input based on their expertise on the activity or its potential impact on future projects.
  • Informed (I): the person in this role is regularly updated regarding the activity but does not need to be more involved.

2.1.2 Example of the RACI assignments

An IT department has transitioned its service desk to an external provider. The IT department wants to ensure that customers are aware of the change. They also want the terms of the agreement with the external provider to meet organizational expectations. The Head of Operations is accountable for the transition and the ongoing operation of the service desk. The Service Desk Manager meets with the organization to provide awareness and gather feedback. The provider is accountable for delivering to the terms of the agreement.

Let’s examine some example activities based on this example:

  • The Head of Operations sets and communicates the budget. Since there is no chargeback, the organization is not directly involved in the communication of the budget. The Service Desk Manager is consulted during the process and is informed of the final budgetary numbers.
  • The Service Desk Manager is responsible for ensuring the budget is on target and is reported to the Head of Operations.
  • The Service Desk Manager facilitates review sessions. Before the sessions, the Service Desk Manager identifies topics to include from the provider and the organization. During the session, the Service Desk Manager facilitates the discussion and makes notes of required actions. Afterwards, the Service Desk Manager informs the Head of Operations of the results.
  • The organization is accountable and responsible for providing feedback to the Service Desk Manager, who documents and actions the feedback. This information is communicated to the provider and the Head of Operations.
  • The Service Desk Manager collects metrics from the provider and communicates the information internally. Representatives are consulted to make sure there is a feedback loop in case of a discrepancy.
  • The provider is accountable for providing metrics to the Service Desk Manager. The Head of Operations may be informed of any issues with their delivery and consulted on methods of resolving them.

Table 2.1 demonstrates how these activities can be reflected in a RACI chart.

Head of Operations

Service DeskOrganization Representative Provider Representative

Set budget (project and ongoing)

A, R

C, I

C, I

Manage services desk budget

A, C, I

RR

Facilitate review sessions

IA,R,CC

Providing feedback

IRA,R,CI

Review and communicate service desk metrics

C, I

A,R,

C, I

C

Provide service desk metrics

C, I

RA, R

Table 2.1 Example RACI chart

RACI charts have certain rules. There must be one accountable role per activity, but there cannot be more than one. If you want to assign two roles to accountable, split the activity so that each has one accountable role. This rule can be applied to RACI charts that include multiple groups, but the activities, commitments, and accountabilities must be reflected accurately. These must also align with contractual or SLA language. There must also be one, or more than one, responsible role per activity. The responsible and accountable roles can be assigned to the same person.

2.2 HOW RACI CHARTS HELP

RACI charts enable the consistent achievement of targets. When working with a range of service relationships, you must understand the structure of the relationship between each service and the involved parties. Once the structure is understood, it must be documented for others to understand and navigate.

This definition helps to drive conversations and align expectations. For example, an organization provides enterprise network connectivity services between sites but network connectivity within a remote site is handled by the regional team. The regional team has outsourced wireless connectivity within the remote sites to an external provider. A RACI chart will define responsibilities within that complex structure. This information can then be used during service mapping and supplier management, among other activities.

RACI charts and service relationships

For decades, the basic formats of RACI charts and service relationships drove role clarity in organizations. With minor adjustments, these tools can provide the same clarity across complex service relationships. Organizations must understand how their external providers integrate into their internal processes. The service relationships within this organization range from formal contracts to informal agreements. Consumers expect seamless delivery. Organizations can use RACI charts to document and broadcast clear expectations to their employees and their external providers.

3.1 DOCUMENTING A PROVIDER-CONSUMER RELATIONSHIP

Organizations should follow defined steps and use consistent templates when documenting the basics of the provider-consumer relationship. Doing this will ensure comprehensive records. Templates should be living documents that are modified for each organization. Building RACI charts based on a common structure allows them to be combined to provide a broader view of the responsibilities in the organization.

Crucially, document activities or decisions that clarify provider-consumer relationships. These documents can then assist in creating service agreements and help to ensure appropriate role assignments throughout the process.

Key areas to document are:

  • What is being provided?
    • A good, a service, an action.
  • Who is providing the service?
    • May involve more than one provider.
  • What are the consumer responsibilities?
    • Specific procedures to request or report an issue.
  • When can services be expected?
    • Lead time, fulfilment time, etc.
  • How are the services provided?
    • Key activities.
    • Delivery mechanism.
    • Integrations (process and tools).
  • How is the service managed (from both parties)?
    • What does the consumer need to do?

The type of agreement between the provider and the consumer determines its level of service and flexibility. Formal contracts are typically used with external providers, but they may also exist within organizations. Informal service relationships function with less documentation than formal contracts, often resulting in unfulfilled consumer expectations.

The provider only has to deliver what has been formally agreed. It may be possible to negotiate additional services in a similar manner to negotiating informal service agreements, but these outcomes are not required and may be dropped or lessened over time.

Agreements with providers must enable commitments to consumers. Hold providers accountable for the delivery of those commitments, whether the agreement is formal or informal.

Figure 3.1 Provider-consumer flow
Figure 3.1 Provider-consumer flow (Click for a larger image)

3.1.1 Using RACI charts to manage agreements

Agreements formalize commitments. Often, agreements detail commitments for both parties. Agreements may range from a single page to a lengthy document. RACI charts help to consolidate the agreement information, make it consumable, and communicate it to a broader audience. Through RACI charts, individuals know what is expected from them and others.

RACI charts can also map criteria from multiple agreements. As more organizations use external providers and as customers expect higher levels of service, a broad understanding of how agreements connect is helpful when making realistic commitments.

3.2 RACI CHART CONTENT SOURCES

So, how is a RACI chart built? Basic RACI charts can be populated at a high level, but if there are difficulties with onboarding new staff, missed activities, or teams communicating poorly, enhance the RACI chart to include the areas causing confusion. Having a checklist of information to include in the RACI chart can reduce the risk of gaps or misalignment.

Understanding ownership and accountability is essential when reviewing an agreement for a service. Ask:

  • Are there expectations for sharing knowledge in the agreement?
  • Who owns the knowledge articles?
  • How will the support and design information be handled at the end of the contract?

The interaction between the provider and the consumer is a critical next step. Where there are government or industry compliance requirements and other requirements that must be factored into the service offering, map the necessary steps to drive consistency, understanding, and transparency.

3.2.1.1 Contract Management

Contract management ensures that contracts currently in place deliver business value. Contracts include information like:

  • service level attainment measures
  • costs and reporting
  • frequency of performance and financial reviews
  • reporting including measurement definitions and data sources
  • escalation procedures
  • scope
  • roles and responsibilities.

In order to manage contracts, contract management activities (which may follow a defined internal process) must be defined and assigned. RACI charts can be useful for ongoing contract management and when escalating issues.

3.2.2 Services

The concept of an end-to-end service allows you to put the provider-consumer relationship in the context of other services, products, or teams. When you know how services connect, it is possible to design a RACI chart to account for related services, activities, and teams needed to provide, consume, and package services to provide additional offerings.

It might be necessary to add roles, document additional requirements or expectations, or detail specific schedules in a RACI chart to meet broader service-based needs. Most organizations do not have complete service definitions, so it can be difficult to reach the right level of understanding. It is easy to expend unnecessary effort and cost when defining service and role assignments, so populate the RACI chart only so far as is necessary to make roles and expectations clear.

Once these provider-consumer relationships are mapped, document and trace the provider structure. Understand the end-to-end delivery commitments, support commitments, costs, volumes, and any other components that could affect the consumer’s experience. However, a RACI chart does not need to be exhaustive; details can be documented in various ways, including configuration management (CMS/ CMDB), monitoring configurations, knowledge articles, and other service documentation.

Each provider needs to factor in the dependent services, resulting in an accurate and simplified consumer view. For example, 100% application uptime cannot be guaranteed if a network only supports a 99.9% uptime service commitment.

Figure 3.2 End-to-end service
Figure 3.2 End-to-end service (Click for larger image)

Although maintenance windows are becoming less utilized as Agile and DevOps methods are adopted, some services continue to deploy changes using traditional methods. Any maintenance window defined within a service needs to be factored in and communicated, regardless of development methods. Maintenance windows need to align to the consumer requirements. For example, change enablement processes need to be understood to provide visibility of changes prior to implementation, so all provider changes are visible. Often, in critical environments, formal approvals for all changes are required to drive minimized risk. For other changes, communication (inform) may be sufficient.

3.2.3 Handoffs

There is inherent risk when transferring a service from the provider to the consumer. When planning handoffs, look earlier in the process to ensure each party will be able to execute the handoff at that point. Consider providing an overview of the delivery plan to the consumer.

The consumer may not be able to change timeframes, but they can prepare their teams. This usually involves filling out a request for change in the consumer system. The request can be initiated by the consumer or the provider, depending on the terms of the agreement, and is dependent on the type of access provided. The provider may have access to the consumer’s ITSM tool for user query submission and closure. The consumer may also choose to move the internal organization to the provider’s tools. Having this mapped out reduces the risk of delays during incidents prolonging business impact.

The visibility of planned activities is another important area. When visibility is consistent, teams know what is upcoming and what their responsibilities are, and handoffs can happen as planned. Documenting expectations for the awareness of future activities in a RACI chart grounds the understanding and aligns all parties. This understanding also aligns expectations for work going forward.

Handoffs should be represented as activities and can connect individual RACI charts. Think of each relationship as self-contained, with inputs and outputs based on a simple relationship. Determine who is performing certain activities, what is coming into the relationship, and what is delivered based on the defined roles and responsibilities within that specific relationship.

3.2.4 Communication

After the handoffs have been documented, document the necessary communication activities. Examples include defining who will communicate with the consumer about an incident and who will attend a review meeting about the service.

Beyond understanding communication with the consumer, it is essential to understand how communication occurs throughout the provider-consumer relationship. There are inherent challenges with communication between teams, including that teams can become ambivalent about improving communication or that they underestimate the value of current communication.

Some organizations limit who can talk directly to specific groups, such as business partners or executives. It is important to understand these constraints when building a RACI chart. Pay attention to any information needed for communication outside the provider-consumer relationship. This dependency should be noted to ensure the efficient and effective routing of information to support communication activities.

Types of service provision

Most organizations include internal and external providers, and some have shared service providers within their service relationships.

A shared service provider functions like an external provider, but within the organization, providing services to multiple internal groups. These groups may be in other locations or may be separate entities under the same parent company. Their typical objective is to combine resources internally and provide those back to the organization to gain efficiencies and reduce overall cost.

4.1 PROVIDER VISIBILITY

There are often limits to a party’s visibility of the service relationship. For example, an external provider may have contact with an IT department but will have no visibility into how the IT department provides their service to consumers. Also, requirements, such as response targets or request mechanisms, may come from other agreements, causing the external provider to have different expectations than the internal consumers; for example, regarding delivery times.

Provider visibility is crucial to understand when navigating contracts, service commitments, and other expectations. Do not assume that external providers have the knowledge they need; give them that information. Visibility drives both parties to common goals and facilitates the understanding of existing constraints. Relationships become much easier to manage once each party’s scope, accountabilities, and other obligations are understood. Collaborating and promoting visibility is a guiding principle in ITIL 4.

4.2 MULTIPLE SERVICE OFFERINGS

As the service relationship evolves, adding multiple providers, it can be complicated further when multiple consumers require different deliveries for the same service. For example, a business unit may have a business support team instead of utilizing support provided by IT. Shadow IT departments come into organizations for many reasons.

For example:

  • IT cannot meet the needs of the organization
  • the organization has a third party providing the service and that service does not integrate with other IT services
  • the shadow IT department has always been in the organization and there is no pressing need to move it.

Figure 4.1 Varying levels of service
Figure 4.1 Varying levels of service

The differences in service offerings may be a result of how an organization delivers its services. This can be seen in the concept of multi-speed IT (that utilizes Agile and waterfall methods). There may be one service that is built around Agile and a second service that is more aligned to the waterfall approach. By providing multiple service offerings, the consumer can select the one most aligned to their needs.

Figure 4.1 depicts an example of varying levels of service offered to consumers. In this example, the IT service provides two service offerings, one for each type of consumer. Service Offering A does not include support because the business unit fulfils that function. IT would manage the assets, but the business provides the end-user support. The IT department provides support functions for Service Offering B to other business units as they are looking for IT to provide that service.

When there are separate levels of service across business units, the service relationship requires a more refined structure to account for the differences in the service offerings. There should be a RACI chart for the service offering without the support function and another for the service offering with the support function. The RACI chart with the business-supported service should have additional clarification on the handoffs, visibility, authority, and other attributes to ensure all parties understand how the activities are performed and managed.

Another example of multiple levels of service is from a technology perspective, where it is normal to host an application on a cloud platform with different providers delivering and supporting the data centre, platform, application, and networking services. Additionally, understanding the support processes and the handoffs across providers is crucial when considering the inclusion the support functions for the service, which include:

  • provider system administration
  • service desk
  • service management
  • monitoring
  • discovery
  • technology administration
  • IT asset management.

Any service may be provided internally, externally, or through a shared service provider. Establishing the handoffs between the providers can be extremely challenging and could result in negative results for the consumer, including unplanned downtime.

The following diagrams demonstrate the difference between simple and complex service relationships.

As figure 4.2 shows, services can be provided directly to the consumer. Each arrow indicates the delivery

Figure 4.2 Simple service relationship
Figure 4.2 Simple service relationship

Figure 4.3 depicts services provided through both an internal provider and directly from an external provid- er. Each relationship should be included in an overall view. Without this overall perspective, each service is managed in isolation, limiting the visibility of how the service is delivered and increasing complexity.

Figure 4.3 Complex service relationship
Figure 4.3 Complex service relationship

An example

Now, an example of how to bring all of this together.
Elaine has been an Operations Director at an engineering firm for the last 15 years. She wants to outsource some capabilities, including service desk, desktop support, and security administration. SD Hub will provide the service desk and desktop support functions. Another provider, SecureAdmins, will provide the security administration.

Elaine wants everyone to understand what they need to do, ensuring that the work gets done in a timely and accurate manner. She follows these steps to understand how the teams and services connect to delivery services.

  1. Agreements: Elaine reviews the contract with SD Hub and extracts essential information, such as roles and responsibilities, measures, processes, reviews, financial penalties, escalations, and scope of the service provided. She starts a RACI chart with these items and the minimum roles of consumer and provider.
  2. Services: Elaine reviews the RACI chart and adds service information from within her organization that might not be explicit in the contract. She asks if other services rely on this provider. If so, Elaine wants to start a separate RACI chart to build out the relationship between her and her consumers. She needs to understand where the service she provides to the consumer comes from and what requirements come from each side. Elaine wants to align these two RACI charts to deliver more value to her consumers.
  3. Handoffs: Elaine needs to provide additional detail around the handoffs between the organizations. How is the service requested and delivered? What approvals are needed and what information is needed to get those approvals? If there is an additional cost or review, how are those included in the ongoing activities performed? If the provider needs to perform a change, how is that done? Elaine needs to think through the processes that the provider and the consumer engage in and provide that structure through each RACI chart. She uses her existing process flows to build out these interactions to ensure the expectations are clear to all parties.
  4. Communication: Elaine can now align the communication activities on the RACI chart for each party. How are major incidents communicated? How can consumers interface with the service desk or desktop support? Does the provider play a role? Do they follow the same process, or does it change once desktop support is assigned the user query? How does the desktop support group communicate with the provider for any issues? How does the provider communicate with Elaine’s consumers? Elaine needs to structure both RACI charts for consumer-facing activities and internal IT activities to provide useful documents to help all groups deliver on expectations.
  5. Governance: Elaine needs to account for the provider review as part of the governance function. Her consumers may only be informed for this activity but may be consulted for feedback on the provider before the meeting. The provider needs to be able to see the internal consumer reviews on their RACI chart to ensure the correct attendance in the meeting or to distribute reports to support the meeting’s agenda. The provider does not need to see the details of how Elaine interfaces with her consumers. Enabling a holistic view of reviews allows for timely and accurate information to be leveraged.
  6. Elaine will repeat the previous five steps with SecureAdmins. If changes are needed, the existing RACI chart can be updated
  7. An overall RACI chart is completed, showing the end-to-end structure that aligns to the delivery to the consumer. This RACI chart is not defined at the individual role, but rather the at the organizational level. It covers the significant activities from the individual RACI charts.

Figure 5.1 Example service relationship
Figure 5.1 Example service relationship (click for larger image)

As figure 5.1 shows, many areas provide details that make RACI charts usable tools, rather than exercises completed during process design and then forgotten. The visibility RACI charts provide improves the accuracy and effectiveness of the tools used to manage the overall service relationship.
Service relationships often change over time. These changes need to be reflected in the RACI documents to accurately reflect the service relationship. For example, a change within one provider-consumer relationship may affect other parts of the overall service relationship.

RACI charts should be reviewed:

  • regularly (annually, quarterly, etc.)
  • as part of any process definition or refinement effort
  • during organizational changes
  • as part of annual planning
  • based on feedback or findings through improvement processes or problem management
  • after introducing a new tool or tool capability
  • after automation changes.

Summary

Ultimately, the consumer sees one service and it is the provider’s responsibility to manage that service. When it is unclear who is accountable for what, managing becomes risky. A lack of clarity can impact business processes. By breaking the overall service relationship into components with distinct activities and handoffs, the service is more likely to be successfully delivered and continually improved.

An excellent tool to help manage this complexity is the RACI chart. The RACI chart should detail each provider-consumer relationship and the holistic service relationship. Building this overall RACI chart structure is time-consuming but ultimately drives efficiency. A RACI chart provides teams with a view of the interchanges with the provider. This understanding drives effective issue resolution and improvement identification.

The provider is accountable for defining a RACI chart at this level so that they understand what to deliver as a provider and expect as a consumer. Without this robust definition, there is a risk of disenfranchising consumers.

About the author

Angie Pederson has focused on IT Operations in roles including IT Leadership, Service Management, Infrastructure Project Management, Platform Engineering, and Architecture. Currently a consultant for Sirius Computer Solutions delivering ITSM and Operations Management services, Angie has over twenty-five years’ experience within organizations and through IT consulting. With industry knowledge in financial services, healthcare, retail/distribution, and engineering, she leverages first-hand experience with industry knowledge to drive effective operational practices in situations including internal and sourced organizational models.

Accountabilities in a complex service relationship