Commonwealth of Massachusetts

Statewide Strategic IT Consolidation (ITC) Initiative

ITIL Process Current State Assessment and Roadmap for ITD

Deloitte Consulting LLP

September 21, 2009

DRAFT – FOR DISCUSSION PURPOSES ONLY

 Table of Contents

1 Executive Summary
General Recommendations 4-5
General Actions 6
Process Roadmap 7-9
2 Six ITIL Process Assessments
Service Asset And Configuration 11
Capacity Management 12
Problem Management 13
Request Fulfillment 14
Incident Management 15
Change Management 16
3 IT Consolidation and Process Integration 18-20
4 Appendices
A: Detailed Findings by Process 23-28
B: Computer Associates 2007 Assessment 30-31
C: ITIL Process Capability/Maturity Assessment 33-38

DRAFT FOR DISCUSSION PURPOSES ONLY -2-

 Components of ITIL: Service Desk

1.0 Executive Summary

DRAFT FOR DISCUSSION PURPOSES ONLY -3-

 Executive Summary: General Recommendations

Recommendation … Desired Attributes and Outcomes

Establish Service Management

• Key Performance Indicators (KPIs) • Management by outcomes that are measurable
• Regular management review meetings • Support customer service focus and culture change
• Process ownership

Change the Culture

• Establish customer service focus
• Education
• Change attitudes and behavior
• Frequent communications
• Tie rewards to Service Management results
• Performance reviews and rewards tied to KPIs

Integration with Secretariats

• Combine process improvement with integration
• Improve success of process and culture change
• Support transformations in operations in support of IT
• Improve IT Consolidation success
Consolidation
• Increase Standardization of Services

Revisit Technology Approach

• Reassess E2E requirements • Avoid carrying over bad practices and workarounds
for prior issues and design flaws
• Ensure support of ITIL processes is part of requirements
for platform tools • Support integration with secretariats

DRAFT FOR DISCUSSION PURPOSES ONLY -4-

 General Recommendations
Establish a Service Management Structure Change the Culture
ƒ Institute KPIs that measure process results, supported by ƒ Service Management Education in Objectives,
measures of process compliance Framework, and Concepts
– Customer Satisfaction; Percentage Change Success; Number of
incidents; Mean Time to Restore Service (MTRS); Percentage of
ƒ Communications expressing the vision of Customer
Service Level Targets met Service as focus, using ITIL concepts

ƒ Institute weekly and monthly KPI review meetings ƒ Individual performance measurements revised to
– Review KPIs for the process, by manager, but also by service,
incorporate performance to KPIs
platform, customer, etc.
ƒ Rewards for success in achieving improvements in
– Monitor performance of service level targets, and trends over time
team performance to the targets
and between teams
– Prescribe remediation actions and track their accomplishment s
– Director-level management participation is essential

ƒ Establish Process Owners, with a reporting relationship to

Revisit Technology and Tool Plans with TSB
a Service Management lead
ƒ E2E requirements
Incorporate Secretariats into Process Improvements – Revisit or redo to ensure process integration is supported

ƒ Opportunity to combine change drivers to support – Ensure that unnecessary process customization is not included
successful adoption of the changes – Align with a tools standard for the Commonwealth
– Drive to Improve or establish processes ƒ Support of ITIL processes and appropriate integration should
– Need to Integrate operations with Secretariats be selection criteria for other tools
– Platform monitoring tools
ƒ Opportunity to establish leadership for the
– Platform management tools
Commonwealth

ƒ Consistency with Secretariats in overall process

architecture and operations
DRAFT FOR DISCUSSION PURPOSES ONLY -5-
 General Process Improvement Actions
2009 2010

Oct Nov Dec Jan Feb Mar Apr May Jun

Service Management

Service Management Lead Appointed

Process Owners Appointed for key processes

Structure

Establish KPIs

Establish Performance Review Meetings

Organization Restructuring

ITIL and Process Training Strategy

Train the Trainers

Prepare Training Materials

Change
Culture

Conduct Training

Plan Communications

Distribute Regular Communications: Customer Service / Process

Include KPI performance as a major component of performance reviews of personnel

Technology

Service Desk Toolset Standard Selection

Upgrade E2E and associated Tools

DRAFT FOR DISCUSSION PURPOSES ONLY -6-

 Roadmap for ITD Process Improvement – Summary Objectives
Legend: Sep 2009 Jan2010 Jul 2010 Dec 2010

Process 1 2 3 4
1.8 2.5 3.0 3+
Incident • End‐to‐End 
Management of the  •Process is Stable and Well‐
Management Publicized • Continuous Improvement driven by 
Process
Service Level Targets and KPIs
2.1 2.5 3.0 3+
Change
Management • Change Results  • Process is Stable and  • Strong process interfaces, especially 
Focus well‐publicized with Service Asset and Configuration 
Management
0.8 1.5 2.5 3.0
Problem
• Process is documented with 
Management • Known Error Database
established roles and  defined  • Process is Stable and Well‐
• Initial Proactive Analysis
objectives Publicized

1.0 1.5 2.2 3.0

Request
•Service Level Targets in E2E 
Fulfillment
are consistent with Service  • Process is Stable and 
Catalog •Process is documented Well‐Publicized
0.6 1.5 2.5 3.0
Service Asset
&
• Document Asset Management process
Configuration • Asset data accuracy • Asset Management Process is Stable and Well‐Publicized
• Formalize Asset Data Repository(s)
Management • Configuration Management repository formalized

0.6 1.2 2.2 3.0

Capacity • Capacity Reporting  • Process is documented
• Capacity forecasting • Process is Stable but not fully developed 
Management • Standards
• Capacity needs are reviewed regularly with all technical platforms

