We are all customers of someone right?  What was your last customer experience like?  Was it so good that it completely changed how you thought about the product or the organization you were receiving services from? On the other hand was the service you received so poor that you vowed never to use their products or services ever again.  We have all been in those situations. You may not have realized it, but how that interaction was designed can have a huge impact on the perception you, the customer, walk away with.  I recently read a series of articles in the September issue of Harvard Business Review magazine.  The entire series was titled “The Evolution of Design Thinking” - It’s no longer just for products. It speaks to how executives are using this approach to devise strategy and manage change.  I can’t tell you what an absolute must read this is for all.  It will make you take a second look at how you design, deliver and support the services to y...

When an organization is planning on a major change that will incur significant cost, risk, time and engagement of resources along with organizational impact, it is best practice to initiate this activity through the Service Portfolio process.  Before this new or significantly changed service is chartered, it is important that it be reviewed for how it may impact the short, medium and long term support of other services currently being delivered, the pool of limited resources that will be utilized for this undertaking and on the change schedule itself. The Change Proposal is used to communicate a high level description of the change and is normally submitted to Change Management for authorization.  Authorization, however, is not an approval for implementation, but is a measure to allow the service to be chartered so design activity on the service can begin. In some cases the proposal may be created by someone other than Portfolio Management, such as the PMO or SMO. Thi...

All changes need to be assessed and evaluated.  Changes that are considered significant should be subject to a normal change evaluation in which we have well defined criteria for making this determination.  In this blog we will focus on the assessment side of the equation. A logical place to begin assessing the impact of changes on services and configuration assets would be the use of the "Seven Rs of Change Management".  Without these questions being answered a proper impact assessment could not be completed.  When leading an impact and resource assessment several items should be considered.  At the top of the chart we need to determine if there will be an impact to the customer's business operations.  Next we might want to know what the effect will be on infrastructure, individual customer services and their performance, reliability, security, continuity and ability to handle various levels of demand.  Additionally we will need to understand what t...

In today's dynamic business climate, service outages cause real bottom line impact to the business. There are documented best practice processes and known critical success factors and yet outages that throw support organizations into reactive firefighting turmoil are far too common. Mature processes with just enough control are needed to smoothly transition new and changed services into production, helping to ensure stability for IT and the business.  Most organizations will confirm that they do have Change and Release Management processes in place.  Service Providers will usually have some level of Service Asset and Configuration Management control.  There is generally a lot of buzz and focus on three core processes for Service Transition and the success and integration of these three are critical to business success.  Three Core Processes for Service Transition are: Change Management Service Asset and Configuration Management Release Management Most IT...

I highly recommend The Visible Ops Handbook by Gene Kim, Kevin Behr and George Spafford. There are a lot of intersections between Visible Ops (VisOps) and being Agile.  In fact, following Visible Ops practices allows you to achieve an Agile perspective in a shorter time scale.  There is an area in particular where I think alignment between VisOps and Agile is very strong. One of the four tenets of the Agile Manifesto is that we value “Responding to change”.  This is further underpinned by the principle “Welcome changing requirements, even late in development”.   Agile processes harness change for the customer’s competitive advantage.   This also ties us to the goal and objective of Agile Service Management in “Improving IT’s entire ability to meet customer requirements faster”. Responding to change does not equate to bypassing process or controls.  Every business decision triggers an IT event.  Industry statistics tell us that 8...

Anyone who has worked in Information Technology knows that today, there is and always will be improvement opportunities available to our organizations.  This is especially in light of the pace of change that is taking place in all market spaces and the level of customer expectations that accompanies that change. If you have worked in IT for a number of years, you may remember when change was not welcomed. Well the good old days weren’t always that good and tomorrow ain’t as bad as it seems (Billy Joel).  The challenge is in getting started. If……. ·        the processes that are currently being engaged are not as efficient and effective as you would like ·        you are finding that your environment isn’t as stable and reliable as it should be ·        that when you make changes to your environment it generally results in an outage and prolonged and repeatable firefighting ...

A reader recently asked me to comment on the difference between Change and Release Management. The first question “Is it a request or proposal?” is a good one.  When we use the term proposal, normally we are speaking about major changes that will involve significant risk, cost, or organizational impact.  Proposals are normally initiated by the portfolio management process.  They can also be submitted by a program or project management office.  Again remember that each organization is unique and how they do this and at what level it takes place can be different from organization to organization. This is defined at a high level, but the details necessary will depend on the organizational requirements.  For the most part, before the new or significantly changed service is chartered it is critical that the proposed change be reviewed for its potential impact on other services, shared resources, and the change schedule. These proposals are submitted to change ma...

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

This blog was written in 2010. For the most up-to-date guidance, please read Problem, Incident, and Change Enablement Integration published in 2025 “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 i...

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

Prioritizing Changes Originally Published in 2011 The Professor recently received the following question: Having put together a spreadsheet of information that I need to assess the impact of a change,  what I need to do next is figure out how to assess the impact of a change as being high, medium, or low? Any guidance you can give me on how to do this would be greatly appreciated.” The  Service Transition book provides great guidance on assessing the impact of changes (ST 4.2.6.4). This section provides 7 questions that must be answered to fully understand the impact. Many of these questions are answered using information in your spreadsheet. Others you may want to consider adding.  Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementati...

