Skip to main content

Posts

New Moon on the Rise

What is a new moon? It is the phase of the moon where the moon is rising but not yet visible from the earth. For us, a new moon is definitely rising. It may not be visible but it is definitely here with BYOD, virtualization, shadow IT and cloud computing.   And that moon is demanding that we examine our practices in order to improve Time to Value. You may have heard a lot about the cultural and collaborative movement called DevOps.  Some service providers are making the DevOps vision a reality by focusing on improving their cadence - the  rhythmic   flow of something as it moves forward, such as software development or complex projects.  Agile service management and DevOps strive to improve the cadence between three main players in the value stream: Cadence of the Business Business demand is dynamic and the rate of speed is increasing. The business needs a cadence that is able to meet their accelerated requirements.  Jayne Groll in a recent webinar from ITSM Academy desc

WTF? Why the Failure?

Through the implementation of best practices, one of ITSM's critical success factors is to enhance the business' perception of the IT organization.   By creating a service strategy which helps to define good design, encourage effective transition processes and deliver valuable services through efficient and effective operational management, we work hard at making this goal a reality. Unfortunately, IT is often perceived to be ineffective and inefficient.  Recently, the government’s inability to deliver a working website for the affordable care act was splashed all over   news with many of my non-IT friends and family asking, how could this happen?   How come IT people never get it right? I want to respond with “BUT WE DO” and list many of the successes that I have been part of during my career.    But I look at them sheepishly and respond with” I don’t really know”.   As I think about this, I begin to get angry and not just because I’m an American tax payer, but because a

Service Provider Interfaces

With the rise of service specialization, sourcing services from multiple service providers has become the normal way of doing business. This approach has allowed service providers to deliver higher quality services and enhanced support capabilities while more affectively utilizing a greater constrained set of resources.  In order for this cost savings and ability to spread risk to be realized an organization must be able to maintain a strong relationship with each service provider. In order to support the development of strong relationships in a multi-vendor environment, guidelines and reference points (technological, procedural and organizational) between the organization and the multitude of vendors being engaged must be established.  These validated reference points are known as service provider interfaces (SPI). A service provider interface is a formally defined reference point which identifies some interaction between a service provider and user, customer, process or on

DevOps and the Service Desk

DevOps is a cultural and professional movement that stresses communication, collaboration, and integration between software developers and IT operations professionals. DevOps responds to the demands of application and business unit stakeholders for an increased rate of production software releases. Driven by the adoption of agile development processes by IT development organizations, DevOps aims to help organizations rapidly produce quality software products and services. Although the “Ops” in DevOps is often viewed as the technical and application management professionals that deploy and manage applications and their associated infrastructure (e.g., application servers, web servers, and database servers), the service desk supports the goals of DevOps in a number of ways. A goal of DevOps is to produce more frequent software releases. This means the service desk must be prepared to handle a faster rate of change. One way to ensure the service desk is prepared is to engage the serv

Collaboration

As I sit and listen to some classical music, the idea of collaboration comes to mind. To make the music,  the symphony needs to work together, yet play as individual musicians. I cannot play your part, nor can you play mine. By playing each of our parts together as part of the bigger whole, we can create something bigger than either of us. We call this the “primacy of the whole”-the sum is greater than the individual parts. This is the basis of collaboration. Pulling together a group of people into a team and instructing them to use “teamwork” or to “work as a team” does not equate to collaboration. A recent presentation made sense of this. Wikipedia© would not have come together as we know it if all the contributors had been put in the same space and given the instruction to create the site. The online encyclopedia exists precisely because the contributors did not know each other and did not work together in forced cooperation. The contributors created the information because t

Business Value of Service Level Management

There have been many discussions on what is a Service Level Agreement (SLA) or what is an Operational Level Agreement (OLA).   And by the way how does that differ from an Underpinning Contract?   We can agonize over how to measure and what to measure and who, what, where, and how we should manage our internal and external reviews.   Capturing the appropriate knowledge and building in a system for iterative activities and improvement are always a challenge.   Each of these could provoke a lengthy discussion on their own merit.    In this segment I would like to address the thought of who cares!   In other words, what is the real business value for implementing Service Level Management (SLM)? Why do I care about SLM? At the root of it all, the true value of SLM is that it is a vital organ in the systemic approach to integrate the business with IT.    Using SLM to strengthen the relationships between the two provide an opportunity for gleaning benefit from your effort.   For many