DRAFT FOR DISCUSSION PURPOSES ONLY -7-

Roadmap for ITD Process Improvement - Actions
Legend: Sep 2009 Jan2010 Jul 2010 Dec 2010

Process 1 2 3 4
1.8 2.5 3.0 3+
•Institute central  •Revise 
• OLAs support SLAs and 
management of  Process 
Incident are managed
dispatched incidents and 
Management • Continuous 
•Institute regular  republish
Improvement 
review meetings of  •Train staff 
Procedures based on 
performance with  on revised 
KPIs
improvement actions  process
assigned as needed
2.1 2.5 3.0 3+

• Revise  • Documente • Audit compliance 

Change process to  d Change  with Procedures
Management focus on  Planning  &  • Expand use of 
Change  Testing  Configuration Mgt 
Results Procedures  data now available
• Initiate Post‐ for each 
Implementati technical 
on Reviews team

0.8 1.5 2.5

3.0

• Initial trend analysis  • Create Process 
• Known Error Database 
Problem of Incidents Document
utilized for Incident Mgt
• Formal Recognition  • Train Staff on Process
Management • Process roles established,  
of Problems • KPI in place and 
including  lead on each 
• Major Incident RCAs  performance is 
technical team 
done under Problem  reviewed
• Downward trend in number 
Management • Known Error database 
of Incidents
created and used

DRAFT FOR DISCUSSION PURPOSES ONLY -8-

Roadmap for ITD Process Improvement - Actions
Legend: Sep 2009 Jan2010 Jul 2010 Dec 2010

Process 1 2 3 4
1.0 1.5 2.2 3.0
• Train on the Process
•Ensure E2E  •Document the 
• Defined workflows for 
reflects  Process
Request each Service/Type of 
promised  •Establish 
Fulfillment Request built into E2E
completion  performance 
• Automate request 
time reporting by 
approvals to minimize 
•Service Desk  Service & 
manual nature of BAR 
support role Customer
process
0.6 1.5 2.5 3.0
• Train on the Process
• Create overall process  • Asset information is 
• Institute cycle‐counting 
document complete, process for 
Service Asset to validate data accuracy
• Mandate authoritative  updating is under control
& • Formalize procedures 
data repository • Configuration relationships 
Configuration for sub‐sections of the 
• All technical platforms  are documented
Management process
have configuration  • Software is  also included in 
• Configuration 
template documentation managed data
documentation 
maintained for all 
platforms
0.6 1.2 2.2 3.0

• Complete  • Create Process  • Train on the Process

existing  Document • Establish proactive review 
capacity  • Complete standard  of capacity requirements
Capacity units of capacity for 
reporting • Establish KPIs for managing 
Management services
• Publish  some  the process
standard units  • Create Capacity Plan • IT Consolidation plans 
of capacity for  • Forecasting of capacity  forecasts fully incorporated 
services trends in place into Capacity Plan

DRAFT FOR DISCUSSION PURPOSES ONLY -9-

Components of ITIL: Service Desk

2.0 Six ITIL Process

Assessments

DRAFT FOR DISCUSSION PURPOSES ONLY - 10 -

Incident Management

Definition • The process is defined, but not managed end-to-

end, and there is no review of actual performance or
follow-up to investigate issues or plan
• An incident is an unplanned interruption of a Service, or a improvements
reduction in the agreed-to quality of an IT Service. Gap
Incident Management seeks to restore normal service
operation as quickly as possible.

Description of Opportunity Process Maturity

• Establish Process Owner oversight of all incidents,
including those assigned to Tier 2&3 groups
• Continuous improvement: Manage the process using Scores by Process Activity
KPIs, regularly reviewed, with good performance
rewarded and performance needing improvement Assignment, Tracking 
addressed with action plans and Communication
5.0
• Update and remodel the process in conjunction with IT 4.0
Consolidation integration with Secretariats
3.0
Resolution, Recovery  2.0 Detection, Recording 
and Closure 1.0 and Classification
0.0
Key Decisions/Implications
• The process needs to be revised to improve management
Initial Support, 
• Current CA R6E2E toolset needs to be replaced or Management and 
Investigation and 
substantially modified Quality Assurance
Diagnosis

Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 11 -

Change Management

Definition • The process is defined and managed, but there isn’t

a focus on the results of Change, on its success or
• A Change is the addition, modification or removal of failure, nor on how well change is planned, tested,
and implemented.
anything that could have an effect on IT services. Gap
Change Management controls the introduction of Change
and minimizes the risk of disruption to the business from
its implementation.

Description of Opportunity Process Maturity

• Establish a focus on improving Change Success, Scores by Process Activity
minimizing rework and incidents
• Strengthen the quality of the technical work performed Assess and 
• CAB perform post-implementation reviews of Change Approve
• Strengthen the linkage between Change, Problem 5.0
Management, Incident Management, and Asset 4.0
Management.
3.0
2.0 Build, Implement 
Plan and Schedule
1.0 and Review
Key Decisions/Implications 0.0

• Invest in procedures covering change planning and testing

for each technical team.
• Modification of E2E required to track Change results and
Management and 
the information about the causes/symptoms of failures. Initiate and Log
QA
• Establish regular management reviews of the KPIs, to
drive improvement

Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 12 -

Problem Management

Definition • The process is only an outgrowth of the Major

Incident Process, from Incident Management,
producing Root Cause Analyses for Major Incidents.
• Problems are the unknown cause of one or more • No Proactive measures are performed outside of
incidents. This process determines the root causes for Gap the immediate prescriptions from an RCA.
the Problems and implements preventive measures, or
develops ameliorating work-arounds to reduce the impact
when incidents do occur.

