To understand the concept of “Release Models” one must first understand the clear distinction between the Change Management process and the process of Release and Deployment Management.   At a high level you could say that the Change Management process activities assess, authorizes and control the change and that Release and Deployment Process will actually execute or implement the change. This helps to understand the difference between change and release but also to understand that there will be different skillsets and activities involved for each area.    Although Change and Release management processes in and of themselves do have clearly defined objectives, roles and responsibilities these processes do not stand alone and must consistently work together for seamless integration with all of the Service Transition processes including Service Asset and Configuration Management and Validate and Testing processes.   This is especially true when you set out to define “Release Models”

If a problem is the unknown cause of one or more incidents then how can I design a repeatable model for something that is unknown? The purpose of Problem Management is to manage the problems throughout their lifecycle. Problem Management seeks to not only to minimize the adverse effect of incidents by providing work arounds, but also seeks to eliminate outages, and prevent them from recurring again. In Incident Management ITIL defines an Incident Model as a predefined set of procedures based on type of incident.   So then what is a “Problem Model”?   Problem Models Not all problems are the same.   There are many different types of problems and each type will require unique roles and responsibilities, varied skill sets and different timelines and policies based on the complexity of the problem.   When considering how to design problem models consider the workflow required once the “problem” or is identified. Approach to Defining Problem Models One approach is to classify

An “incident” is defined as an unplanned interruption to an IT service, the reduction in the quality of an IT service or the failure of a CI that has not yet impacted an IT service.  The purpose of incident management is to restore a service to normal operations as quickly as possible by minimizing the impact of incidents on IT services.  Incident Management is the process responsible for managing the lifecycle of all incidents by ensuring, that standardized methods and procedures are utilized to record, respond and report on all incidents.  Additionally this process should increase the visibility and communication of incidents to the business and the IT support staff and thereby allowing greater alignment of incident management to the overall IT and business strategies.  In a normal IT environment the IT organization may be dealing with a large number of incidents and many of these are repeatable, something that has happened before and very well may happen again in the future.  I

In ITSM as in life change is inevitable.   In order for us to continually deliver services that are meaningful and bring value to our customers, we must frequently update and upgrade not only the services we deliver but also the underlying infrastructure, technology and applications that are utilized and managed to deliver these services.   The ITIL definition of a change is “the addition, modification or removal of anything that could have an effect on the delivery of an IT service. The purpose of the change management process is to control the lifecycle of all changes, allowing us to make beneficial changes with minimal disruption to our current IT services.   The objective is to be able to respond to these changing requirements while safeguarding value and reducing rework.    Additionally ITSM must ensure that services continue to align to overall business strategy and that we have the processes and mechanisms in place to guarantee that all changes and the configuration items (C

  An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service and is strictly a reactive process. A problem on the other hand represents a different perspective of an incident by diagnosing its underlying root cause, which might also be the cause of multiple other incidents. Incidents however do not always grow up to become problems.  While Incident Management activities focus on restoring services to normal operations as quickly as possible, Problem Management activities determine the root cause, find the most effective and efficient permanent resolution and ultimately prevent the incident from happening again.    Problem Management can be both reactive and proactive. Proactive Problem Management identifies weaknesses in the environment before actual incidents occur.  These can then be exploited as improvement opportunities.   Reactive Problem Management addresses problems that were identified from one or more incidents.      The pol

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

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

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