1

• Background

• Key definitions

• Objectives

• Scope

• Methodology

• Timelines

• Benefits of developing MSAs

• FAQ

2

As part of the implementation of a new entrepreneurial management service model at DAS, four service Enterprises have been created.

Each service enterprise is governed by a Customer Utility Board, which acts as a governing board for those services provided by each Service Enterprise that has been designated as utility services.

One of the key responsibilities assigned to CUBs is the approval of SLA (Service Level Agreement) documents. These are referred to in this presentation as MSA (Master Service Agreement) documents (see definitions), while the term SLA (see definitions) is used to designate a section of the MSA documents.

This document presents an approach to the development of MSA documents within DAS.

3

1. Service: A bundle of activities and resources (IT, people and processes) combined to provide a business outcome or output/ deliverable received by the customer.

2. MSA (Master Service Agreement): A document, specific per program, which includes a service catalog, agreed SLA’s (performance targets) and responsibilities of the service provider and customers, all of which helps improve service delivery, manage expectations, clarify responsibilities and facilitate communication between the parties.

3. Service Catalog: A description of the services and service offerings provided by a program. This can be a multi-level set of information with linked and discrete hierarchies of services, child services and specific ‘offerings’ (specific tasks) available for these services, and will typically include service terms, standards, packages, exclusions, etc.

4. SLA (Service Level Agreement): A written, measureable target for service or process performance agreed between service provider and customers.

5. Service Agreements: Individual documents signed between a service provider and each customer reflecting customer-specific information (choice of services from service catalog, contact information for escalation procedures, etc).

6. Service rate: A price that incorporates the costs of delivering the service at the service levels agreed to by both parties.

4

The objectives for the project are:

1. Develop & provide support for the implementation of Master Service

Agreements with common structure and content across the 4 Service

Enterprises of DAS.

1. Develop/ obtain CUB agreement on MSA common structure.

2. Coordinate / facilitate program specific MSA document development.

3. Provide implementation support.

5

1. Develop / update service catalog

2. Develop additional SLA’s

3. Adapt / convert document to DAS common MSA structure, developing additional MSA content as identified in common MSA index / structure approved by CUBs for all DAS programs

Common activities for areas that have existing

documents

6

FOCUS(common activities

for all MSA’s in DAS)

DEVELOP (specific activities per program/ MSA)

STEP 1: Establish MSA Development

Workgroup

STEP 2: Develop Service Catalog

IMPLEMENT

TA

SK

S

FOCUS• Set up FOCUS

workgroup (common to all 4 Service Enterprises).

• Define / agree on MSA objectives and criteria for developing SLA’s.

• Define / agree on common MSA structure .

• Define / agree on service catalog structure.

• Develop MSA common template.

• Define / agree on MSA common content (across all programs/ Service Enterprises).

• Define common approval and governance processes.

STEP 1• For CUBs with

multiple programs, agree on MSA development / implementation strategy.

• Identify MSA development workgroup members.

• Align understanding/ definitions.

• Review MSA project timelines.

• Review methods to capture customer input.

STEP 2• Identify list of

current services.• Describe &

document current services.

• Capture and document additional operational information (forms, templates, etc.)

• Identify DAS & customer operational commitments.

• Identify opportunities to change (add/ eliminate) the current portfolio of utility services.

STEP 3• Identify key

quality attributes per service/ process.

• Identify performance metrics.

• Establish service standards (performance targets).

• Measure current performance levels.

• Negotiate / agree on SLA´s (targeted performance level).

• Document SLAs.

STEP 4• Develop /

document & complete all additional MSA-specific content that was not developed by the common FOCUS group:• Rates.• Contact data.• Definitions.• Other.

• Report final document to CUB and obtain approval.

IMPLEMENT• Develop & execute MSA

communication plan.• Execute/ sign agency

specific Service Agreements documents.

• Measure & track and report to CUB / all customers on key performance metrics.

• Conduct regular MSA review meetings.

• Periodic evaluation & review of MSA document.

Project management and communication / reporting to CUBs

STEP 3: Develop

perf. metrics and targets

STEP 4Develop rest of MSA document

7

FOCUS(common activities

for all MSA’s in DAS)

DEVELOP (specific activities per program/ MSA)

STEP 1: Establish MSA Development

Workgroup

STEP 2: Develop Service Catalog

IMPLEMENT

DE

LIV

ER

AB

LE

S

FOCUS• Common MSA

document structure/ index.

• Service catalog structure/ elements.

• MSA Template.

STEP 1• MSA

development project plan (specific per MSA/ program)

