Why is your organization buying new IT service management (ITSM) tools? If they are trying to fill a gap in requirements or reduce the cost of ownership, the purchase may be a good decision. However, if the organization is struggling to deliver efficient and effective service, buying technology won't solve the underlying problem. It is an easy answer that will not have the intended payoff.
Prior to purchasing the new tools, a true understanding of the root cause of the service issue is required. If there is a process issue, the process will not be fixed just because new tools are introduced. Technology should support service delivery. The processes need to be reevaluated and corrected prior to a tool implementation. Otherwise, the organization will have the same issue after the new tool is introduced only now, it will be worse. Valuable time and money were spent to purchase a tool with little benefit. The IT staff will look at this purchase as a management failure rather than a win.
If the organization’s processes are strong but challenges still exist with delivery. The root cause may be related to individuals or teams that do not support the process or various initiatives. A review of metrics and/or conversations with team members should surface ‘people’ related issues. Challenges relating to ‘people’ are much tougher to address. Conversations must take place to fully vet the issues and determine the next steps. It could be as simple as a communication issue or as complex as a performance issue.
If you are making an ITSM tool purchase, take a step back to consider why this purchase is important. Is this purchase key to your success in delivering service and meeting expectations? Why? If the answer to these questions involves solving today’s service delivery problem, ensure your processes are reviewed and refined and ‘people’ related issues are addressed prior to the implementation.
Consultants are often asked to conduct maturity assessments. Our customers want a score relating to maturity so they can show progress and benchmark against other organizations. Unfortunately, the standard maturity assessment really offers little value to the organization. Almost every best practice relating to IT has a maturity assessment.
Most of the time, the assessments are customized to meet the needs of the client which virtually eliminates the ability to benchmark scores with other organizations. In addition, many maturity assessments merely measure process maturity. Is the process implemented and well documented? If so, credit is given in the assessment. Assessing at this level is of little value to the organization. It doesn't reflect performance nor does it provide any information about the customer experience.
Assessments should be valuable to the organization. It isn't about process maturity or a score. It is about how the IT organization is performing compared to the business's expectations and needs. What are the pain points affecting the customer? How are priorities identified and communicated? Does everyone in the organization understand how to navigate in order to get work done? How are IT investments identified and prioritized?
The questions noted are a small sampling of relevant questions which can yield interesting information about how an organization is performing. The assessment questions and technique will vary based on the organization’s goals and objectives. A valuable assessment provides information about the efficiency and effectiveness of the IT organization. It is not about maturity but performance.
The outcome of the assessment should be information about how IT is performing as well as a roadmap which clearly illustrates actions which will improve the efficiency and effectiveness of the IT organization.
Written By: Pamela Erskine
When writing a service level agreement (SLA), consider if your customer will find value in the document. Is your SLA too technical? Does it list all of the technology that the IT organization is providing rather than referring to services or critical applications?
Most SLA documents include the utility and warranty aspects relating to IT service. Clearly the IT organization is providing value yet the customer won’t agree if they cannot understand how the technology supports them in their day to day operations. Consider how the customer perceives value. They value outcomes. They form preferences and perceptions based on their own experience and knowledge. Outcomes, preferences, and perceptions equate to how the customer defines value.
If there is too much technical jargon in the SLA document, the customer value was lost. The customer is interested in availability, security, continuity, and capacity but the information needs to be framed by talking about the service. The warranty aspects allow the service to perform to the customer’s expectations.
For example, if the IT Service Provider is backing up data on a server. The customer definitely wants their data backed up. Do they care about the technology? Most likely, they don’t. They merely want to use the applications and data that are on the server. They want a level of assurance that if something goes wrong, they can quickly recover without losing any information. As an IT Service Provider, we need to understand the customer’s requirement for availability and continuity and build a solution that fits within their requirements and budget. In the SLA document, the IT Service Provider should set expectations on service availability as well as continuity but the information needs to be meaningful to the audience. Referencing the impact on customer business processes or business activities when data is unavailable will help the customer relate to how the backup is providing value.
Remember, the customer is determining if the technology is valuable based on how it supports them in their day to day operation. The IT organization needs to communicate the value they are providing in terms the business can clearly understand.