Process Maturity
Description of Opportunity
Scores by Process Activity
• Create the process engine that will improve the stability of
the environment, and the quality of technical operations,
through proactively eliminating the causes of incidents. Error Control
• Establish an improved knowledge base for technical 5.0
operations, in a Known Error database. 4.0
Resolution and  3.0 Identification and 
Closure 2.0 Classification
1.0
0.0
Key Decisions/Implications
Investigation and 
Problem Prevention
• Build a knowledge repository for the Known Error Diagnosis
Database
• Invest in training in Root Cause Analysis and the concepts
and tools required for proactive analysis to identify Management and 
problems Quality Assurance
• Establish the KPI focus on incident reduction
• Create an initial process document Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 13 -

Request Fulfillment

Definition • Process is in pieces, with no process owner or

process documentation covering the whole lifecycle.
• Service levels are promised customers, but there
• The management of the lifecycle of standard, usually are no management controls to achieve the targets.
small changes, from when they are requested until Gap
delivered to the customer, providing for a prompt,
complete, and cost effective provision of the Request.

Description of Opportunity Process Maturity

• Build off the Service Catalog definitions of Services, to Scores by Process Activity
document how they are fulfilled. Create the process from
that analysis.
Assess and Approve
• Support increasing standardization, specifically of work 5.0
processes through documenting them.
• Establish the management controls to achieve the service 4.0
level targets 3.0
2.0
1.0
Key Decisions/Implications 0.0

• Invest in documenting the workflow for fulfilling the

requests. Management and 
Initiate and Log
Workflow
• Invest in a Process Owner, who can create an initial
process document.
• Check accuracy and update as needed the service level
targets
• Establish a role for the Service Desk in supporting the
ordering of Service Catalogue requests.
Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 14 -

Service Asset and Configuration Management

Definition • Process is fragmented, with no overall process

ownership and management
• There is no authoritative asset database
• The identification, recording, and controlling of service • There is no process to measure the quality of the
assets and configuration items, to maintain accurate and Gap process
complete information that supports management • There is no expectation to maintain configuration
decision-making and effective control of these resources. information.

Process Maturity
Description of Opportunity
Scores by Process Activity
• Establish a key process, and the data it generates, that
provides fundamental support for Service Management 5.0
• Reduce wasted energy from duplication of effort and
mistakes from inaccurate data
• Improve financial management, with accurate lifecycle 4.0
data on assets, owned and hosted.

3.0

Key Decisions/Implications
2.0

• Establish a strong Process Owner with authority

• Invest in documenting and then training on the process,
1.0
so staff know how to maintain the asset data
• Designate the authoritative asset data repository and
require it be maintained, even if there is duplicated effort
0.0
in the short term.
• Establish cycle counting of asset data accuracy, and use Configuration Management And Support Configuration Verification and Audit
the results as the key KPI for the process.
Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 15 -

Capacity Management

Definition • Reporting of capacity consumption is partial and,

where done, frequently incomplete and so of limited
value.
• Monitoring the performance and throughput of IT services • No trending of resource utilization to project
and supporting components, to ensure that IT services Gap capacity needs
have the resources required as needs evolve. • Strong suspicion that excessive capacity is
acquired with initial purchases

Description of Opportunity Process Maturity

• Capacity management is needed to support the expansion
Scores by Process Activity
of services, especially with IT Consolidation
• Improved utilization of existing capacity could avoid Business 
expenditures and result in lower rates for services. Capacity 
• Standard units of capacity can support service Management
5
standardization.
• Capacity data can be used by other processes 4

2
Key Decisions/Implications 1

0
• Invest in the time required to complete the reporting of
capacity and add the reporting of utilization trends.
• Invest in the staff time to establish standard units of
capacity. Resource 
Service Capacity 
Capacity 
• Establish reviews of capacity utilization trends and new Management
Management
usage requirements, to start incremental additions (or
reductions) of capacity based on forecast.
Target Score Current Score

DRAFT FOR DISCUSSION PURPOSES ONLY - 16 -

Components of ITIL: Service Desk

3.0 IT Consolidation, Process

Improvement and Process
Integration

DRAFT FOR DISCUSSION PURPOSES ONLY - 17 -

Process Integration points with Agencies, Secretariats, and ITD

• Coordinate on incidents involving more than one organization

• Leverage shared tools
Service Desk • Leverage shared knowledge
• Redirect callers to appropriate resources (ITD vs. Secretariat vs. Agency)

Incident • Coordination of communications and notifications

Management • Coordination of Incident resolution actions

Request • Calls to one organization for services that are the responsibility of
Fulfillment another organization

Change • Coordinate change planning and approval for resources hosted or

Management managed by ITD

Asset and
• Ownership vs. custodianship (e.g., ITD hosts a server owned by
Configuration Secretariat)
Management

• Leverage knowledge beneficial to all: share Known Errors

Problem
• Share responsibility for Root Cause Analysis and Problem elimination
Management (e.g., application support and server management)

DRAFT FOR DISCUSSION PURPOSES ONLY - 18 -

Process Integration – ITD & Secretariats
2009 2010

Oct Nov Dec Jan Feb Mar Apr May Jun

Governance

Infrastructure Services Board (ISB) & subcommittees

Secretariat Service Desk & Desktop/LAN Summits

Service Desk Toolset Standard Selection

General Service Desk

Implementation of Standard Toolset / Integration with legacy, as appropriate

Share / Leverage Procedures

Share Training with ITD

Establish Standard Rules of Engagement for

Routing Calls from one Desk to another
Establish Knowledge Sharing Procedures
Management

Standard for Priority Coding

Incident

Notification/Escalation lists shared

Procedures for coordination of Incident Resolution Actions

