ITIL Process Maturity Assessment

xxxxxxx IT Department

xxxxxxx is a governmental entity which serves as hub of the services the yyyy government provides to the citizens in XXXX. The xxxxx has achieved a good Maturity level in its IT operation and services, this has happened due

to many reasonsx1. The clear mission and vision that adopt ICT as success factor 2. Management support and commitment to xxxxx mission and vision3. The adoption of the standard frameworks (ITIL,PMI,TOGAF,COBIT)

O – Improve the quality of people’s life without any discrimination, transcending regional and racial differences, and realize socio-economic development by building a transparent government and providing value added quality services through ICT T

Value Networking Government through 1.Citizen-centered service

2.Transparent service 3.Networked government

4.Knowledge based society

One of the best 10 Government organizations according to the e-Government measures 99.999% Service availability 90% business process Automation More than 750,000 cases have submitted and processed during the year of 2011 More than 20 million documents have been archived and indexed. 23 business applications have been developed, deployed Fast WAN that connect 25 distributed data centers 120 server running 24/7 to support business needs 900 workstation used by employee Multiple e-services delivery channels (IVR, KIOSK ,SMS, smart phones)

Exertive summery

Vision

Mission

Achievements

he purpose of this document to asses the maturity level which has been achieved by xxxxx in its phase 1 ITIL process Implementation , then to start a process improvement exercise for

the main weak areasT

Document scope

Before commencing with the plan to implement ITIL best

practice framework in the ITDepartment, it is necessary to establish a documented baseline of:All identified services. IT Department will need to conduct a strategic exercise withthe Management of the governmental organization in which the result will be toidentify and define the services that is required to be offered. Cost ofimplementation should be weighed against defined benefits. It should be notedthat Service chargeability is the only dimension of the exercise that will not berelevant to the overwhelming majority of IT Departments in the government ofSaudi ArabiaAssessment of all processes maturity that are considered for implementationAll work procedures followed in the IT DepartmentRoles and responsibilities of the staff working in the IT DepartmentAssess if organizational structure changes are required. Two functional entities willbe a must if the full scale implementation will take place: Service Desk Functionand Service Level Management GroupAssessment findings of staff readiness in term of capability and capacity

Identified required tools that can help in the automation of ITIL processes

It is definite that the base lining exercise will identify gaps that need to be addressedbefore commencing with the ITIL implementation. These gaps should be handled in theform of recommendations and must be implemented separately. Sometimes, therecommendation implementation will be considered as a transitional phase of the ITIL implementation, and many successful implementations depend on the outcome of this intermediary phase

Processes assessment Considerations

Gap Analysis and Recommendations

Establish a Baseline for Implementation

Upon closing the identified gaps from the base lining exercise, there will be a prioritization

exercise related to the processes that need to be implemented first. The prioritizationexercise will focus on aspects such:IT Department readiness as a result of gap closure phaseThe dimension of complexity of service offering tightened to the comprehensiveimplementation of processes can create a complex project to implement. Hence,we need to be realistic in defining the real requirement to implement the neededscope of processesNever undermine the issues related to Management of Change. As it is the humannature to resist changes, there will be always the burden of introducing thechanges at the right pace and speedIn term of process prioritization, ITIL best practice framework highlights certainconsiderations for the IT Departments such as:We can always start with Service Level Management as it really defines the depthall other processes will need to considerService Desk Function and Incident Management Process go hand-in-handChange, Configuration, and Release Management can followProblem Management Process is recommended to be implemented only afterIncident Management Process reaches a certain maturity. Due to the conflictingnature of Problem Management and Desk and Incident Management, the processshould not be governed by the same functional entityService Delivery Processes (other than Service Level Management) can beimplemented after Service Support Processes. However, the part related todefining acceptable capacities and availability has to be undertaken by ServiceLevel Management

The implementation of ITIL processes (either one or more) must be handled as a project.

Handle Implementation as a Project

Process Prioritization

All aspects related to the project must be addressed and covering developing a business

case, Detailed Project Plan, Detailed Communication Plan, allocate dedicated resources

to the project, and requesting clear milestones and achievements. The concept of Quick

Wins must also be identified and defined at this stage. Quick wins are all improvements

that are perceived and acknowledged by the customer during the early phases of the ITIL

implementation. To the ITIL implementation team, quick wins are all milestones that can

help in achieving preset goals during the early implementation project. A clear implementation roadmap must be developed and approved by the

organization management and not only IT management. The defined roadmap need to

take into consideration the four areas of IT Service Management Alignment: Service,

Process, Organization, and Technology. Below figure represents a sample roadmap.

ne very important aspect of ITIL implementation is to conduct a process assessment exercise as part of the base-lining activities. This exerciseo