• Meetings scheduled.

STEP 2• Service catalog

section/ of MSA document.

• Customer & DAS operational commitments.

• Recommended list of new services/ services to discontinue.

STEP 3•Documented metrics and SLAs (targeted performance levels).

STEP 4• Finished MSA

document .• Approval by

CUB.

IMPLEMENT •Communication plan.• Periodic MSA performance reports.• Other reports.

AP

PR

OA

CH

Project management and communication / reporting to CUBs

STEP 3: Develop

perf. metrics and targets

STEP 4Develop rest of MSA document

FOCUS Workgroup sessions

FOCUS team presentation to CUB

SLA DEVELOPMENT TEAMWorkgroup sessions

SLA development team presentation to CUB after steps 2, 3, 4

DAS support team Analysis and documentation of progress

8

1. Set up FOCUS task group (common to all 4 Service Enterprises).

2. KEY TASK: Define / agree on structure of information.

1. Key decisions:

1. Define elements and structure of information in MSA document

and in service catalog section of MSA.

2. Agree on level of detail.

3. Define common templates for MSA and service catalog.

4. Define / agree on MSA common content (across all programs/ Service

Enterprises) (e.g.: basic reporting, SLA amendment process, etc.).

5. Define common MSA approval and governance processes.

9

Service catalog

Service specific

Service level Agreements

Service rates

Service management

processes(reporting, MSA

amendment, remedies, etc)

Customer commitments

Glossary/ Definitions

Operational procedures

(forms, templates)

Process specific

Service level Agreements

10

Proposed draft high level structure for MSA documents:

1. Service catalog (service terms, standards, packages, exclusions, etc.)a) Service terms, packages, standards, exclusions, schedules, etc.

b) DAS & Customer (operational) commitments

2. Service Level Agreements: metrics and targets for service performance and delivery agreed with customers

3. Financial processes information (billing, payments, etc.)

4. Service management processes: • Reporting

• Periodic review

• SLA amendment procedure

• Remedies (e.g, incompliance with agreed service levels, dispute resolution, etc.)

5. Definitions

6. Contact data

7. Appendixes: 1. Hyperlinks to forms & templates to be used (if available) (e.g., to request a new service, etc.).

2. Hyperlinks to written operational procedures (if available )(e.g., ordering, change requests, incident management).

3. Program-specific service rates.11

Each service described in the catalog can have a number of elements/ service attributes.

A key decision is agreeing on what elements each service description must contain and their level of detail.

Different Service Enterprises in DAS may have different service elements, as elements relevant in an IT service catalog (e.g. availability or outage response commitments), may not be pertinent in service catalog for EHRS or Surplus).

12

Key: R = Required for all services / “Minimum” service definition/support B = Required for “Basic” service definition/support A = Required for “Advanced” service definition/support

What is the service?

What’s included?

What’s not included?

How is this service requested?

What forms are used to request this service?

What to ask for?

When can you expect to have your service fulfilled?

What are the availability and outage response commitments for this service?

Is there anything else you need to know about this service?

EXAMPLE : INFORMATION IN CURRENT SDC

SERVICE CATALOG

ELEMENTS R B A IT Specific element?

Question 1: What is the service (Service Description)

R Service summary X

B Features & Functions X

B Bundled/ unbundled offerings X

A Availability, Metrics & Statistics X

Question 2: What is included (Service Description)

R Description of what is included in service X

R Description of standard configuration supported

X X

Question 3: What is not included (Service Description)

R Description of what is not included in service

X

Question 4: How is this service requested (Service Request)

R How is this service requested? X

B What forms are used to request this service?

X

A When can you expect to have your service request fulfilled?

X

A Service Request Process/ Procedure X

R Customer and Service provider commitments

X

Question 5: How do I get help? How does the Service Enterprise provide support this service? (Support, Help and Self-Service)

R Getting Help X

B Self-Service Support X

R Escalation process X

R Communication Plan X

B Eligibility for service X

B Clients and services affected by changes to this service

X

A Testing X X

A Documentation and Training for Support X

R Customer and Service provider commitments

X

Question 6: How does ETS provide this service? (Service Delivery)

B Technical Specifications X X

A Technical Service Delivery Documentation X X

A Related websites X X

13

1. Identify MSA development workgroup members.

Identify workgroup members from DAS and customers.

A team of 6-8 members is recommended for each MSA, with equal numbers of program delivery unit

staff and customers represented.

Aim is having a balanced mix of customers representing different agency sizes and services

contracted in workgroup. Participation from CUB will be preferred, but participated from non CUB