Formal, Documented Incident

Management Process
Request

fillment

Help Procedures Provided to Service Desks for Shared Service Catalogue Items
Ful-

Formal, Documented Request

Fulfillment Process
DRAFT FOR DISCUSSION PURPOSES ONLY - 19 -
Process Integration – ITD & Secretariats
2009 2010

Oct Nov Dec Jan Feb Mar Apr May Jun

Establish Standard Policy for

Management

what constitutes a Change

Change

Standard Procedures for Coordinating

Changes Across Organization
Formal, Documented Change
Management Process
Managemen

Establish Shared Repository of Asset Information

Asset

Establish Procedures for Maintaining Asset Data

t

Formal, Documented Asset Management Process

Share / Discuss Common Problems

Management

Share Problem Management Techniques

Problem

Share Known Errors & Solutions

Formal, Documented Problem

Management Process

Secretariats Provide detailed forecasts of Consolidation Plans – for ITD planning

Management
Capacity

Complete definition of standard units of capacity, for each Service

Establish ability to trend capacity consumption

Formal, Documented Capacity

Management Process
DRAFT FOR DISCUSSION PURPOSES ONLY - 20 -
Components of ITIL: Service Desk

4.0 Appendices

DRAFT FOR DISCUSSION PURPOSES ONLY - 21 -

Components of ITIL: Service Desk

A: Detailed Findings

DRAFT FOR DISCUSSION PURPOSES ONLY - 22 -

Incident Management
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ The process is defined, but not managed end-to-end, and there is ƒ There are common procedures for recording incidents. However
no review of actual performance or follow-up to investigate escalation and tracking procedures are not complete .
issues or plan improvement actions
Roles and Responsibilities:
ƒ Some basic capabilities are lacking with the use of the E2E tool,
ƒ There is a Process Owner, but they lack the authority over
such as removing Hold time from record duration in measuring
resolution time, or identifying First Contact Resolved records. groups outside of the Service Desk.
ƒ Major Incident Process is the exception, where the Incident
ƒ The process does not provide sufficient information for trends in
incidents to be used well for proactive Problem Management . Manager is empowered to lead.
Process Interfaces:
Scores by Function ƒ A change calendar is available for review, but passively.
Enabling ƒ Only major incidents generate Problems
Technology ƒ Device information is not available , and there is no Known Error
5.0 database, handicapping investigation and diagnosis
4.0 KPIs and Reporting:
3.0 ƒ Performance to Service Level Targets are reported on a web
Roles and 2.0 KPIs and page (though methodology is suspect), but there does not appear
Accountability Reporting
1.8 1.0
0.0
to be any management review or action driven by performance.
Enabling Technology:
ƒ E2E requires improvement to be an adequate tool.
ƒ Technical teams have some tools for remote resolution ,but there
Process isn’t proactive monitoring to prevent incidents.
Process
Definition and ƒ There is no apparent automation to create incidents from events
Interfaces that are observed by the monitoring tools.
Activities
Target Score Current Score ƒ No reliable asset or configuration management database

Recommendations
ƒ Enhance the role for Incident Management so that the individual(s) truly take responsibility and accountability for incidents throughout
their lifecycle, focusing on attaining results in reducing incident duration.
ƒ Establish a solid plan and timeline for addressing the deficiencies of E2E in conjunction with an overall Commonwealth approach to a
Service Management toolset including the capture and reporting of actionable measures of performance.
ƒ Update staff training : cover an overview of the process , roles & responsibilities, performance metrics, and an explanation of the
codes used (so staff understand how to apply them and why they are important).
ƒ Revise codes to better identify types of incidents and how they were resolved.

DRAFT FOR DISCUSSION PURPOSES ONLY - 23 -

Change Management
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ The process is defined, and has a strong focus on roles and the ƒ Process definition is fairly robust. However, there is no evidence
performance of process steps. of post implementation reviews.
ƒ But there is no focus on results, on whether the changes were ƒ Each technical team should have procedures for their changes
successful and effective.
Roles and Responsibilities:
ƒ Strong lip service is paid to Change Control, but changes still get
ƒ There is a Change Manager and Change Advisory Board (CAB).
made that aren’t approved.
ƒ There is little evidence of independent testing and verification
prior to change implementation.
Process Interfaces:
ƒ There is no apparent linkage made between changes and the
Scores by Function incidents that the change may have caused.
Enabling
ƒ There is no evidence that service asset and configuration records
Technology
5.0 are utilized for planning changes, and no way of verifying that
4.0 they are updated with the change.
3.0 KPIs and Reporting:
Roles and 2.0 KPIs and ƒ There is no apparent tracking of results of changes just the on-
2.1 Accountability 1.0 Reporting time implementation.
ƒ KPIs are posted to the web, but no indication of utilization for
0.0
management
Enabling Technology:
Process ƒ The strongest role of E2E is in identifying Change and capturing
Process standard information, including status.
Definition and
Interfaces ƒ There are templates for change models
Activities
Target Score Current Score ƒ Relationships to Incidents or Problems are the manual recording
of the associated record numbers
Recommendations
ƒ Clearly set and communicate a policy for what constitutes a Change in scope for this process. Establish penalties for policy violations.
ƒ Change focus of measurements from on-time completion of change activities ,to the success or failure of the implemented change.
Track information about the nature and symptoms of failed changes, to provide information for improvement.
ƒ Institute CAB reviews of changes completed in the prior period.
ƒ Review the internal review and testing of changes within the technical teams, to determine if these are adequate.
ƒ Audit changes to determine whether the planning and testing is actually being done, as well as the updating of asset/configuration data.
ƒ As Service Asset and Configuration Management is enhanced, Change Management needs to maintain a systematic linkage to fully
identify the impacts on the services and underlying infrastructure.
DRAFT FOR DISCUSSION PURPOSES ONLY - 24 -
Problem Management
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ Process is not documented, except as the Major Incident ƒ Problem Management is an outgrowth of Incident Management
Process from Incident Management, producing Root Cause and only used for major incidents.
Analyses for Major Incidents. ƒ Process seems to be largely informal.
ƒ Process does not appear to be used to address lower-priority ƒ There is no proactive Problem Management or procedures
incidents beyond identification of a root cause.
ƒ No Proactive measures are performed outside of the immediate Roles and Responsibilities:
prescriptions from an RCA. ƒ There is a Problem Manager but the role is rudimentary and
focused on Major Incident analysis. Needs to focus on finding
real root causes and then eliminating them from environment.
Scores by Function
Enabling Process Interfaces:
Technology ƒ There is no evidence of linkage between problems and changes.
5.0 ƒ There is no Known Error database.
4.0 ƒ Incident data is of limited value as a source of information for
3.0 developing solutions and workarounds. Better codes are needed,
Roles and 2.0 KPIs and and more complete documentation of resolutions by techs.
Accountability Reporting
0.8 1.0 KPIs and Reporting:
ƒ There is some reporting but it is limited to major incidents.
0.0
ƒ Process metrics are focused on completing the RCA, not on
reducing the volume or impact of Incidents
Process Enabling Technology:
Process ƒ There is no Known Error database
Definition and
Interfaces ƒ There is no evidence that there is any consistent process for
Activities
Target Score Current Score recording and tracking problems outside of major incidents,

