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

Process Maturity Framework (PMF) - Part 3

The professor was recently asked:  "I am having difficulty communicating the business risk of having processes like Change Management and Incident Management sit at Initial (Level 1) maturity. Can you address some of the common business risks and costs companies see by having immature processes?" Great question!  Many organizations do not recognize the inherent risks inhaving immature critical processes such as Incident Management and Change Management. Both processes strive to increase service availability either by identifying and mitigating risk before a change is made or minimizing the impact of a failure after a service is deployed.  To refresh our memories, I have included a description of each aspect of Level 1 in the Process Maturity Framework, with its associated risks:   Vision and Steering: Minimal funds and resources with little activity. Results temporary, not retained. Sporadic reports and reviews. No formal objectives and targets. Wasted activi

MOF and Standard Changes

Organizations looking for help defining standard changes will find it in the Microsoft Operations Framework (MOF). A white paper Using Standard Changes to Improve Provisioning describes what standard changes are in relation to other changes as well as in relation to service requests; along with guidelines for establishing standard changes. The MOF Action Plan: Standard Changes offers a more succinct step-by-step look at how to create standard changes. There are a also a number of “MOF Reliability Workbooks” in the MOF Technical Library (e.g., Reliability Workbook for Active Directory® Certificate Services) that describe proposed standard changes for the given system or service presented in a checklist-like fashion that allows the proposed change to be verified as a standard change. The MOF Reliability Workbooks are Microsoft Excel spreadsheets that also look at things such as Monitoring Activities, Maintenance activities, and Health Risks. This and other tools such as an in

Process Maturity Framework (PMF) - Part 2

In one of my previous blogs I wrote about the ‘Process Maturity Framework”. (Appendix H pg 263 from the V3 ITIL Service Design Book). I mentioned that you can utilize this framework to measure your Service Management processes individually or your Service Management program as a whole.  With this discussion I would like to speak to the five areas that the assessment should be completed against at each level. The five areas are: Vision and Steering Process People Technology Culture  Initial (Level 1) Vision and Steering:   Minimal funds and resources with little activity. Results temporary, not retained. Sporadic reports and reviews. Process : Loosely defined processes and procedures, used reactively when problems occur. Totally reactive processes. Irregular, unplanned activities. People: Loosely defined roles or responsibilities. Technology: Manual processes or a few specific, discrete tools (pockets/islands). Culture: Tools and technology based and driven with strong a

Process Maturity Framework (PMF) - Part 1

I am often asked about the best way to measure process maturity.  While there are several process maturity models available, I prefer the “Process Maturity Framework” (Appendix H pg 263) from the V3 ITIL Service Design Book. You can utilize this framework to measure your Service Management processes individually or Service Management as a whole. The five areas that the assessment should focus on are: Vision and Steering Process People Technology Culture The major characteristics of the Process Maturity Framework (PMF) are the following:    Initial (Level 1) The process has been recognized but there is little or no process management activity and it is allocated no importance, resources or focus within the organization. This level can also be described as ‘ad hoc’ or occasionally even ‘chaotic’. Repeatable (Level 2) The process has been recognized and is allocated little importance, resource or focus within the operation. Generally activities related to the process are unco

What does it mean to "adopt and adapt"?

What does it mean to “adopt and adapt” an ITSM framework like ITIL? This question has come up recently in several of my classes. It is not an easy question to answer but one that needs to be addressed early on in any ITSM implementation effort.   The first consideration is the adoption of a framework or perhaps even more than one. Yes, with an ITSM implementation we are not limited to taking on the advice and best practices of only one approach. When we “adopt” a framework, we make a commitment to use the methods, means and approaches laid out within a given framework. This commitment includes being willing to go as far as redesigning how and why we undertake activities and efforts within our organizations. If we want to “adopt” and ITSM framework, but we do not change the fundamental way we approach things, then we have not really adopted an ITSM framework. Adoption requires a fundamental willingness to see things from a new perspective. If you want to redesign your living space you

Proactive Availability Management Techniques - CFIA

Component Failure Impact Analysis (CFIA) is a proactive availability management technique which was developed by IBM in the 1970’s. This technique allows us to predict the impact on our services if any of the individual components fail. It points out our vulnerabilities to single points of failure. Doing a CFIA is a pretty simple exercise. Here are the steps: Take certain key Configuration Items (CI)s in the infrastructure and identify the services that they support by researching the Configuration Management System (CMS).  If you do not have a CMS, look for paper diagrams, network configurations, any available documentation and general knowledge. Create a paper or electronic table or spreadsheet.  List the CIs in the first column, and the Services in the top row.  For every CI, place an “X” in the column below the service if that CI's failure would cause an outage.   Mark an “A” when the CI has an immediate backup (hot start) or a “B” when the CI needs a warm start. The basic

eTOM and ITIL

