White Paper

Defining, implementing, managing, and measuring the quality and performance of enterprise services in a multi-vendor government environment can be a challenge. In the absence of well-defined services and agreed-upon service levels with clearly identified service dependencies and owners, service providers will typically blame one another for degradations in service and missed Service Level Agreements (SLAs). The best way to mitigate this risk, increase transparency and accountability, and consistently meet or exceed established service levels is to ensure collaboration and cooperation between the government and the service providers. Collaboration is best achieved by tightly integrating the people, the management processes, and the enabling tools or technology. Since 2001, in support of federal and defense agencies, members of G2SF’s IT Service Management practice have been instrumental in leading enterprise level initiatives to seamlessly integrate people, processes, and technology within large and complex multi-vendor environments. These initiatives have resulted in [competing] companies cooperating and coordinating work activities to consistently deliver high quality services in the most efficient manner saving our clients millions of dollars in time and money. This white paper describes G2SF’s proven approach to integrating these critical components of an enterprise service management solution.

 

Where to Begin – Define Your Services

If you don’t know where you are or where you are going, it doesn’t matter what you do or which way you go. It is virtually impossible to establish IT goals and objectives, or measures of progress against one’s goals, without knowing where you are today, what you are trying to accomplish, and where you want to be in the future. When attempting to integrate people, processes, and technology, the starting point is to define the services to be offered by answering the following fundamental questions:

✓ Who are our customers?
✓ What services do they utilize?
✓ What services are most critical to the mission?
✓ Who “owns” a given service?
✓ When and how often is the service used?
✓ When does the service need to be available?
✓ Who is responsible for supporting the service?
✓ What are the service dependencies?
✓ How is service quality measured?
✓ Do the SLAs measure what’s most important?

 

Establish Accountability – Define Service Levels and Create Service Level Agreements

Answers to the above questions should be captured in SLAs prior to assigning responsibility for a given service to a service provider, and/or prior to the start of a contract. Every operational service should have SLAs and the SLAs should describe roles and responsibilities, service performance targets, measures and metrics, support parameters, and service dependencies as reflected in operational level agreements (OLAs). What is necessary to determine accountability for a specific service should be described in the SLA. When new services are in development, their associated SLAs should be proactively developed in parallel with development of the service itself. SLAs should be referenced and accessible via an organization’s service catalog.

In order to successfully establish service levels and associated SLAs that can be tracked, measured, and reported, it is critical to decompose each service and to identify the key features, processes, and dependencies each service has upon other services. It is also important to identify all service providers necessary to meet service objectives and associated service levels. Mapping the various dependencies that are prerequisite to service quality and meeting service levels is critical. When establishing an enterprise service dependency map for the first time, it is essential that the organization manually define and map dependencies in order to validate any automated mapping that may occur in the future using a tool.

 

Develop Partnerships – Map Service Dependencies

discovery-dependency-mapping-example

Discovery and Dependency Mapping Example

One of the most challenging aspects of mapping service dependencies is proactively establishing a strong working relationship with other service providers and clearly defining roles, responsibilities and dependencies each provider has on the other to meet its SLAs. Unfortunately, this collaborative working relationship or “partnership” is usually not properly established until after a service outage has been experienced and the various vendors have begun blaming one another. After a service outage and a significant amount of time spent playing the “blame game,” someone has to sift through the information in an effort to determine the root cause for the outage and whether the outage caused a breach in service levels. Usually, there are penalties associated with a breach of SLAs, depending on the severity of the breach. This is fair and reasonable as long as the penalties are known, understood, and agreed upon by the customer and the service provider prior to contract start. Service delivery responsibilities and performance metrics for each vendor should be clearly defined within operational level agreements that can be used to help mitigate the “blame game” in a multi-vendor service delivery environment.

If this “partnership” between the various service providers is not clearly established up front with specific penalties and dependencies identified, defined, and agreed upon in advance, significant challenges will be experienced by all stakeholders, including the customer.

 

Validate the Linkage of Dependencies and SLAs