Recommendations
ƒ Establish Incident Reduction as key metric for Problem Management, adjusting Major Incident Process accordingly.
ƒ Conduct training on performing RCAs – improve the quality and usefulness of the effort in eliminating the causes of incidents
ƒ Implement a knowledge management tool as a Known Error database, usable by both the Service Desk and the technical teams.
ƒ Create procedures for proactive Problem Management, leveraging Incident data, and utilizing Capacity and Asset/Configuration
Management data to identify Problems.
ƒ Create a process document to govern how Problem records will be managed, to start developing the process beyond Major Incidents,
supporting proactive Problem Management. Include how Known Error records are created and updated.

DRAFT FOR DISCUSSION PURPOSES ONLY - 25 -

Request Fulfilment
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ Process is in pieces, some requests treated as incidents, some ƒ There are practices but no overall process definition, and the
as Service Requests, and the activities are different. practices don’t appear to cover the whole lifecycle of a request.
ƒ While there are service level targets established for many service ƒ There is no evidence of defined method for prioritization or
requests, and reporting of performance on the web, there is no escalation.
process to manage and drive the achievement of the targets
Roles and Responsibilities:
ƒ The technology is complicated, with Service Catalogue requests
ƒ There is no process owner, nor any visible management of the
entered into the same module as Change Requests.
process
ƒ There is no apparent formal request approval, outside of the off-
line BAR process.
Scores by Function ƒ Service requests are not centrally monitored. Escalation could
Enabling
come with someone calling to ask for their SR to be expedited.
Technology
5.0 ƒ The Service Desk has no role with most requests.
4.0 Process Interfaces:
3.0 ƒ There is no automation for service requests to generate change
Roles and 2.0 KPIs and requests.
Accountability 1.0 Reporting
1.0 0.0
KPIs and Reporting:
ƒ There are some metrics on Service Requests, posted to the web,
but they are not accurate nor used to manage the process
Enabling Technology:
Process ƒ Service Requests can be in two different parts of E2E..
Process
Definition and ƒ Rudimentary messaging to customers on status of their requests.
Interfaces
Activities ƒ There is no customer satisfaction survey on completed requests
Target Score Current Score

Recommendations
ƒ Document the services and the steps for fulfilling them, to establish a baseline for what requests the process should support
ƒ Ensure that the service level targets are consistent with the Service Catalogue, and re-establish a KPI for success in meeting the
targets
ƒ Establish an owner for Request Fulfillment. Create an initial process document focused on identifying the requests, then succeeding in
meeting the service level targets.
ƒ Records should be reviewed at least monthly to ensure that staff are coding the records properly, and completing status appropriately.
ƒ Establish a role for the Service Desk to support the ordering of Service Catalogue requests.

DRAFT FOR DISCUSSION PURPOSES ONLY - 26 -

Service Asset and Configuration Management
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ Process is fragmented, solely focused on Assets, with no overall ƒ Process documentation is implied in the training material
management or coordination. prepared for the UAPM training. But it isn’t available as a
ƒ Because the process is not followed, the data in the asset reference outside of the training.
database has become inaccurate, resulting in no one using it. ƒ There are many procedures, but they are not joined together to
ƒ Each technical team maintains their own spreadsheet as the comprise a process.
master list of assets. ƒ Some technical teams maintain configuration documents,
capturing some of the information that would be desired in a
CMDB.
ƒ There are no audits of data accuracy

Scores by Function Enabling Roles and Responsibilities:

Technology ƒ There is no RACI for the entire process.
5.0 ƒ The Asset Manager is really a process SME, she has no authority
4.0 over the operation of the process.
3.0 ƒ There is no evidence of accountability for asset management.
2.0 Process Interfaces:
1.0 Process ƒ There is no evidence of linkage between assets/configuration
0.6 Roles and
Accountability
0.0 Definition and items and capacity management and incident management.
Activities ƒ The process is not producing reliable data, and so is failing the
processes dependent on asset and configuration data.
Enabling Technology:
ƒ It wasn’t clear how much of the problem of maintaining the data
was due to the tool, but it likely was a factor
Target Score Process
ƒ There are no discovery tools in use to automate data collection.
Interfaces

