ITSM Process Governance – Service Reviews

Service Reviews are where all the other work in Process Level Governance converges and is shared with Core Stakeholders at regularly scheduled review meetings.

A Core Stakeholder is an individual within your business at a Manager and above level who has decision making authority and represents a large number of partitioning Service Delivery Groups or Partners. A Service Deliver Group is an internal group of process practitioners. A Service Delivery Partner is a 3rd party vendor who represents an external group of process practitioners.

Core Stakeholders are a much smaller group whose role includes the following attributes:

    • Being a process champion
    • Decision making authority to represent their area’s interests
    • Being a critic
    • Facilitation of process definition, implementation, and adoption for their area
    • Envisioning and documenting orchestration with other teams
    • Attends the regularly scheduled Service Review meeting
    • Participates in process-level governance

What exactly is reviewed with process Core Stakeholders is up to you and your business, however I think it’s important to review the following:

  1. Any suggestions or issues entered into the Process Improvement Forum by the Core Stakeholders. (This will be explained in an upcoming article)
  2. The results of Operational Pipeline Monitoring for the period since the last Service Review. (See previous article on Operational Pipeline Monitoring).
  3. Operational / Performance Effectiveness results for the period since the last Service Review. (See previous article on Operational / Performance Effectiveness).
  4. An update on Change and Release Management release progress.
  5. Process Risk Self-Assessment results (This will be covered in an upcoming article)
  6. Actionable or tension metrics, KPIs (Key Performance Indicators), CSFs (Critical Success Factors), and Dashboards.
    1. Prior to the first Service Review, KPIs, CSFs, and Dashboards need to be developed with actionable metrics. The term “actionable” means that the Process Owner pre-defines the high and low threshold of each KPI and what exact actions will be taken if the threshold or objective is reached. An example would be to have a KPI for Operational Pipeline Monitoring. Let’s say you establish a metric to measure the time it takes for an incident ticket or problem ticket assignment group to accept the assignment and that the OLA (Operational Level Agreement) for this is 10 minutes in the case of a priority1 record. So, you could review a list of any team that did not meet the OLA during the period. You can also establish a threshold of 2% of the total number of priority1 OLA missed.
      1. In the case where you have teams that do not meet the OLA, you can pre-determine that an email will be sent to the manager or director of the team letting them know of the issue and asking that they address the issue.
        1. Teams that miss the OLA should be historically recorded and any team that is seen to have a trend of misses, can be counseled and retrained.
      2. In the case there more than 2% of the total number of priority1 records are missed, you can pre-determine that whenever that threshold is exceeded, mandatory training will be provided to all teams by the process owning team.
    2. Making all metrics “actionable” gives the Core Stakeholders confidence that the Process Owner has their interests addressed continually; and they are better able to support and champion the process. It also makes it very clear to the organization what the objectives and expectations of the process are in order to provide the most effective value to the business (which includes IT) and how the objectives will be maintained. It is very effective in defining what “normal” operational levels of the process are and building awareness of these across the organization.
    3. Defining dashboards, KPIs and CSFs out of necessity means the development of reporting. The business purpose(s) for each report need to be clearly defined. The reports and the business purposes for them should be documented and shared with Core Stakeholders. Any calculations utilized in the reports and KPI’s, CSFs, or the Dashboard need to be documented and also shared with Core Stakeholders. This makes the entire process transparent and provides Core Stakeholders the ability to provide suggestions to improve.

Regular service reviews with Core Stakeholders are very important to the Process Owner. Any new Core Stakeholders need to be trained on the service review process and the remaining aspects of process-level governance, as well as their role as a Core Stakeholder.

Service reviews allow the Process Owner to share process value and progress in a transparent manner, and to ensure Core Stakeholder support is maintained. The reviews pull together the aspects of process-level governance into a well-defined procedure which can be shared with audit entities at any time.