Skip to main content

Posts

Managing Conflict

The workplace can be a stressful environment. Personality differences, team dynamics, budget constraints, technology issues, achieving business alignment and customer satisfaction are all contributing factors to this stress. Conflict inevitably arises. I recently attended an ITSM Leadership workshop and realized that conflict is not negative nor something that we should avoid. As IT Service Management leaders we must understand that our stakeholders often have a different set of concerns and issues. There will be varied opinions on the right way to implement service management. In our goal of effective leadership it is important to solicit and listen to differing opinions. We have to embrace our differences, work through the issues and implement strategies to limit the negative aspects of conflict. Conflict can actually be valuable to an organization. It is in the effective management of this conflict that our teams can be made stronger, our relationships with our customers improved an

Enterprise Monitoring and the Service Lifecycle

I was recently asked where an entity such as Enterprise Monitoring resides in an organization. Should it be equivalent to the Operations, Engineering and Security areas rather than reporting to one those areas? Yes in some ways it does make sense to have Enterprise Monitoring at the same level. However, we must remember that there is a clear distinction and separation between the functions as proposed in ITIL and the activities that they perform. “Monitoring” is an activity related to a process (including but not limited to Event Management, Availability, Capacity, Service Level, etc.) So this work gets performed across an enterprise and not by a single, particular group. Anyone who needs to “monitor” something should use the associated processes to do so. Someone doing “monitoring” does not need to be located in any specific part of an organization. Functions are organization, location and structure agnostic. A function is not a place or management structure rather an abstract groupin

Evolution of the Balanced Scorecard

The balanced scorecard (BSC) has evolved from simple metrics and performance reporting into a strategic planning and management system. It is no longer a passive reporting document which shows pretty pictures. It has transformed into a framework that not only provides performance measurements but helps analysts identify gaps and continual service improvement programs. It enables our senior staff to truly execute their strategic goals and objectives. Dr. R. Kaplan & David Norton did extensive research and documentation on this framework in the early 1990’s. In Kaplan & Norton’s writing, the four steps required to design a BSC are as follows: Translating the vision into operational goals; Communicating the vision and link it to individual performance; Business planning; index setting Feedback and learning, and adjusting the strategy accordingly. In the late 1990’s an updated version on the traditional balanced scorecard was introduced called the Third Generation Balanced S

Narrowing Tool Selection Criteria Based on Stakeholder Requirements

One of our followers recently asked about how to handle the CIO's concern about security in a cloud environment when evaluating tool solutions.  To my mind, the CIO is expressing a potential requirement that should be considered and that may narrow your selection criterion. Your selection criteria should assist in achieving two outcomes. One is to narrow down the list of providers and their products to a workable number so that you are not spending undue amounts of time evaluating too many vendors. The other is to ensure that the products you have selected to evaluate really do meet 80% of your stated requirements out of the box. You will need to develop three criteria sets. The first list is a set of criteria of what you would like the tool to do in terms of supporting your documented and defined processes (call these functional requirements). Functional requirements are those things that help you to achieve utility of your processes and services. You will also need a set of c

Metrics that Matter to Customers

I was recently asked to elaborate on a previous blog that discussed reducing metrics and reporting on those that matter to customers. In terms of any metrics, especially those that are important to customers, you should always think about or add the phrase “with quality”. Remember that the term “quality” is defined as “conformance to customer requirements”. So all metrics and measurements should ensure the work or actions you perform remains focused on the customer and their needs. Also in terms of how you phrase a metric it can often be more beneficial to measure in terms of increases and decreases rather than specific quantities. Given that, here some metrics that you might think about using: Increased Customer Quality Satisfaction %--perhaps the most important of all metrics Increase First Line Call Resolution [with quality] %--helps reduce costs but also builds perception of preparedness and knowledge in the eyes of the customer Decreased Mean Time to Restore Serv

Culture Shift

When one thinks about how things work in the world, the word paradigm might come to mind. Paradigm (n.)-- A system of assumptions, concepts, values, and practices that constitutes a way of viewing reality. As the definition shows, a paradigm represents “how things are” in our current world. Another way I like to think about the idea of a paradigm is to use the term “culture.” Culture (n.)— The known environment in which a person, thing or idea exists. If you know a foreign language or how to play an instrument it is part of your own personal culture, or paradigm. If you do not speak a foreign language or cannot create music, those capabilities are not part of your culture or paradigm. And just as an individual has a culture or personal paradigm, so can an organization. Often it is this culture or paradigm that wreaks havoc with our ability to understand and implement IT Service Management. So how do we understand and use the knowledge of our cultures or paradigm to our advantage when

Keeping the Momentum Going

The Continual Service Improvement publication describes the Continual Service Improvement model. One of the questions asked in this model is “How do we keep the momentum going?” This question becomes especially important when your ITSM implementation efforts have been in place for a significant amount of time. The question then becomes more one of “How do we stop from losing the momentum and effort invested up to this point?” Or perhaps “How do we avoid from returning to the old ways?” For all our efforts to become efficient, effective and economical there is a potential danger that we will fall into comfortable, yet poor habits. So how do we ensure that we do not fall into bad habits such as taking shortcuts, pushing aside process, and just “getting things done” instead of following established methods and processes and doing proper planning? We must begin by being confident in the strides we have made to this point. If we have followed the Continuous Improvement Model faithfully