Skip to main content

Posts

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