is needed to capture information about the status of processes currently adopted by the IT Departments operation to:

Measure the IT Department interest and reaction to the concept of implementingITIL ProcessesIdentify pain areas that raise challenges to the IT Department in their dailyoperation and can be addressed through implementing ITIL processesShow the value that ITIL implementation can bring to the IT DepartmentEmphasize that the concepts of ITIL adoptions and Service Management are notluxuries that can be done without

The assessment covered the following areas:General questions related to the readiness of ITIL implementationIncident Management ProcessProblem Management ProcessChange Management ProcessRelease Management ProcessService Management Process

ITIL Process Maturity Assessment

Context

Scope of Assessment (as advised by xxxx )

Gen

eral

ITIL

Rea

dine

ss

Is the business committed to the use of ITIL

Do you provide management with information concerning operational performance (including analyses) of the different processes?

Are there standard reports regularly produced)operational reports, KPI's and service performance(

Does the IT-department comprehend how the IT services add to the business?

Has the purpose and benefits of the different processes been advertised within the organization?

Is the IT-staff trained on ITIL, standards and all related procedures؟

Do your regularly organize meetings concerning the content of the processes (per process)

Are all links between the processes identified and operational? (E.g. information between processes which is exchanged, procedures, involvement(

Are your processes supported by a service management tool?

ITIL Process Maturity Assessment Questions

Inci

dent

Man

agem

ent P

roce

ssAre incident records maintained for all reportedincidents?Are all incidents managed in conformance with theprocedures documented in SLAs?

Is there a procedure for classifying incidents, with adetailed set of classification, prioritization and impactcodes?

Is there a procedure for assigning, monitoring andcommunicating the progress of incidents?

Does incident management provide the Service Deskor Customer/User with progress updates on the statusof incidents?

Is there a procedure for the closure of incidents?

Does incident management match incidents againstthe problem and known error database?

Are Service Level Agreements available andunderstood by incident management?Are requests for changes produced, if necessary, forincident resolution?Are resolved and closed incident records updated andclearly communicated to the Service Desk, customersand other parties?Do you provide management with informationconcerning escalated incidents?Have the interfaces between the Service Desk andincident management been defined andcommunicated?Does incident management exchange information withProblem Management concerning related problemsand / or known errors?

Prob

lem

Man

agem

ent P

roce

ssIs there a procedure for problem management?(Concerning analyzing significant, recurring andunresolved incidents and identifying underlyingproblems, classification of potential problems, in termsof category, urgency, priority and impact and assignedfor investigation?)Are at least some problem management activitiesestablished in the organization, e.g. problemdetermination, problem analysis, problem resolution?Have responsibilities for various problem managementactivities been assigned?

Is the nature of the problem always documented aspart of the problem record?

Is Problem Management responsible for thecompleteness of all problem records?

Are the standards and other quality criteria madeexplicit and applied to problem management activities?Does Problem Management provide management withinformation concerning recurring problems of aparticular type or with an individual item?

Cha

nge

Man

agem

ent

Proc

ess

Are at least some change management activitiesestablished in the organization, e.g. logging of changerequests, change assessments, change planning,change implementation reviews?Have responsibilities for various change managementactivities been assigned?

Are the procedures for initiating change alwaysadhered to?Is there a procedure for approving, verifying andscheduling changes?Are all changes initiated through the agreed changemanagement channels, for example a ChangeAdvisory Board?

Are changes planned and prioritized, centrally or bycommon agreement?Are formal change records maintained?Is a change schedule of approved changes routinelyissued?Are there standards and other quality criteria for thedocumentation of change made explicit and applied?Does Change Management exchange information withConfiguration Management regarding change progressand change closure?

Rel

ease

Man

agem

ent P

roce

ssAre explicit guidelines available on how to managerelease configurations, naming and numberingconventions and changes to them?Does Release Management verify informationconcerning the release? (Like number of major andminor releases within a given period, number of new,changed and deleted objects introduced by eachrelease, the number of problems in the liveenvironment attributable to new releases)Are at least some release management activitiesestablished within the organization, e.g. procedures forthe release and distribution of software?

Have roles and responsibilities for various releasemanagement activities been assigned betweenoperational groups and development teams?Does incident management provide the Service Deskor Customer/User with progress updates on the statusof incidents?

Are there operational procedures for defining,designing, building and rolling out a release to theorganization?Are there formal procedures for purchasing, installing,moving and controlling software and hardwareassociated with a particular release?Are there formal procedures available for releaseacceptance testing?Are requests for changes produced, if necessary, forincident resolution?Are plans produced for each Release?Are back-out plans produced for each Release?Is there a library containing master copies of allcontrolled software within the organization?Does Release Management exchange information withChange Management concerning change records forany new / changed CIs?

Serv

ice

Leve

l Man

agem

ent

Proc

ess

Do you check with the customer if the activitiesperformed by the IT department adequately supporttheir business needs?Do you check with the customer that they are happywith the services provided?

Are you feeding customer survey information into theservice improvement agenda

Are at least some service level management (SLM)activities established within the organization, e.g.service definition, negotiation of SLA's etc?Have responsibilities for service level managementactivities been assigned?

Has a catalogue of existing services been compiled?

Are there mechanisms for monitoring and reviewingexisting service levels?

Do you compare service provision with the agreedservice levels?Are the standards and other quality criteria for SLMdocumented?

ny ITIL process maturity measurement exercise will use a process maturity indicators usually ranging from zero to five. Zero indicated a non existent process maturity, while

five is the highest process maturity that is fully optimized and aligned with the business and service requirements. Below figure provides a visual elaboration of the Process Maturity

AIndicators.

Process Maturity Indicators

Process Maturity Level1 Incident Management Process Managed and measurable ( 4)

2 Problem Management Process Managed and measurable (4)

3 Change Management Process Managed and measurable ( 4)

4 Release Management Process Managed and measurable (5)

5 Service Management Process Managed and measurable (5)

hose targets were set by the e-Government Program for Riyadh Principality for ITIL IMPLEMENTATION PHASE 1T

Process Maturity Targets

Process Maturity Level1 Incident Management Process Defined process ( 3)

2 Problem Management Process Initial (1)

3 Change Management Process Defined process ( 3)

4 Release Management Process Managed and measurable (4)

5 Service Management Process Managed and measurable (4)

rom the result we concluded that Problem management capability need improvements we will move a step forwarded to support this conclusion by doing gap analysis F

Process Maturity Result

Gap analysis

From the diagram we can see the green or light gray polygon which represent the AS IS then the red or dark gray polygon which represent TO BE ,The area between the two polygons represent the gap, Examining the Gap lead us the following finding our main problems come from problem management process because the gap area towards the problem process represent the main gap area

Topics for improvement

Potential problems are assessed and identified but they are not recorded into a database : there is no proactive Problem Management with a logging of proactive problems into a database.

Risk : the risk is that more incidents are going to occur.

There is a procedure but this procedure is not enough deployed for analysing significant, recurring and unresolved incidents and identifying underlying problems.Risk : More incidents can occur if the problems are not identified

There is no staff really dedicated to the Problem Management.Risk : The risk is to have a poor Problem Management without sufficient employee involvement.

IT would be necessary to define the type of problem to

be managed and the Problem Management procedures.There are two types of problem :

Reactive problems : Analysing Incidents as they

Occur. The process could be the following : A reactive problem would be logged by a practiced agentwhen an investigation is necessary for one or more incidents. the support team members would identify the root cause and a method of resolving the problem with aWorkaround : a Known Error would be logged into the Known Error Database.Local Problem Manager could also log a RFC (Request For Change) in the aim of resolving the Known Error. The Local Problem Manager would log the RFC into the Service Management tool.When the Known Error would be resolved (with or without a change), the Known Error and the linked problem would be closed.

Proactive problems : Analysing Incidents over differing

time periods and logging problems before incidentsoccur.

Implementation of a Problem Management process

Input1. Incidents with a necessary investigation2. Analyzing incidents and trends

Activities

1. Logging of a problem2. Verification of the problem3. Forward to support4. Investigation5. Logging of a Known Error6. Logging of a RFC 7. Resolution of the problem8. Verification of the closure

Output1. Closure of the problem 2. RFC

Problem management process (TO BE)

Logging of a RFC

InvestigationForward to level 2

Resolution of the

problem

Logging of a RFC?

RFCLogging of a Known ErrorVerification

of the closure

Verification of the

problem

Verification of the

problem

Logging of a problem

Logging of a problemLevel 2 or 3

agents

Level 1 or 1.5Local

manage

Incidents with a

necessary investigation

Closure of the problemAnalyzing incidents

and trendsOutputLevel 1 or 1.5

agents

Level 2 or 3

Local manage

Input Logging of a RFC

InvestigationForward to level 2

Resolution of the

problem

Logging of a RFC?

RFCLogging of a Known ErrorVerification

of the closure

Verification of the

problem

Verification of the

problem

Logging of a problem

Logging of a problemLevel 2 or 3

agents

Level 1 or 1.5Local

manage

Incidents with a

necessary investigation

Closure of the problemAnalyzing incidents

and trendsOutputLevel 1 or 1.5

agents

Level 2 or 3

Local manage

Input