In an earlier blog I had talked about the need for organizations to have the ability to measure their processes against those of their competition or some defined industry standard.  Before that could happen, it had to be determined if your processes are mature enough to ensure that you can gather the needed data for a successful undertaking.   If your assessment calls for developing a new process, reengineering or improving an existing process a sound methodology for that mission could be the “Ten process design and improvement steps” as describe in “The ITSM Process Design Guide by Donna Knapp. The elegance of this approach is that it can be utilized to design or improve any process regardless of maturity level.   It provides the common vocabulary, tools, and techniques needed to engage all participants who would be required for these process and improvement actions.   They help to define and understand the end to end process, who the customers are and their requirements.   It a

In part one of this topic we discussed the “dynamic” needs of business and also discussed how we the service provider must be “agile” to meet those dynamic needs.  Understanding of course that none of that can be done without the support of “processes and technology” and the best practices that enable them.  In part two of “Agile_ITSM – Ingredients for Success” I would like to discuss the most important ingredient for the success of all service providers: people.   People People with their skills, their diversity, their productivity and innovation are at the heart of agility and speed to deliver quality in a world where business needs and demand are dynamic. Empowerment! Trust the intentions of your people.  We have to be careful not to hobble the productivity with micro management of staff members and their effort.  When considering trust, it is not just a matter of whether a single member of the team or workgroup is trustworthy but do you trust that the team will

Dynamic We the service provider must meet the “dynamic needs of the business”! Someone recently asked me “What does that mean exactly?”   If that is what we are all chasing after and that is what we as service providers must understand and meet, then what is it?! The business demand for speed and productivity is not decreasing in any way.  The dictionary definition of “dynamic” is: Always active or changing Having or showing a lot of energy of or relating to energy, motion, or physical force This would mean that the needs of the business are constantly changing.   We can attest to that in our own experience.   So the question really becomes  "  How do we quickly adapt to that need?" Agile Being agile would mean that we are flexible so that we can adapt to change. We have to start looking at the provisioning of a service as a consumption cycle. Products are produced but a service is consumed.   Once consumed the demand for that service will incre

Most executives understand that a business’ performance is only significant when it is benchmarked against its competitors.   As an accepted business best practice it is expected that the functioning of an individual organization will be measured against other like type organizations. This practice of benchmarking oneself against competitors should be no different for any IT organization.   There can be no better instrument to utilize then benchmarking to insure whether the IT operation is providing a competitive product.   Without this peer to peer comparison it would be difficult at best to define if IT’s performance is weak, competitive or an industry leader. Of course in order to benchmark you must first determine are my processes mature enough to ensure that I can gather the significant data needed for this undertaking.  If not then your resources would be better utilized in first assessing your processes maturity through tools such as the ITIL Process Maturity Framework (PMF

I recently published a blog that explained the Theory of Constraints.  In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. The First Way  Workflow!  The first way is all about workflow or the flow of work from left to right. Generally referring to that flow of work between the business and the customer.  Work that is flowing from development to test and then test to operation teams is really only work in process.  Work in process really does not equate to anything until value is realized on the other side.  We must identify and remove or free up our constraints. For example, reducing the cycle from time of code commit to the time we are in production will reduce the release cadence. Ensuring the workflow from left to right can radically increase workflow throughout the delivery cycle.  Define work and make it visible.

There is often confusion between the goals, authorities and roles of Change and Release Management.  In fact, the objectives of each of process are very, very different. Change rules! Change Management is an authoritative process that governs anything that potentially impacts a new or existing service.  It is both the enabler of innovation and protector of stability.   It is first and foremost a risk management process.   It is also a planning process.   If Change Management is a governance process, Release Management is an action process.  Under the authority of Change, Release builds, tests and releases new or updated services into the production environment.  Every release is comprised of a single change or package of changes.  Release Management is more technical than Change. If done well, both processes will avoid unnecessary levels of bureaucracy and will build a collection of change and release models that pre-define and pre-approve the rigor required based on levels

Do you assume that all IT service management programs must adhere to the IT Infrastructure Library (ITIL)?    In truth, there are several other frameworks available and efforts underway.     Most are variations of or are rooted in ITIL but may apply to a specific environment or context.   Some are very comprehensive, while others advocate a “lighter” approach.    A service lifecycle is an ongoing theme.    None are meant to be highly prescriptive. Which is right for you?   Of course the answer is “it depends” on your goals, resources and business models.   To meet the needs of organizations that were overwhelmed by the enormity of the 2000+ pages of the IT Infrastructure Library, renowned ITSM expert Malcolm Fry published “ITIL Lite”.   This approach  makes service management more realistic for organizations with fewer resources by focusing on the essentials.        ITIL Lite is an official ITIL publication.   ( http://www.theitillitebook.com ). For years, Microsoft has  also

Trends such as mobile computing, consumerization (also known as bring your own device (BYOD), and cloud computing are having a dramatic impact on the service desk and present great opportunities for discussion within your organization. Considerations for the Service Desk and other IT support teams:  How does service catalog management support these trends? What about SACM and change management? What improvements might need to be made to incident and problem management and request fulfillment? What role does the service desk play in all of these processes? How does the service desk interface with business relationship management and service level management relative to these trends? The future is now.

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

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

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

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

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

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