How to overcome internal SLA misconceptions

Why is it that when I mention the idea of internal service-level agreements (SLAs), people start shaking their heads “no” so rapidly it seems like they have a major neck problem? Usually, people readily agree to the concept of SLAs between two organizations in order to hold one other accountable. But, why is there so much hesitation around the internal implementation of SLAs?

SLAs can be implemented within a department, between departments, or in other formations. But, network engineers, administrators, and other IT staff members, get defensive when broached with the topic of a formal, internal SLA. They are quick to say that they are already capturing metrics and KPIs, reporting to their managers, and that everything is FINE, as is. Sound familiar? Why is that?

Part of the problem exists in the misconceptions that both executives and their staff have about performance metrics. IT and other departments (sales, HR, finance, etc) that are charged with collecting and reporting metrics to management almost always feel that these sets of data are somehow a measure of their own performance. I am sure that metrics being reported to successive levels of management are perceived by each lower level as performance indicators. On the other hand, when listening to CIOs, they admit to receiving a ton of great and wonderful reports/data from their staff, but they admit that often times they do not know how to interpret the data and are sometimes overwhelmed with the amount of data they receive each day. Which metrics and data will help them confidently make sound business decisions? Further, how can staff be assured that the reports they provide are not a knock to their own capabilities?

Why SLAs are important

Traditionally, SLAs are used as a method of measuring and potentially penalizing performance according to predetermined, mutually agreed upon standards. Typically, SLAs are between internal and external parties, but they are commonly used between departments of an organization. When done correctly, the process of drawing up a formal SLA brings attention to potential issues, identifies objective lessons learned, sets expectations, and increases the likelihood of continual improvements.

CIOs and their teams are often thought of as consultants, providing services to their internal “clients.” Just like between external partners, SLAs can also help IT understand what is and is not of most importance to their inter-organizational client. Financial penalty clauses are the “stick” within traditional SLAs to ensure that the provider delivers a certain level of service. But, this new form of SLA should first and foremost be viewed as the “carrot,” as a tool to encourage communication and to be used as a consistent framework for meaningful dialogues between parties.

A formal SLA creates a truly professional business relationship between “provider” and “client” and serves as a model for other departments within an organization.

SLAs: ­ Set yourself up for success

• Get the right people on board: Identify and select the appropriate individuals and bring all parties involved to the table so that the business, technical, and legal perspectives are considered. Involve the administration department as well. Include the day ­to ­day supervisory management staff who will have to meet the performance standards based on the SLA requirements. Their involvement will go a long way towards improving the overall SLA quality and also addressing the misconception that the staff may have that their individual performance is being evaluated.
• Rally around the cause: It is best when the strategic objective of the organization is expressed with the team so that everyone understands the goals and mission involved.
• Don’t completely reinvent the wheel: If there are any current metrics and KPIs being used, bring those to the table. Note that IT service metrics will be different than those of HR, finance or marketing. In addition, consider metrics based on what others in your industry are doing in a similar environment with similar objectives. The key is to avoid an overload of metrics to be captured, but discover the optimal amount to fulfill your business objectives.
• Begin with the end in mind: Beginning with the end in mind involves imagination — the ability to envision your future. What is the mission of the organization and what are the goals and objectives for the business and the steps needed to accomplish them? Are the internal SLAs driving the collection of data and analysis to enable better informed business decisions with confidence? What business decisions will be made from the data collected under the terms of the SLA? If the CIO is planning to consolidate, for example, it’s important to make sure that the correct information will be captured. Executives need to feel confident that they will be able to meet data governance needs and requirements as a result of the information they receive.
• Be specific: SLAs should have a set duration and be re­evaluated during an established renewal period or when preparing a new budget. These agreements should change as the demands and requirements change (new policies, new processes, new mandates and regulations that need to be met, etc.).
• Don’t make a mountain out of a molehill: An important note to take into account when gathering SLA requirements is not to create an issue out of a non-­issue. If scheduled downtime is not important, then do not include it as part of the SLA. Address those areas where there are identified discrepancies and a need for process improvement.

SLAs: Time well spent

By taking the time to properly set up SLAs, any misconceptions and hesitation experienced by the various stakeholders will be addressed. SLAs provide executives and staff, and IT and their internal clients with the structure, confidence, and reassurances necessary for healthy working relationships to succeed. Formal SLAs bring all parties involved together and make a positive impact on the initiative as a whole. When done correctly, they boost morale and create value.