Recommendations
ƒ An Asset Manager should be named responsible for enforcement of the entire Service Asset and Configuration Management process.
ƒ Document the process end-to-end. Train staff on the purpose of the process and their role and activities in it
ƒ Mandate the authoritative asset data repository(s) and then start cycle counting to monitor the quality of process compliance, using
asset data accuracy as the key KPI for the process (The repository could be UAPM or any other replacement for Argis, or even
continue with spreadsheets.) Focus first on hardware assets, then expand to software.
ƒ Require every technical team to establish a configuration template and start populating it with relationships between CIs for significant
systems, devices, and applications. Begin the configuration with the Service supported.

DRAFT FOR DISCUSSION PURPOSES ONLY - 27 -

Capacity Management
Maturity Maturity Stage Observations Detailed Findings

Summary Process Definition and Activities:

ƒ The process is rudimentary, primarily limited to some reporting of ƒ There isn’t a documented Capacity Management process.
resource utilization. While the mainframe area is fairly complete, Practices executed by the architecture team still seem to be ad-
most other technical platforms have, at best, incomplete data. hoc based on the availability of the appropriate resource.
ƒ There is some insight to future demands on capacity coming from ƒ There is no trending of capacity utilization and only rudimentary
BARs, but no trending of consumption, so little capacity planning planning for new services.
ƒ There is some evidence that the lack of Capacity Management ƒ There is no Capacity Plan, per se
process and tools is driving acquisition of over capacity.
Roles and Responsibilities:
ƒ Roles are not really established.
Process Interfaces:
Scores by Function ƒ Lack of consistent capacity management inhibits the ability for
Enabling
Technology Incident and Problem Management to correlate incidents and
5 problems to capacity constraints.
4 ƒ Capacity management doesn’t support Chargeback with small
3 standard increments of capacity to support service models for
Roles and 2 KPIs and rates.
Accountability 1 Reporting
0.6 0
KPIs and Reporting:
ƒ There is reporting of consumption through Chargeback process.
ƒ There is capacity reporting of some resources posted to the web,
but no trend reporting.
Process Enabling Technology:
Process
Definition and ƒ There is use of tools like HP Openview, but implementation is
Interfaces
Activities incomplete.
Target Score Current Score ƒ There is no capacity planning tool, or tool to track history

Recommendations
ƒ Complete the reporting of capacity so that all the resources of a certain type are covered, enabling decision-makers to have an
accurate picture of current capacity for that type of resource.
ƒ Create standard units of capacity for Services, as small as possible, to facilitate expanding (or, in the future, contracting) capacity to
meet the needs of increased usage, without incurring large blocks of cost.
ƒ Capture the history of capacity utilization, and start reporting trends and forecasting when utilization will cross a threshold requiring the
addition of additional resources.
ƒ Establish a capacity plan, incorporating forecasts from capacity utilization trends, new business requirements
ƒ Process should be documented, with detailed procedures for reporting and forecasting
DRAFT FOR DISCUSSION PURPOSES ONLY - 28 -
Components of ITIL: Service Desk

B: Computer
Associates Assessment

DRAFT FOR DISCUSSION PURPOSES ONLY - 29 -

Computer Associates 2007 Assessment

• CA was asked to perform an assessment of ITD’s process maturity in the fall of 2007,
reviewing four of the six that Deloitte assessed.
• The results, scored against an ITIL CMM model with values ranging from 0-5, were:

IT Service Management Process CMM Maturity Rating

Incident Management 1.5
Problem Management 0.8
Change Management 1.5
Configuration Management 0
Financial Management 1.5
Availability Management 1.0

“ITD does not have defined and managed processes” p.4

“Culturally, some of the key stakeholders involved in the interviews believed they would
rate quite high in maturity because they felt they have good process in place since their
previous ITIL assessment in 2003; in fact ITD has lots of procedures for how they work;
but they are not joined up by an end to end process or governed by a quality framework
and the shortcomings obvious in workflow are blamed wholly on software.” p.7

DRAFT FOR DISCUSSION PURPOSES ONLY - 30 -

 Computer Associates Assessment Findings

ƒ Process is documented but lacks key process controls, is not consistently understood or
Incident implemented
Management ƒ A single point of contact Service Desk does not exist. And once an incident is dispatched the
Desk ceases to control it.

ƒ No clear distinction between Problems and Incidents, reinforcing a reactive, fire-fighting culture,
Problem and repeat incidents will occur.
Management ƒ The absence of a Knowledge Base of Known Errors, work-arounds, etc., staff are limited in their
ability to restore service.

ƒ “There is a recognized change control process within ITD but more emphasis on process
Change compliance is required and integrated technology to support integrated processes.”
Management ƒ The process focuses on the end of the lifecycle, as the change is being implemented, which is
really “change control” rather than “change management

ƒ “There is no Configuration Management process”.

Configuration
ƒ There is no asset tagging, or standardized naming conventions, and “each platform team has
Management their own way of doing things with their own procedures, documentation and databases.”

ƒ While there is no formal process, there are availability activities performed by platform teams,
Availability but in silos, reactive to customer requirements.

Management ƒ Availability doesn’t play a significant role in the design or maintenance of systems.

ƒ “Services have been defined as component usage of systems and are charged as such.”
Financial ƒ The cost allocation model is difficult to use for reporting and managing the costs of delivering
Management the services.

DRAFT FOR DISCUSSION PURPOSES ONLY - 31 -

Components of ITIL: Service Desk

C: Deloitte Process
Assessment

