cmmi,egov,gap,itil,maturity,architecture,asset,capability,cycle,domain,enabler,enterprise,itil,life,togaf,foundation

1. ITIL Process Maturity Assessment
xxxxxxx IT Department

2. 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 reasons
x1. The clear mission and vision that adopt ICT as success factor
2. Management support and commitment to xxxxx mission and vision
3. 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

3. 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 areas
T
Document scope

4. Before commencing with the
plan to implement ITIL best
practice framework in the IT
Department, it is necessary to establish a documented baseline of:
All identified services. IT Department will need to conduct a strategic exercise with
the Management of the governmental organization in which the result will be to
identify and define the services that is required to be offered. Cost of
implementation should be weighed against defined benefits. It should be noted
that Service chargeability is the only dimension of the exercise that will not be
relevant to the overwhelming majority of IT Departments in the government of
Saudi Arabia
Assessment of all processes maturity that are considered for implementation
All work procedures followed in the IT Department
Roles and responsibilities of the staff working in the IT Department
Assess if organizational structure changes are required. Two functional entities will
be a must if the full scale implementation will take place: Service Desk Function
and Service Level Management Group
Assessment 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 addressed
before commencing with the ITIL implementation. These gaps should be handled in
the
form of recommendations and must be implemented separately. Sometimes, the
recommendation 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

5. 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 prioritization
exercise will focus on aspects such:
IT Department readiness as a result of gap closure phase
The dimension of complexity of service offering tightened to the comprehensive
implementation of processes can create a complex project to implement. Hence,
we need to be realistic in defining the real requirement to implement the needed
scope of processes
Never undermine the issues related to Management of Change. As it is the human
nature to resist changes, there will be always the burden of introducing the
changes at the right pace and speed
In term of process prioritization, ITIL best practice framework highlights certain
considerations for the IT Departments such as:
We can always start with Service Level Management as it really defines the depth
all other processes will need to consider
Service Desk Function and Incident Management Process go hand-in-hand
Change, Configuration, and Release Management can follow
Problem Management Process is recommended to be implemented only after
Incident Management Process reaches a certain maturity. Due to the conflicting
nature of Problem Management and Desk and Incident Management, the process
should not be governed by the same functional entity
Service Delivery Processes (other than Service Level Management) can be
implemented after Service Support Processes. However, the part related to
defining acceptable capacities and availability has to be undertaken by Service
Level Management
Process Prioritization

6. • The implementation of ITIL processes
(either one or more) must be handled
as a project.
• 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.
Handle
Implementation as a
Project

7. ne very important aspect of ITIL implementation is to conduct a process
assessment exercise as part of the base-lining activities. This exerciseois 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 implementing
ITIL Processes
Identify pain areas that raise challenges to the IT Department in their daily
operation and can be addressed through implementing ITIL processes
Show the value that ITIL implementation can bring to the IT Department
Emphasize that the concepts of ITIL adoptions and Service Management are not
luxuries that can be done without
The assessment covered the following areas:
General questions related to the readiness of ITIL implementation
Incident Management Process
Problem Management Process
Change Management Process
Release Management Process
Service Management Process
ITIL Process Maturity Assessment
Context
Scope of Assessment (as advised by xxxx )

8. GeneralITILReadiness
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

9. IncidentManagementProcess
Are incident records maintained for all reported
incidents?
Are all incidents managed in conformance with the
procedures documented in SLAs?
Is there a procedure for classifying incidents, with a
detailed set of classification, prioritization and impact
codes?
Is there a procedure for assigning, monitoring and
communicating the progress of incidents?
Does incident management provide the Service Desk
or Customer/User with progress updates on the status
of incidents?
Is there a procedure for the closure of incidents?
Does incident management match incidents against
the problem and known error database?
Are Service Level Agreements available and
understood by incident management?
Are requests for changes produced, if necessary, for
incident resolution?
Are resolved and closed incident records updated and
clearly communicated to the Service Desk, customers
and other parties?
Do you provide management with information
concerning escalated incidents?
Have the interfaces between the Service Desk and
incident management been defined and
communicated?
Does incident management exchange information with
Problem Management concerning related problems
and / or known errors?