When an application does not work, end users and customers typically conclude “the internet is down.” From the end user’s perspective, they do not care what caused the problem that prevents access to an application or service; they simply know that they can no longer accomplish any work. However, from a service provider’s perspective, it is critical to determine the root cause of the service disruption in order to restore service as quickly as possible. In this case, the service disruption could be caused by any number of factors such as a cable cut, a hardware failure, a software error, a data center issue, or other potential technical issues. The culprit could be the responsibility of a given service provider that may be accountable for a wide variety of different, yet mutually dependent services. This is when defined service availability, associated service levels, and service provider dependencies become very important. In this case, in order to successfully restore access to the application, the service provider that has responsibility for the application or service may be completely dependent upon another provider that has responsibility for network connectivity. The application service provider cannot possibly meet their SLAs without the cooperation of the network service provider. The terms of one provider’s support of another in meeting SLAs must be defined and documented in an OLA that is associated with a particular service. This agreement would include timeframe commitments to restore network connectivity that is critical for providing application access and meeting application-specific SLAs. It is also critical that the user community at least be aware of these interdependencies. If an event occurs and it is not covered by the SLA and/or OLA, then the SLA and OLA must be updated to ensure all service dependencies are addressed.

 

Develop a Service Catalog – Manage Expectations

service-catalogue-example

Service Catalogue Example

In speaking with customers about service, we have found that there are often discrepancies, misunderstandings, and overall differences between customer, service provider, and manager expectations within the same organization. The easiest way to mitigate the risk of unmet expectations is to collaborate with all stakeholders when answering the questions above regarding a given service.

 

Answers to these questions should be captured in the SLAs/OLAs and in an organization’s service catalog. The service catalog becomes the repository of available operational services with detailed information about service availability, support, and associated service levels. Service Catalog Management is the process used to facilitate the development and maintenance of a service catalog. The service catalog ensures service provider and service consumer expectations are aligned by defining stakeholder interactions, mutual dependencies, interfaces, and relationships. Documenting the answers to basic service related questions and defining services within the service catalog helps to ensure expectations are consistent among parties.

 

Establish Operational Oversight – Checks and Balances

One of the keys to successfully managing within a multi-vendor service delivery environment is to ensure there is a clear separation of responsibility between operational delivery and oversight of operational performance. Eliminating the conflict of having a single entity responsible for both oversight and delivery is critical to ensuring that the “fox is not guarding the hen-house.” In many cases, oversight is provided by one vendor who is tasked with monitoring and reporting to the government another vendor’s performance in the delivery of services. Designating an oversight role typically does not pose a risk as long as roles and responsibilities are clearly defined and the vendor responsible for providing advisory and oversight of service performance has no operational responsibilities for service delivery.

As previously mentioned, the roles and responsibilities of all stakeholders should be defined in advance to properly manage expectations, answer questions, and eliminate concerns. This should include the identification and mutual agreement of metrics and tools used to measure performance, as well as how performance metrics will be tracked and reported as part of overall performance management and oversight.

 

Summary

To ensure the effective delivery of services and to avoid conflict within a multi-vendor environment, there are a number of critical success factors that must be considered. Services, service owners, and supporting processes to deliver services must be well defined and documented. SLAs that describe service provider roles and responsibilities, service performance targets, measures and metrics, and support parameters should be established for every service in a collaborative manner. Dependencies each provider has on the other to meet its SLAs need to be well defined and documented upfront within OLAs. Service descriptions, SLAs, and OLAs should be published within a Service Catalog. There should be a clear separation between those responsible for delivering the services and those responsible for oversight of operational performance. Expectations for service delivery and measures of service performance should be mutually agreed upon early in the service lifecycle.

G2SF has successfully implemented this approach for a variety of customers in different federal IT environments. Our efforts have resulted in the reduction of risk and the delivery of services that consistently meet and/or exceed SLAs. The critical success factor for this approach is our ability to establish trust between all stakeholders. Trust is best achieved through open, honest, clear, and continual communication. If your organization is experiencing challenges within a multi-vendor environment, please call us at (703) 397-5161 or contact us at bd@g2sf.com.

For more IT Service Management related information, please see G2SF white paper entitled “IT Service Management Assessment – Obtaining the Baseline Measure of Service Performance.”