Skip to main content

Posts

Problem, Incident and Change Management Integration

“ Problem Management  seeks to minimize the adverse impact of incidents and problems on the business that are caused by underlying errors within the IT infrastructure and to proactively prevent the recurrence of incidents related to those errors.   In order to achieve this,  Problem Management  seeks to get to the root cause of incidents, document and communicate known errors and to initiate actions to improve or correct the situation”.    Given that statement is directly from the ITIL Best Management Practices text, it’s a wonder more organizations don’t have well integrated Problem, Incident and Change processes in their organizations. I never want to say that there is a single silver bullet solution for a given problem and I’m not suggesting that here.  However having a solid CMS (Configuration Management System) is a good step in the right direction.   Of course before we even think of tools we must have rules.  Thinking holistically we can create an integrated set of best p

Problem Management for Newbies (Part 2 of 2)

Problem Management for Newbies (Part 2 of 2) In part one of “Problem Management for Newbies” we looked at reactive Problem management and how Problem Management can serve as a pillar of support to incident management.  Problem Management prevents, minimizes and eliminates future incidents and problems from occurring.  There will always be a need for reactive problem management.  IT support can never guarantee that there will not be outages and will always need clearly defined roles, skilled staff and governance for the resolution of incidents and problems when they occur.  Added value to the business is via proactive problem management!  Proactive Problem Management Proactive problem management will glean management information from the function of the service desk, and others across the organization.  By viewing and analyzing reports on frequency of incidents, types of incidents,  noting the times that incidents and problems occur and most importantly understanding the bu

Problem Management for Newbies! Part 1 of 2

Getting Started with Problem Management To understand the process of Problem Management one must first understand that a problem is distinctively different than an Incident.   It is tracked and recorded separately, it requires a very different skill set and has a different objective than those that are required for “Incident Management”.   Problem records are unique entities and are reported upon separately.   A repeatable lean problem management process could very well be the glue that helps IT Service providers integrate and automate much of the work and effort required to “prevent” “Eliminate” and to “Minimize” the impact of incidents on your business and end user customers. While an incident is an unplanned interruption that creates an impact to one or more business services, the problem is actually the cause of one or more incidents.    Example:   “I can’t access the ERP system”, “The web portal will not come up!”    “I can’t log in” are all examples of incidents.    The c

Next Steps

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

Agile_ITSM – Ingredients for Success! Part 2

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

Agile_ITSM - Ingredients for Success! - Part 1 of 2

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

Roadmap

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

The Three Ways of DevOps

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.

The Difference between Change and Release Management

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

Which Service Management Framework is the Best?

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 Influencing the Service Desk

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.

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