Skip to main content

Posts

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