represented customers will be tapped as needed. At least one CUB member will be a member of the

work \group.

Support staff from DAS/DBS will also participate in order to assist and to facilitate the MSA

development process / meetings.

2. Hold preliminary workshop/ meeting with following objectives:

Discuss / align definitions.

Review project timelines.

Review available methods to capture program specific customer input.

Review tasks and criteria to prioritize services- processes.14

1. Workshop to identify structure/ list of current services. Identify high level service structure/ framework (with service

groupings / functions).

Identify service components: individual service offerings within each function /grouping.

Identify linked and/or discrete service hierarchies of services, child services and specific ‘offerings’ (specific tasks) available for these services.

2. Describe current services / service offerings. Describe service items, packages, bundled and unbundled

offerings.

Describe service terms, standards, and exclusions.

Describe service hours/ schedules, contact channels.

Additional content:

Forms? Templates? Operational procedures?

See SDC service catalog

What is the service?

What’s included?

What’s not included?

How is this service requested?

What forms are used to request this service?

What to ask for?

When can you expect to have your service fulfilled?

What are the availability and outage response commitments for this service?

Is there anything else you need to know about this service?

EXAMPLE : INFORMATION

FROM SDC SERVICE CATALOG

15

1. Ideally, the output of the initial workshop between provide and customers would be:

A simple high-level definition of the service structure or framework.

Identification of service components – each service would be defined in terms of its position

in the overall service structure/ framework – i.e. is it part of a larger service, or does it also

have some ‘child’ services or ‘offerings’ which are simply low level service features….?

EXAMPLE OF IT SERVICE STRUCTURE/ FRAMEWORK2. It is important to keep

service catalog workshops

/ meetings to the point on

service definitions, not

SLAs or service issues

(although these

sometimes creep in).

16

1. Identify key quality attributes for each

service (key customer input).

2. Define SLA’s (service specific / Process

specific).

3. Develop good SLA documentation.

Identify customer expectations/ quality

factors

Identify performance metrics

Establish service standards

(performance targets)

Measure current performance levels

(Baseline)

Identify list of services

Publish SLA- Service Level Agreements

(“agreed” performance targets)

Negotiate/ agree on new performance

targets

Develop long term performance

improvement program

Re-establish perf. targets?

Yes

No

Yes

No

Are standards met or can they be met in

the short term?

e.g., by implementing short term performance

improvement actions

Service Level Agreements:

Written measureable targets for service performance agreed

between provider and customers

17

DEVELOP SLA’s PROCESS EXAMPLE FOR EHRS

Identify list of services Client agency recruitment

Identify customer expectations/ quality factors Agile process Quality of candidate list

Identify performance metrics CYCLE TIME FOR RECRUITMENT

Establish service standards SERVICE STANDARD: 60 days

Measure current performance levels (Baseline) BASELINE: 80 days

Are we meeting service standards or can they be met in the short term?

NO (hope to get to standard incrementally in the next 4 years)

Can standards/ performance targets be renegotiated?

Yes

Agree/ publish service level agreement (agreed service performance target)

AGREED SLA: 75 days

SLA DEVELOPMENT

PROCESS: SIMULATED

EXAMPLE FOR EHRS

EXAMPLE OF KEY QUALITY ATTRIBUTES/ DIMENSIONS IDENTIFIED

FOR A SERVICE

18

How Long Does It Take to Establish an MSA?

It depends. Many factors can influence the duration of the effort, such as:

◦ The number and complexity of the services covered: The more services covered by a MSA, and the more complex

these services, the longer it takes the two parties to discuss, negotiate and document the conditions of service delivery.

◦ The availability / commitment of the working team members: Joint service provider & customer work and face-to-

face negotiations are crucial in establishing a MSA. Insufficient commitment or availability of key SLA development

team members can add significantly to the elapsed time.

◦ The choice of performance metrics and the availability of past performance data. In the absence of past

performance information, the team will need to baseline current performance levels before negotiating the final service

level agreements.

◦ The approval/ governance model for the agreement. A complex multi-party approval process, either for the final

document or for any of its key elements, can certainly add to the elapsed development time.

◦ The availability of a base model & template: The first MSA in an organization usually takes the longest. Once it is

completed and in operation, however, both the document and the process can serve as a model for subsequent MSA’s.

If the first MSA is successful, later ones usually proceed much more rapidly.

◦ Prior SLA experience: The most expeditious MSA efforts are ones led or facilitated by SLA developers who have had

prior successful experience establishing MSA / SLA documents.