10. ProblemManagementProcess
Is there a procedure for problem management?
(Concerning analyzing significant, recurring and
unresolved incidents and identifying underlying
problems, classification of potential problems, in terms
of category, urgency, priority and impact and assigned
for investigation?)
Are at least some problem management activities
established in the organization, e.g. problem
determination, problem analysis, problem resolution?
Have responsibilities for various problem management
activities been assigned?
Is the nature of the problem always documented as
part of the problem record?
Is Problem Management responsible for the
completeness of all problem records?
Are the standards and other quality criteria made
explicit and applied to problem management activities?
Does Problem Management provide management with
information concerning recurring problems of a
particular type or with an individual item?
ChangeManagementProcess
Are at least some change management activities
established in the organization, e.g. logging of change
requests, change assessments, change planning,
change implementation reviews?
Have responsibilities for various change management
activities been assigned?
Are the procedures for initiating change always
adhered to?
Is there a procedure for approving, verifying and
scheduling changes?
Are all changes initiated through the agreed change
management channels, for example a Change
Advisory Board?
Are changes planned and prioritized, centrally or by
common agreement?
Are formal change records maintained?
Is a change schedule of approved changes routinely
issued?
Are there standards and other quality criteria for the
documentation of change made explicit and applied?
Does Change Management exchange information with
Configuration Management regarding change progress
and change closure?

11. ReleaseManagementProcess
Are explicit guidelines available on how to manage
release configurations, naming and numbering
conventions and changes to them?
Does Release Management verify information
concerning the release? (Like number of major and
minor releases within a given period, number of new,
changed and deleted objects introduced by each
release, the number of problems in the live
environment attributable to new releases)
Are at least some release management activities
established within the organization, e.g. procedures for
the release and distribution of software?
Have roles and responsibilities for various release
management activities been assigned between
operational groups and development teams?
Does incident management provide the Service Desk
or Customer/User with progress updates on the status
of incidents?
Are there operational procedures for defining,
designing, building and rolling out a release to the
organization?
Are there formal procedures for purchasing, installing,
moving and controlling software and hardware
associated with a particular release?
Are there formal procedures available for release
acceptance testing?
Are requests for changes produced, if necessary, for
incident resolution?
Are plans produced for each Release?
Are back-out plans produced for each Release?
Is there a library containing master copies of all
controlled software within the organization?
Does Release Management exchange information with
Change Management concerning change records for
any new / changed CIs?

12. ServiceLevelManagementProcess
Do you check with the customer if the activities
performed by the IT department adequately support
their business needs?
Do you check with the customer that they are happy
with the services provided?
Are you feeding customer survey information into the
service 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 management
activities been assigned?
Has a catalogue of existing services been compiled?
Are there mechanisms for monitoring and reviewing
existing service levels?
Do you compare service provision with the agreed
service levels?
Are the standards and other quality criteria for SLM
documented?

13. 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
A
Indicators.
Process Maturity Indicators

14. hose targets were set by the e-Government Program for
Riyadh Principality for ITIL IMPLEMENTATION PHASE 1T
Process Maturity Level
1 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)
Process Maturity Targets

15. rom the result we concluded that Problem management
capability need improvements we will move a step forwarded
to support this conclusion by doing gap analysisF
Process Maturity Level
1 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)
Process Maturity Result

16. 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

17. 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.

18. ITwould 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 agent
when 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 a
Workaround : 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 incidents
occur.
Implementation of a Problem Management
process

19. Input
1. Incidents with a necessary investigation
2. Analyzing incidents and trends
Activities
1. Logging of a problem
2. Verification of the problem
3. Forward to support
4. Investigation
5. Logging of a Known Error
6. Logging of a RFC
7. Resolution of the problem
8. Verification of the closure
Output
1. Closure of the problem
2. RFC
Problem management process (TO BE)

20. Logging of a
RFC
InvestigationForward to
level 2
Resolution
of the
problem
Logging of a
RFC?
RFCLogging of a
Known Error
Verification
of the
closure
Verification
of the
problem
Verification
of the
problem
Logging of a
problem
Logging of a
problem
Level 2
or 3
agents
Level 1
or 1.5
Local
manage
Incidents
with a
necessary
investigation
Closure of
the problem
Analyzing
incidents
and trends
OutputLevel 1
or 1.5
agents
Level 2
or 3
Local
manage
InputLogging of a
RFC
InvestigationForward to
level 2
Resolution
of the
problem
Logging of a
RFC?
RFCLogging of a
Known Error
Verification
of the
closure
Verification
of the
problem
Verification
of the
problem
Logging of a
problem
Logging of a
problem
Level 2
or 3
agents
Level 1
or 1.5
Local
manage
Incidents
with a
necessary
investigation
Closure of
the problem
Analyzing
incidents
and trends
OutputLevel 1
or 1.5
agents
Level 2
or 3
Local
manage
Input