IT Maturity Model – Why Should a Company Undertake ITIL Assessment Process

ITSM Assessment

ITSM Assessments are common mechanisms to measure the maturity of ITSM processes within an organization. There is no official standard or universally-adopted assessment. Instead, various entities have created their own assessment models. These assessments utilize a questionnaire to create a baseline and measure incremental improvements. Also, it is vital to gain agreement and document the desired state. The ITSM assessment outputs create a roadmap. If we know where we are starting, the desired end state, and a process for measuring progress, it is much easier for executive leadership to gain funding and support for an ITIL/ITSM (IT Service Management) organization and its initiatives to execute the roadmap.

Maturity Assessment

Most ITSM assessments are based on the CMMI (Capability Maturity Model Integration) model. The CMMI model has five levels:

CMMI Maturity Levels

• Maturity Level 1 – Initial – There is no documented and adhered to process. Many organizations will baseline their maturity at Level 1 as they begin their process-maturity journey.
• Maturity Level 2 – Managed – Processes are established, and the work is loosely managed, just not executed in a standardized, repeatable manner.
• Maturity Level 3 – Defined – Process inputs and outputs are defined, training established, metrics established, the level of risk is understood, and processes are audited.
• Maturity Level 4 – Quantitatively Managed – As an organization moves toward Level 4, decisions are based on quantifiable data. Leadership leverages process KPIs (Key Performance Indicators) and CSFs (Critical Success Factors) to evaluate a process’s health. Also, these same metrics may be established for projects and programs.
• Maturity Level 5 – Optimizing – Once we move toward Level 5, we make significant data-based decisions. We need to re-focus the direction from process execution to optimization of the process for future iterations. This could include automation and integration with non-IT processes and multiple toolsets. The goal is to optimize against a greater purpose.

Incident Management Process Maturity

ITSM Incident Management Process Maturity

Most ITSM Assessments will evaluate the ITSM process to see where they rate against the five levels above. If we think back to ITSM basics, each method has “process activities” used to carry out a given function. The maturity of an entire process may be broken down into the process activity subcategories. For example, most organisations use a basic Incident Management process (or practice in ITSM4) with the following activities:

• Identification – Identifying a Configuration Item (CI) is – or soon will be – down.
• Logging – Logging the Incident into an ITSM tool.
• Classification – Classifying the Incident using predefined classes.
• Prioritization – Assessing a priority for the Incident using the Priority Matrix.
• Initial Diagnosis – Do we have a quick diagnosis?
• Escalation – Escalating the Incident in one of two ways (Functional and Hierarchical).
• Investigation and Diagnosis – Investigating what is really down and how to resolve the Incident. At times, one small CI is reported down, and an Incident is raised only to find out that it is dependent on a more significant CI, also down.
• Resolution and Recovery – The Incident Management process’s goal is to resolve the Incident as quickly as possible.
• Closure – Closing the Incident in the ITSM tool. This needs to happen as soon as a workaround is established, and the users are no longer impacted.

How Does ITIL Assessment Process Help

If we measure the standardized outcomes of each process activity through the consistent usage of a questionnaire, we will soon find out which ones the organization performs better – or worse – than expected. For example, most organizations do well in all but two or three process activities: Logging, Classification, and Prioritisation. If the ITSM Assessment illustrates a weakness in logging Incidents, it will show that IT members see a CI down or offline and put the fix in without logging an Incident or recording a Change. If the deficient area is classified, training may be required to help with future Incident classification. If prioritization is the low area, the priority matrix may need to be re-evaluated, a practice developed and delivered, or increased leadership support. The latter occurs if Incidents are de-prioritized to manipulate the metrics.

Most organizations are content to remain in a good – not great – state because the law of diminishing returns begins for most organizations once Level 3 has been eclipsed. The cost to move to 3.5 is much more expensive than the move from 2.5 to 3.0. This is where initially gaining agreement on the desired state is vital. There needs to be agreement on what “good enough” and “excellence” look like. If a process is at a 3.5 level, most of the process activities may be very high, and the assessment allows the identification of pain points and logging them in the CSI Register for execution.

ITSM assessments are valuable to most organizations to evaluate progress against the road map, identify areas that are obstacles to success, and establish a mechanism to measure improvement. Many times, Continual Service Improvement (CSI) will be used in connection with these assessments. The areas which need to be addressed are executed in CSI. Measurements and metrics will be utilized to evaluate progress against the goal.

Undergoing an ITSM assessment is not something an organization should do just once. The benefit of tracking success against a goal is not attained if the assessment is not performed at regular intervals, usually annually. The ability to chart progress against the roadmap, moving toward the desired end state, is a powerful tool for executive leadership to show success.