Any real life examples of a Service Design Package?

I have been asked this question several times before and I actually blogged about it in 2011 ( http://www.itsmprofessor.net/2011/08/service-design-package-sdp.html ).   This is a tricky question because the SDP is merely a package of documentation that tells the “story” of a service, from concept to testing to deployment and beyond.   The documentation can take many forms, from documents, records, source code comments, electronic media Each organization and each service will have different criteria, looks and feels to their SDP.   Apprendix A of the Service Design publication provides insight into the type of information that should/could go into the SDP.  My best advice is to avoid reinventing the wheel – leverage documentation that already exists (e.g., requirements documents) and capture information at the point where it is being determined or distributed.   Leverage the concept of the SDP as a vehicle for gathering better and more complete documentation.   Decide on a repository

Learning Best Practice Can Be Fun But Should It Be?

How would you describe having fun? When asked, many will describe the outcomes from having fun as a time when they feel most alive! Educators from Kindergarten classrooms through college and career training courses will integrate blended learning techniques to increase the knowledge transfer and comprehension of concepts being taught. Some will say that is fine but making it “fun” is a waste of time; a luxury.   Perhaps.   Is it?   Why not just learn the facts?   Why should we attempt to have fun along the way? Left Brain; Right Brain Many in IT Service management such as engineers and IT staff have proven to be predominantly left brain driven.   Great!   This means they have natural ability to learn facts, have logical thoughts, see things sequentially and are very rational thinkers.   These will do well on exams. Right Brain dominant individuals are more intuitive, see things holistically, and are great at synthesizing information.   We can see then that both skill sets are

Defining Business Benefit

In a previous blog I wrote about the need for a high performance Service Desk with the value proposition being reduced re-work, less down time, better utilization of higher cost resources (knowledge management), increased stability and predictable levels of IT services.  In order to deliver this value, we must effectively communicate goals and business benefits in a language that the business finds relevant and meaningful.   Consequently, metrics and reporting should reflect business outcomes and business needs. IT Support Metrics Average speed of answer. First Call Resolution. Average Escalation Duration. Total # of incidents recorded by: Service, CI, Assignment team. IT Goal Less down time, lower abandon rate, quicker speed of answer. Less down time, lower abandon rate, greater use of knowledge bases. Less Down time, predefined escalation paths, greater cooperation between technical resources. Precise picture of which services and Cis, having the greatest impact on t

Do LESS with LESS! Really??

Since the start of the millennium we have all heard that we must do “More with Less”. I recently read an article where the idea of “Less for Less” was looked at from the perspective of if our resources are cut then we will have to cut programs, products, and services also.   Perhaps we should look at how to cut back on to whom and what we produce in order to stay within our means. Government sequestration may have triggered this way of thinking for some service providers. This is a catchy title but is this really the case?   Is there a different perspective on “Less for Less”? Think back a few years when a downturn in the economy negatively impacted the workforce.   Families got creative.   The new trend became staycation instead of vacation.    A staycation meant less travel arrangements for less time in planning, less time on the road or in airports and therefore less missed connections, less cost for the family resulting in less stress and less debt!   What about VALUE!   W

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): ·          Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” ·          Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services-that is people. Because the people element adds variability, the service is variable. This holds true especially for the v

Balance in Service Operation IV

Previously, I have delivered several articles on the challenges that IT organizations face in trying to balance opposing goals and objectives especially in light of the fact that in every organization, the one constant is change.   The focus of those pieces described the tension between the perspective that IT is a set of technology components (Internal IT view) and that IT is a set of services (External business view).    They also spoke to the fact that, no matter how well the functionality of an IT service meets stake holder’s needs, it will be of little value if the IT infrastructure is unstable causing instances of unavailability and inconsistency in performance levels .   Of course we (IT/Service provider) must be able to do all of this at the same time as providing services that deliver acceptable levels of quality while efficiently utilizing the organizations resources. So to reiterate, this struggle can be broken down into four general imbalances so that an IT organizatio

Process Centric Thinking