19

Given these factors, how long should it take to establish MSA/ SLAs in DAS?

Too short

◦ A misconception about MSA’s is that they can be created quickly. Developing a MSA in a week or even a month is both

difficult and inadvisable. It is difficult because of the workload involved in such tasks as negotiating service standards,

establishing tracking mechanisms, preparing supporting procedures, gaining approvals and generating buy-in. And it is

inadvisable because the process is designed to help the two parties build the foundation for a strong, successful, long-term

relationship.

Too long

◦ "Too long" refers not to a specific time period, but to an effort that has stalled and is making no progress. A major contributor

to a stalled effort is that one or both parties fail to bring a serious commitment to the effort. When management allocation of

staff to establish the MSA is insufficient, or the effort is given a low priority, making progress can be a cumbersome task.

Just right

◦ Establishing a MSA is typically a many-month process of information-gathering, analyzing, documenting, educating,

negotiating, and consensus-building.

◦ Given the complexity of services provided by DAS, a tentative period of 3-6 months can be a good rule of thumb. When

circumstances are optimal, 3 months is realistic, and sometimes even less. At the other extreme, if the situation is a complex

one, 6 months may not be enough. However, if significant progress has not been made within 6 months, it's time to stop the

effort and examine why. 20

OCT NOV DEC

Q4 2012

JAN FEB MAR

Q1 2013

APRIL MAY JUNE

Q2 2013

JULY AUG SEPT

Q3 2013

FOCUS (COMMON WORK FOR ALL DAS MSA’s)

SET UP FOCUSTEAM

DEFINEMSA

INDEX/ STRUCTURE

DEFINEREST OF COMMON

ELEMENTS

SET UP WORKTEAM

DEVELOP SERVICE CATALOG

DEVELOP SLA’ s

(PERF. METRICS AND TARGETS)

DEFINEREST OF

MSA

DEVELOP EHRS MSA

APPROVEMSA

IMPLEMENT

COMMU-NICATE

MSA

BEGIN MEASURING & REPORTING

Tentative proposed project plan for the development of EHRS MSA document

21

1. MSA’s help to improve utility service delivery by Providing an objective basis for assessing service quality.

Facilitating the setting of performance thresholds/ targets.

Providing a context for service changes.

Providing a basis for continuous improvement.

2. MSA’s help to create a business orientation by Creating awareness of cost/ performance tradeoffs.

Creating cost/ performance accountabilities.

Providing a link between services and business objectives.

Facilitating the identification and integration of new service offerings.

• MSA’s help to improve communication & strenghten relationships by1. Creating an improved understanding between provider and customer.

2. Facilitating increased sharing of important information.

3. Providing timely feedback about problems and needs between the parties.

4. Reducing the number and intensity of complaints.

• MSA’s help to manage expectations & clarify responsibilities by Clarifying the scope of services and boundaries of responsibilities.

Providing a context for reasonable expectations.

Creating a shared language.

Establishing priorities and service levels jointly between provider and customers.

The process of reaching the agreement is as important as the agreement itself!22

1. MSA development needs to inform 2015-2017 rate development activities – therefore it needs to be finalized before kicking off the rate review process in July 2013.

1. Developing the service catalog is only a part of the MSA development.

2. The services identified in the service catalog need to be described with enough detail so as to enable the identification of performance metrics and targets.

3. The proposed scope for the service catalog within the MSA development process is limited to services already established at the time MSA development begins.

4. However, developing the service catalog section of the MSA document can offer an excellent opportunity for DAS & CUBs to discuss & challenge the existing offering of utility services and identify:

1. New potential utility service offerings for 2015-2017.

2. Additional utility service levels packages (e.g, gold packages)

3. Service offerings that could be discontinued for 2015-2017.

23

2. The MSA development team (with DAS & CUB members) will define new services for 2013-2015 as part of the MSA development efforts

2. If a need for a new service for 2013-2015 is identified as part of the development of the MSA document, a separate, dedicated service design & development team would have to be formed.

3. This team would be led by representatives from the appropriate DAS Program or Service Enterprise and would have participation by CUB members (and possibly by other DAS customers).

4. This team would work independently from the MSA development work-stream in order to conduct the necessary service design and development activities (market research, detailed identification of customer expectations, defining growth projections, cost analysis, technical scoping, development of business case, development & testing of pilot/ prototype, preliminary rate analysis and agency impact modeling, definition of billing processes, development of POPs, etc).

5. The service development team would report its final recommendations/ output to the CUB in order to inform the 2015-2017 rate development process.

24