DRAFT FOR DISCUSSION PURPOSES ONLY - 32 -

 Deloitte’s Service Management Capability/Maturity Assessment
• The assessment was conducted with three parts:
1. Interviews with the process owners or subject matter experts (SMEs), followed by interviews with
participants or stakeholders in the processes
2. Review of the process documentation utilized by the staff
3. Review of the capability of the ITSM toolset utilized

• The interviews utilized a Deloitte assessment tool that provided 20-50 questions for each
process.
o Where there was a process owner or lead SME expert the interview proceeded by asking each
question of the interviewee.
o For the other interviews the assessor asked a subset of the questions, to fill in holes from the
interviews with the SMEs and to validate their description of how the process is actually performed.
o The answers from all the interviews are reflected in the final maturity scoring commentary for each
question.

• In conjunction with the interviews, copies of the process and procedural documentation
were reviewed, and in some cases, examples of specific instances of forms or reports,
such as the system configuration document utilized by the Wintel team.
• ITD’s E2E toolset was reviewed to ascertain its role in supporting the processes
reviewed. But with general lack of satisfaction with the current capabilities of the tool,
and the plans to replace it with an upgrade to CA’s R-11, as well as the replacement of
Argis with UAPM, led to not much effort being expended on this section of the
assessment.
DRAFT FOR DISCUSSION PURPOSES ONLY - 33 -
 Process Maturity Scoring

Score Description
The functional support process is value driven i.e. well-defined
5= institutionalized processes, driven by business value and
continuous improvement
Increasing Level of Maturity

The functional support process is proactive i.e. well-defined

4= pre-emptive processes, interfaces and dependencies defined,
driven by clear service level targets
The functional support process is stable i.e. well publicized,
3=
regular planned activities, with occasional pre-emptive focus
The functional support process is reactive i.e. defined but
2= reactive activities, irregular, unplanned, no clear objectives &
targets
The functional support process is ad hoc i.e. chaotic,
1=
uncontrolled, success depends on individual effort and heroics
The functional support process is non-existent i.e. no
0=
management processes are applied at all

DRAFT FOR DISCUSSION PURPOSES ONLY - 34 -

 Detailed ITIL Process Maturity Model (1 of 2)

Maturity Stages

Current Stage 1 Stage 2 Stage 3 Stage 4 Stage 5

State (Chaotic) (Reactive) (Stable) (Proactive) (Value Driven)
No formal Service Desk or Service Desk A Service Desk role exists and there The Service Desk is recognized as the The Service Desk has the correct Processes are in place to continually
roles are defined. Nobody has overall are people who conduct some point of contact for all users/customers. balance of technical resource to ensure assess the effectiveness of the
Service Desk

responsibility for receiving and owning activities for the Service Desk. The Communications are distributed via the efficient and effective handling of issues. Service Desk and deliver ongoing
Incidents. There is no supporting Service Desk is frequently by- Service Desk - such as informing users The Service Desk has sophisticated call improvements to performance.
technology for logging calls. passed. Service Desk processes are of planned service outages. handling technologies such as The Service Desk is driven by the
not well defined and documented, Basic service levels are in place to knowledge bases, CMDB, IVR, ACD, business needs and demand,
allowing calls to be handled control the Service Desk, and regular Self Help portal etc. providing comprehensive MI to allow
differently. No Service Levels for the customer satisfaction surveys are The Service Desk operates to tightly IT to assist the business in decision
Service Desk are in place. conducted. controlled service levels. making.
A single asset and user repository is
used.

Incidents are not identified, tracked and A basic Incident Management A well structured and enforced Incident Comprehensive SLAs and supporting Incident Management is closely
resolved in a structured and consistent process exists has been Management process is in place, with OLAs exist and all Incidents are integrated with all key ITIL processes
manner. No process exists, and there is documented. periodic reviews and updates made to proactively tracked and escalated to (such as Problem, Change,
Management

no supporting technology and logging The process can be, and is regularly the process to ensure effectiveness. ensure SLA agreements are met. Configuration, Event, Financial
system. by-passed with issues being All incidents are logged, classified and Intelligent Incident resolution tools are in Management etc)
Incident

resolved in a 'hero-based' approach. tracked in a common system. place such as comprehensive Cost to resolve Incidents is monitored
A basic system is used to record Incident Management is well integrated Knowledge Base, CBR, Self-help and assessed with proactive action to
1.8 most incidents, but this is not with Problem Management and Event Incident Management is appropriately continually reduce both the cost to IT
enforced for all incidents. Management providing MI for Trend structured to best meet the requirements and cost to the Business to resolve
Analysis and delivering proactive of the business. incidents
resolutions.
Basic SLAs are in place to monitor
Incident resolution.

A Request Fulfillment process does not Request Fulfillment occurs either A formal Request Fulfillment process is Request Fulfillment provides Request Fulfillment allows the
exist, and no alternative process is in through a basic Request Fulfillment defined, implemented, communicated standardized services which result in Business to gain quick and effective
Request Fulfillment

place to manage requests. Requests process, or via an alternative and enforced. minimized bureaucracy with high-quality access to standard services, thereby
are therefore dealt with in an ad- process such as Incident Requests are differentiated from service. greatly improving the Business
hoc/informal manner where there is no Management. Requests may be Incidents and RFCs Services are commoditized and well efficiency and productivity.
defined approach, or agreed service regarded as low impact Incidents Request Models are defined to ensure managed, ensuring complete control
targets. and processed against the Incident frequently required services are handled over licensing, media and IT
service level targets consistently and within agreed service infrastructure.
1.0 levels. Users are able to access information and
Efficient financial approvals are in place services easily, and satisfaction results
to approve requests in a quick, and metrics indicate wide-spread usage
controlled manner. of the Request Fulfillment process.
Users are clearly informed of the Technology is used to assist in providing
request services available and the Request Fulfillment services - such as
means by which they can request them. self help portals.