What do we mean when we say “process-centric” thinking? What we mean is that individuals, groups or teams and even an entire organization sees their work and activities being driven by or related to process first, rather than person, technology or information first. Remember that a process is a structured set of activities that take inputs and convert them to outputs that help to satisfy business, customer or user outcomes. When we look to accomplish work or produce a good or service we are going to do that in a structured way (a process). To paraphrase Dr. W. Edwards Deming, “…if you cannot describe your work or what you do as a process, you do not know what you do.” A “process-centric” approach should not imply that you should forget completely about people, technology or information. These are important factors in completing the production of goods and services. It is that these other factors make the process possible. In turn, a process relies on these elements to work most

ITSM and the Consummate Gardener

The Consummate Gardener   There are times in IT Service Management that seem to be like dry cold spells.   Times when the funding is dry, the resources are lean and to all but the consummate gardener might appear to be nonproductive in the way of moving forward.   The consummate gardener will find something to put on the schedule in the bitter cold of January, something like garden planning, tool maintenance, or alphabetizing the seed packets. Perhaps browsing seed catalogs and more to ensure they are prepared for the next season. Why?   They have a vision!   The crop, the wonderful fruit of their labor realized.   Back to the Basics Like the gardener there are areas of ITSM Best Practice that a service provider can continually be preparing for and improving.   When times are lean and dry as well as when they are not.   With all the terms, the technology, the latest and greatest buzz lets pause and step back; back to the basics.   For the gardener that is the seed , the

#SMFlashbook – Best Tip(s) for Building a Service Catalog

This blog is being posted today as part of a larger community effort to publish common topic blogs on the same day.   I encourage you to review the other blogs on this subject by searching the hashtag #SMFlashbook. I was simultaneously confused and disappointed by the recent itSMF/Forrester survey results that indicated a large number of organizations had not built a Service Catalog due to lack of funding.     I am also always confused when organizations move forward with their Service Management initiatives without first defining their services.   So I challenge you with a question:   How can you manage services if you do not have a clear understanding of the services that you provide?   Here are some very simple and virtually free tips for creating an initial and meaningful Service Catalog: Step away from your tool.     The first steps can be captured on paper, whiteboards or in documents.   The tool part will come later. Gather stakeholders and collectively define an

Changing ITSM Seasons

As we approach the fall and winter in the northern hemisphere, the change of seasons makes me think of the whole idea of renewal. This leads me to think about the place of renewal in ITSM—Continual Service Improvement. To make improvement work really well it must be a continuous activity. At a minimum, we should take some time to recognize that ITSM has seasons just like the physical world. Each year as we strive to deliver value to our customers, users and business partners we should think about those seasons. The seasons of the year offer up an opportunity to renew our efforts in ITSM and to bring new life out of the longer-term activities and efforts within our organizations. Just like the need to change a battery in a smoke detector once per year, the “battery” of your ITSM work might need replacement, recharging or renewal. What does renewal of an ITSM implementation or effort look like? Here is a short list of the activities and steps you might take to help your own “renewal”

Value of the Service Desk

Respond more quickly to urgent business needs and incidents while simultaneously providing stable, secure and predictable IT services, despite the fact that the systems on which the business operates are typically fragile and hostile to change.   Sound familiar?   Improving operational reliability and communications between ITSM functions and processes begins at the Service desk. I have to quote a coworker of mine at this point “All things flow through incident management”.   The service desk is the eyes and the ears of the IT organization.   If you think about it and utilize the service desk from both an operational and tactical perspective , ensuring that all of the other ITSM processes and functions are feeding accurate and up to date information and data that the service desk needs, they can become the glue that that binds the entire organization together in alignment with both IT and strategic business   goals.   A single great process alone cannot deliver as much value to th

Rule of Law

Too often I encounter learners who struggle with the concept of governance. This idea does not need to be difficult to understand nor to implement. The idea of governance is based on an older idea known as "rule of law". This idea arose in the Enlightenment and has driven modern civilized society ever since. The understanding of the rule of law is that everyone (people and businesses) is subject to rules and regulations that keep mankind from descending into chaos and anarchy. Governance is simply the modern terminology for this concept. Other terms we use in this same sense are "management" and "control". Governance at its heart has two basic forms. The first is Governance ("Big G"). This is the type of governance whereby established ruling entities (governments and/or lawmakers and/or courts) create rules, regulations and policies (statements of intention or expectation) to keep us all from going crazy and destroying each other. We exper