19Stakeholder management and risk management

Although the ongoing operational processes of service level management (SLM) include activities such as monitoring and reporting, service review and the service improvement plan (SIP), the service level manager as the process owner must execute process control activities as well.

The first is stakeholder management, which is the process that communicates with and influences internal and external environments by creating a positive relationship with stakeholders. The second is risk management, which aims to identify, manage and prevent uncertainties.

Although these two activities are related to the project management discipline, they are highly effective for service level managers who seek to manage their processes better.

19.1STAKEHOLDER MANAGEMENT OVERVIEW

Stakeholder management includes activities such as identification of stakeholders, determining stakeholder requirements, continual communication and managing stakeholder influence.

Stakeholder identification includes the compilation of the list of names, roles and responsibilities of the stakeholders. This list is dynamic and, in reality, evolves as the process itself does. The identification of stakeholders is reviewed and refined periodically. The following is a typical list of stakeholders to be considered for the SLM process:

• Customer and service providers As primary stakeholders in the process, we must first list the official representatives of the customers and the service providers. Those representatives are involved in the service review process.
• Account management In an outsourcing engagement, the account manager must be identified initially and managed throughout the lifecycle of the engagement. The customer’s satisfaction with financial implications is a high priority for the account manager.
• Reporting function The service level manager must identify the function that will support the reporting activities. SLM as a process relies heavily on reporting, and as such the reporting responsibility must be defined. If a reporting analyst is allocated and dedicated to SLM activities, it will simplify the management of the process.

It is also typical for SLM stakeholders to include data source owners, the service desk, SLM staff and other ITIL process owners.

You should allocate time to creating a complete list of stakeholders from the start. Realizing, in future, that a stakeholder has been missed means that new requirements may need to be added to accommodate the needs of the additional stakeholder.

Secrets of the trade

In one of the largest IT service providers in the United States, I helped implement a reporting system for the service level manager. As part of good project management practice, we identified the stakeholders and kept in close communication with them. The initiation of the project was considered to be successful; the pilot was presented to senior managers, who gave their approval, and the project was transitioned into the live environment.

As transition activities progressed, we realized that we had failed to identify an additional stakeholder, who became a primary disruption to the project. This junior database administrator (DBA) was the gatekeeper to crucial data sources required to generate reports. Any requirement submitted to the DBA was immediately rejected and dragged through bureaucracy that appeared to be aimed at putting off any changes to the database. The DBA quickly became a primary stakeholder and primary risk to the project. This issue was escalated to senior managers and was defused as the project went on.

19.2RISK MANAGEMENT

Managing a process as complex as SLM always comes with risks – the risk of changes failing, the risk of reports not being prepared on time, the risk of service level agreements (SLAs) being breached, and so on. Some studies quote that 90% of a project’s problems are decreased through the process of risk management.

First of all, let’s try to understand what risk is. ITIL defines risk as a possible event that could cause harm or loss, or affect the ability to achieve objectives. It is measured by the probability of a threat, the vulnerability of the asset to that threat, and the impact the risk would have if it occurred. Risk can also be defined as uncertainty of outcome – and can therefore be used when measuring the probability of positive outcomes as well as negative ones.

This means that there can be positive risks – negative risks are threats, while positive risks are opportunities. Examples of positive risks can be that service performance improves faster than expected, or that an SLA compliance report indicates that all service levels are complied with and there are no additional comments or complaints from the customer.

Risk management planning defines the methodologies, roles, responsibilities and risk categories involved. One of the most important outputs of the planning stage is the scope for which the service level manager takes responsibility. Consider the risk of incidents breaching their threshold for resolution time. Is it an SLM risk or is it an incident management risk? There is no correct answer. During risk management planning, each organization will determine the responsibilities for every process.

19.2.1Risk categories

Some risk registers for SLM focus only on report generation and its delivery, which is a common mistake. The selection of risk categories is important and should occur in the risk management planning phase, prior to identifying the actual risks.

The typical risk categories for SLM are:

• Customer Including all the risks that relate to service performance and SLA breaches
• Technology Excluding reporting, since reporting has its own category
• Reporting Tool failure or calculation error
• Transition Comprising all SLM activities or tools that are in the course of being deployed
• Service provider
• Supplier
• Cultural risks
• Resource allocation risk
• Unforeseen Including all the risks that cannot otherwise be categorized.

Further information on risk management can be found in Management of Risk: Guidance for Practitioners (TSO, 2010).