DRAFT FOR DISCUSSION PURPOSES ONLY - 35 -

 Detailed ITIL Process Maturity Model (2 of 2)

Maturity Stages
Current Stage 1 Stage 2 Stage 3 Stage 4 Stage 5
State (Chaotic) (Reactive) (Stable) (Proactive) (Value Driven)
The Change Management process A standard process exists and is Change Management defines Changes are assessed and prioritized Change Management is tightly
Change Management

and roles do not exist. Changes are documented for issuing RFCs. The Standard Normal and Emergency against Business needs and impact on integrated with other ITIL processes
not reviewed and approved. process is not always adhered to procedures for changes related SLAs . (e.g. Incident, Problem,
Changes to the IT environment can and can be by-passed. A Change Standard changes are clearly Change Management is closely Configuration, Capacity, Availability
occur without intervention. Manager is responsible for the identified - such as in a Service integrated with Configuration and Release Management)
process and convenes a regular Catalogue Management, assessing changes The change process is regularly
CAB for assessing and approving Change Management is fully enforced against interdependencies of CIs. monitored and improved upon as part
changes. and provides a consistent and trusted Changes are assessed and grouped into of the Continual Service
2.1 approval mechanism for change. change releases in order to minimize Improvement cycle, ensuring
Changes are assessed for IT and disruption to services thorough vetting of changes whilst
Business impact and are fully vetted Changes are assessed post minimizing bureaucratic process
for completeness of implementation by Change administration.
planning/testing/roll back etc. Management.
A forward schedule of change is The Change Process complies with
produced and updated relevant regulations and control
structures (such as SOX, COBIT etc).

No process or repository for Asset A formal Service Asset and Config Formal procedures and processes There are links and interfaces between SACM is used to effectively manage
and Configuration Items exist. process does not exist. Some Asset exist for identifying, categorizing and the CMS and other Service Management all software, hardware and contracts
Relationships between IT data is collected, and some service recording Asset and Configuration systems. SACM information is routinely held within IT. This includes
Service Asset &

infrastructure and services is not relationships are understood, but information in a CMS and Integrated used to assess and reduce impact from managing hardware warranty,
Config Mgmt

clearly understood. these are not consistently stored in CMDB. Changes, Incidents and Problems. monitoring software usage and
a repository, they are spread around Standard naming conventions are Comprehensive procedures exist to track harvesting unused licenses, and
in databases and spreadsheets or used and CIs are uniquely tagged with and efficiently manage software and assisting projects to determine
held within individuals minds. SACM an identifier. hardware deployment and license usage. refresh requirements for deployed
0.6 is more akin to IT Asset Technology is used to support SACM - Suppliers are required to comply with the hardware etc.
Management purely for compliance such as automated CI discovery and SACM processes and standards.
requirements. status tracking.
Relationships between CIs are well
understood, recorded and updated by
procedures to ensure 'house-keeping'
of the SACM data.
Core Problem Management Core Problem Management process A dedicated Problem Management Problem Management effectiveness is Problem Management is fully
activities do not exist such as exists and is documented. Problem team exists who are responsible for tracked and monitored with clearly proactive, working with suppliers to
problem determination, problem Management occurs on an ad-hoc proactive problem determination and defined targets for problem resolution understand development roadmaps.
Management

analysis, problem resolution? basics with no dedicated Problem resolution. Problems are classified for and incident avoidance. Problem Management is closely
Problem

Resolution of problems is entirely Management team. category, urgency, priority and impact Problem Management is closely involved with Architecture and Design
reactive based. and assigned for investigation. integrated with other ITIL processes group to ensure designs address
The bulk of Problem Resolution is Problem Management conducts both such as Incident, Change, Config, current risks and deficiencies in IT.
0.8 recurring Incident-based as opposed resolution of recurring Incidents and Availability and Continuity Management. Problem Management is closely
to proactive Problem Management. also proactive Problem Management. Problem Management proactively works integrated with the Business to
Problem Management is well with development and suppliers to understand and prioritize problem
integrated with the development cycle. understand known issues and areas in-line with Business
resolutions. requirements.

DRAFT FOR DISCUSSION PURPOSES ONLY - 36 -

 Assessment Interviews
Incident Change Problem Asset Request Capacity
Management Management Management Management Fulfillment Management

Emmet Millet 9 9 9 9
Wintel – Bill Legare 9 9 9 9
Change Manager – D. Seaward 9
Argis Team 9
Donna Carnali 9 9 9
Dave Webster – Networks 9
Bill O'Keefe – TFG 9
Michael Creen – TFG 9
Dave Heiniluoma 9
Linda Kelly 9
Majedah Taliep 9
Karim Hadidi – MassMail 9 9 9 9 9
Dan Folloni – Desktop/LAN 9 9 9 9
Helen Caruso – TFG 9
Jim Colbert 9

DRAFT FOR DISCUSSION PURPOSES ONLY - 37 -

 Process Assessment Timeline
4 5 6 7 8 9 10 11
July 20-27 July 27-31 Aug 3-7 Aug 10-14 Aug 17-21 Aug 24-28 Aug 31 – Sep 4 Sep 7-11

Plan
Assessment

Review Documentation

Review ITSM Tools

Select Questions

Select Staff to
Interview

Conduct Interviews

s &Summarize Gaps &

Opportunities

Set Targets for Improved

Maturity

Prepare written
assessment

Assessment
Complete

Process Integration Plan and 9/30

Roadmap

DRAFT FOR DISCUSSION PURPOSES ONLY - 38 -