Early Life Support Originally Published on May 3, 2010 I have found, after doing a number of releases throughout my career, that a solid Early Life Support program (ELS) can really enhance the acceptance and support of any new or changed service. The ITIL Service Transition definition of ELS is the “Support provided for a new or changed IT service for a period of time after it is released." During ELS the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional resources for Incident and Problem Management.   Although stakeholders have agreed to the entry and exit criteria in the Service Design stage, it may become necessary to finalize the performance targets and exit criteria after the build and testing of the service has been completed. This will help to clarify the deployment process and set the proper expectation of the operational resources that will perform the support after ELS has been completed. ELS ensures that ap...

We continue our "Best of" blog services by moving into Service Transition Who is the Change Initiator? Originally Published on July 21, 2010 The “change initiator” is the individual or group that is requesting the change. Change initiators could be users, suppliers or IT staff – depending on the nature of the proposed change. It is the change initiator’s responsibility to justify the reasons for making the change.  However, since the change initiator may not understand all of the risks associated with a seemingly innocuous change, some type of impact assessment should occur.  The assessment could be very simple and quick - or extensive- based on the scope of the change and business processes that are potentially affected. The change authority (CAB, Steering Committee, local CABs, etc.) assesses the impact of the propose change and determines if the change is necessary or beneficial.  Impact could be negative or positive and should consider cost/benefit, re...

I often get asked where change evaluation takes place.   Isn’t it part of change management?   It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.   It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended affects, unintended affects and actual performance once the service change has been implemented.    The purpose of change evaluation is to provide a uniform and structured means of determinin...

Organizations looking for help defining standard changes will find it in the Microsoft Operations Framework (MOF). A white paper Using Standard Changes to Improve Provisioning describes what standard changes are in relation to other changes as well as in relation to service requests; along with guidelines for establishing standard changes. The MOF Action Plan: Standard Changes offers a more succinct step-by-step look at how to create standard changes. There are a also a number of “MOF Reliability Workbooks” in the MOF Technical Library (e.g., Reliability Workbook for Active Directory® Certificate Services) that describe proposed standard changes for the given system or service presented in a checklist-like fashion that allows the proposed change to be verified as a standard change. The MOF Reliability Workbooks are Microsoft Excel spreadsheets that also look at things such as Monitoring Activities, Maintenance activities, and Health Risks. This and other tools such as an in...

🔄 Note: Since the publication of this post, ITIL has evolved significantly. In ITIL 4 , Change Management is now referred to as Change Enablement , with an emphasis on enabling frequent, agile, and value-driven change. The types of change— Standard , Normal , and Emergency —still apply, but decision-making is more decentralized with the introduction of Change Authorities . While the concepts in this post remain useful, we recommend pairing it with updated ITIL 4 guidance for a complete view. Rusty asked: I was looking for terms used for categorizing the impact of a change. I remember in Version 2 of ITIL that changes were categorized as Major, Significant, Minor, and Standard. Is that no longer done? Or is the impact also defined as the priority—High, Medium, and Low? Rusty, I’m going to give you my answer in three parts. This information can also be found in Section 4.2 of your Service Transition Book.   In ITIL V3 changes are now categorized into three distinct ...

I was recently asked about Standard Operations and Maintenance activities relative to the Change Enablement practice and SLAs. Here are a few thoughts. Standard Operations and Maintenance is really something that is defined in a Service Level Agreement (SLA) in consultation and negotiation with the customer. It is not a determination made solely by IT or Operations. The customer or receiver of service helps to establish whether an “outage” has occurred. Because we want to adhere to the terms and conditions set forth in the SLA, strong controls should be in place. It is not a question of whether the Change Enablement practice will be used, but rather the degree of Change Enablement that will be applied. A solid approach is to establish a clear definition of what constitutes a change in the organization. ITIL defines a change as “the addition, modification, or removal of anything that could have a direct or indirect effect on services.” This is a broad definition and covers just ...

I was having a discussion with a learner this morning about the difference between Service Requests and Standard Changes. This learner's organization publishes a list of standard services that users can request via a self-help tool. The Service Request will be routed to the Service Desk. The Service Desk will review the request. If appropriate, the Service Request may be fulfilled by applying a Standard Change that has been approved by Change Management. By definition, a Standard Change is a pre -approved, low risk change (such as a new hire) that can be fulfilled almost immediately. Standard Changes must be recorded, possibly as a Service Request. They do not require operational oversight by the CAB. It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk chang...

I've been spending time within the Service Transition book. Did you know that ITIL V3 has a prescription for performing an impact analysis of a proposed change in the form of 7 "R" questions? Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change? What is the RELATIONSHIP between this change and other changes? Frankly, I would add or clarify a couple of questions: What is the COST of the change?" (broken away from the Resources question) What is the TIMELINE for implementing the change? Other than that, I believe that these are meaningful and well-rounded questions, They can serve as a good foundation for a Request for Change template and informed Change Advisory Board discussions.