Throughout the ITIL classes that I teach many students have asked about other frame works and how they differ from and work in conjunction with   the ITIL framework.   The framework that I will be comparing with ITIL today is eTOM (Enhanced Telecom Operations Map)   The Enhanced Telecom Operations Map is a business process model framework intended to define a common language and a complete activity mapping and classification for use by service providers within the telecommunications industry.   eTOM provides the enterprise processes required to properly run the business of a telecom service provider and break them down to different levels of detail. eTOM is intended to be more formal when compared to IT Infrastructure Library (ITIL) since it specifies a process framework composed by processes typically necessary for service providers to plan, deploy and operate their services. The eTOM Business Process Framework has been widely accepted by the telecommunication industry as a stand

Adding Value - GIVE EM THE PICKLE

Recently I was having a discussion with a colleague. The discussion centered on value, what it means and how we deliver it to customers and users of IT Services. One particular part of the discussion focused on how you can easily add value in small increments that combine to bring satisfaction to customers. My colleague mentioned an interesting idea from a restaurateur named Bob Farrell, the founder of a chain of Ice Cream Parlors. He sold the chain and became a motivational speaker based on what he learned from the restaurant industry and how to drive better value and customer satisfaction. Bob had once received a letter from a customer indicating loss of satisfaction when the server was going to charge him for a single pickle slice to go with his burger. From this letter Bob Farrell derived the importance of the small things we should do for customers and users of our goods and services to ensure satisfaction.  Providing value to customers does not have to arrive in large portio

MOF Management Reviews

Let’s continue our discussion on IT Service Management Frameworks. Recently, we talked about the question based guidance in the MOF Solution Accelerators. Now, I would like to offer you additional information on the MOF Management Reviews. MOF Management Reviews will help organizations ensure that their technology services are on track to deliver expected business value. They offer guidance to help management set goals, evaluate progress and confirm results. The MOF Layer/Phase and the aligned Management Review is listed as such: Manage Layer Policy and Control MR) Plan Phase Service Alignment MR Portfolio MR Deliver Phase Project Plan Approved MR Release Readiness MR Operate Phase Operational Health MR The Management Reviews can be used as checklists to ensure we have completed tasks correctly. For example, the Release Readiness document offers a comprehensive review of the deliverables produced. It delivers an assessment of the readiness of the business to employ the solut

Service Level Management Relationships

One of the most important goals of Service Level Management (SLM) is the need to build strong relationships between the customers and users of IT Services. It is incumbent on the roles of the Service Level Manager and Business Relationship Manager (a role defined with Demand Management) to serve as the Voice of the Customer. SLM must act as an agent on behalf of business customers, since those individuals or groups must focus on executing business processes or serving further the end-users of a company’s goods and services. The business should not have to spend its time worrying about the value they need from IT Services. SLM needs to create a strong bond with the business and end-user customers. This bond needs to be a familiar and personal link that shows the customer that IT truly cares about the needs and success of the business. Good Service Level Management cannot be conducted solely through emails or phone calls. A good Service Level Manager knows they must meet their customer

Accountable and Responsible

I was recently asked about the accountabilities and responsibilities of the Service Level Manager and Service Owner.  Let’s start with Service Level Manager . Responsible for gathering Service Level Requirements from the customer. Responsible for negotiating and maintaining SLAs with the customer. Responsible for developing and maintaining OLAs. Responsible for understanding underpinning contracts as they relate to OLAs and SLAs. Responsible for producing, reviewing and evaluating reports on service performance and achievements on a regular basis. Also for conducting meeting with the customer to discuss service performance and improvements. Responsible for initiating appropriate actions to improve service levels (SIP). Conducting yearly reviews of SLAs, OLAs and underpinning contracts. The success of SLM is very dependent on the quality of the Service Portfolio and the Service Catalogue and their contents. They provide the necessary information on the services to be managed w

Component Failure Impact Analysis

Availability Management balances business availability requirements against the associated costs. So, should we consider availability requirements before the service has been designed and implemented or after?  The Availability Management process should begin in the Service Strategy stage of the lifecycle and continue in each stage of the service lifecycle. Availability Management ensures that the design approach takes two distinctive but related perspectives. Designing for availability focuses on all aspects of the technical design of the IT service. Designing for recovery ensures that in the event of a service failure, the business can resume normal operations at normal as quickly as possible. One of the techniques that can be invaluable to both perspectives is the Component Failure Impact Analysis (CFIA). The CFIA can be used to predict and evaluate the impact a component failure can have on its related IT service. This activity identifies areas of weakness or fragility within

MOF's Question Based Guidance

During a discussion in a recent Intro to MOF class, we talked about some of the best practice guidance from MOF that we would use in our ITSM improvement initiatives.  We had an enthusiastic “YES” that the MOF question based guidance will be a most welcome addition in our toolkit.  Let’s talk a little bit about MOF and what this guidance entails. MOF is a Microsoft Solution Accelerator that helps integrate IT best practices, governance and risk, compliance, and team accountabilities for managing key functions across the IT service life cycle. In the documents, MOF provides scripted questions to help organizations drive service improvements by process or stage or activity. For example, the MOF Reliability Accelerator offers direction on understanding, setting targets and measuring IT service reliability. It addresses creating plans for the following areas:  Confidentiality Integrity Availability Continuity Capacity Here is an example of the question based guidance from MOF 4.0 w