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

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

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 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

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

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

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