By ITIL® from Experience©
When a request for Service Level Agreements (SLA) was not previously discussed during planning meetings or as part of a quarterly/annual objective, it is often in response to a specific need to address a certain pain point. For example:
- A difficult Customer meeting took place and expectations will be clarified in an SLA.
- An agreement, like a Memorandum of Understanding (MOU), is expiring and it is seen as an opportunity to replace it with an SLA.
- The CIO is frustrated with the inability of the IT organization to meet commitment to Clients. Thus, SLAs will be used to measure the organization’s performance.
As for any requirement, regardless of the trigger or driver, it is important to clarify expectations to successfully meet them. If the target is unclear, it is surely going to be missed. The following questions can be used to start a dialogue to clarify and set expectations.
- What triggered or which event caused the unplanned need for an SLA?
- What changed to make this important?
- Why is this a requirement now?
- What are we trying to achieve with SLAs?
- What is the objective, the end goal of having SLAs?
- Can you describe what SLAs would look like and how they would work once implemented?
- How many SLAs will be needed?
- Is the SLA a Customer based or a Service Based SLA?
- How do you see this project unfolding?
- Who are the key players to involve in this work?
- Which organizational unit will own the SLAs and who will be the process owner once the project is complete?
- When is this expected by?
Even though one can guess the answers, it is important to ask these questions to confirm your assumptions. Be careful not to interpret the request to prepare SLAs as a requirement to implement a full Service Level Management Process! An SLA is only one element of the entire Service Level Management (SLM) process. Implementing the Service Level Management Process may require: the role and/or a position(s) of the role of Customer Service Representatives, defined customer engagement procedures, establishing a service pipeline...in other words Service Design. Perhaps the issue and pain point originates in Service Operation! Perhaps a simple SLA document is needed instead of a process with governance, ownership, procedures, monitoring, people and tools to operationalize and integrate SLA and performance measures into the day-to-day culture.
For these reasons, the CIO’s understanding of an SLA must be established. Simply asking “What do you mean by an SLA” can be very revealing and totally change your understanding of: 1) the problem, 2) the requirement and, 3) the appropriate solution. Perhaps an agreed procedure explaining how the business is to engage IT is all that is required. In this case an engagement protocol would suffice.
While clarifying the CIO’s requirement for SLAs ensure that your response and commitment is appropriate to the level of maturity and capabilities of the organization. Otherwise its mission impossible! Therefore, focus on delivering to the specific requirement and to address the pain point. Many, like consultants, will see the opportunity to over deliver by implementing an SLM Program. Be careful not to expand the scope beyond the capabilities of the organization to absorb and embrace a new way of doing business. Offer to prepare a draft project outline to clarify your understanding of what is actually required. This will ensure that everyone is on the same page and understands the scope and what needs to be delivered.
- We need SLAs. Should we start with Service Level Requirements
- Do we need an SLA for VIPs
- How to ensure that incidents and service requests are closed quickly when there is no SLA
Copyright 2012 - ITIL® from Experience - D.Matte<HR>