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

“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 s...

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

Paul recently asked: Hello, When browsing the topic of Service Requests, I visited your site where a question was answered on the differences and similarities of Service Requests and Standard Changes. I was intrigued by the following passage: "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 changes that are not 'requestable' by the user. Any Service Request or Standard Change that presents a higher risk may require reassessment and reclassification by Change Management." I am trying to think of a term that would differentiate the one from the other. Considering that there are Service Requests that may invoke a Standard Change, I see two possibilities: it may be a Standard Change that...

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident status of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead? Thanks, René W. Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” ...

Sandy, if you have any more questions, just let me know! Standard Operations and Maintenance is really something that gets defined in the Service Level Agreement in consultation and negotiation with the customer. It is not really a determination made solely by IT or Operations. It is the customer or receiver of service that helps to establish whether an “outage” has occurred. Because we want to adhere to the terms and conditions set forth in the SLA we want strong controls in place. I think it is not a question as to whether the Change Management process will be used or not used. It is more a question of the degree of Change Management that will be used. A solid approach would be to establish a clear definition of a Service Change in the organization. ITIL says it is any “addition, modification or deletion of elements of the delivery of service” [paraphrased]. This is a broad definition and covers just about everything we do in IT. So, next we need to identify what we actually do in ...

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.