Skip to main content

Posts

Showing posts with the label Change Management

The Top Benefits of ITIL

Stronger alignment between IT and the business: Historically IT has not been a participant in helping to create business strategies, it was normally in the role of supporting them. Recently, with the speed of innovation impacting businesses position in the marketplace, IT has been playing a greater role in helping to develop that business strategy. The ITIL framework enables IT to act as a service provider and become a core and more strategic part of the business. Pre-defined processes and best practices from the ITIL framework enable businesses to react quickly to today's rapidly changing technology landscape, focus on innovation and ultimately keep customers satisfied. Improved service delivery and customer satisfaction: Event, incident and problem management processes included within the ITIL framework enable businesses to review performance, perform root cause analysis, resolve issues and through problem management, prevent future incidents from occurring and allows us

Digital Transformation - What Is It?

Customers are empowered and connected. To stay relevant many organizations are asking “how can we evolve with the digital era?” To lead the change, we must understand it.  It is likely that in the next one to five years your organization will focus on digital transformation in three or more of these areas: Artificial Intelligence / Machine Learning Defined as the study of " intelligent agents " on any device that perceives or learns its environment and takes actions toward success at a specified goal. The Internet of Things (IoT) The IoT refers to the connection of devices (other than typical computers and smartphones) to the Internet. Today things like cars, kitchen appliances, and even heart monitors can all be connected through the IoT. Who would have known that we might need to add items such as drones to an asset registery and learn how to manage them? And as the IoT grows in the next few years, more devices are and will continue to join that list. (Editor'

Agile Change Management

I always hear people say ‘Don’t like the weather, wait an hour it will change’.  The one constant in our lives is change. In business today, customers, users and stakeholders all have the expectation that as IT service providers we can and should be able to handle change requests at an ever-increasing pace.  Yet they still have the expectation that an appropriate response to all requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorization and especially to the realizable business benefit. For us to be able to do change management in an Agile environment, does that mean we must give up those requirements for speed and agility? The purpose of Change Management is to control the life cycle of all changes enabling beneficial changes to be made.  I was once told by a very wise thought leader ‘Being agile is a state of mind.  It’s more perspective than prescription.’  Why can’t we have a

Process Practitioner Examples – Roles and Responsibilities Revisited

Assigning clearly defined roles and responsibilities are critical to the success of every process. These roles need to be defined early and reviewed periodically to ensure proper training, communication and education.  A process without clearly defined roles will fail at some level.   There is a very clear distinction in the activities or the roles that are played out by individuals in your organization.  You should determine and communicate who is accountable and who is responsible for the process activities.  A role is like a hat.  One individual could wear two or more hats.  Watch out for titles.  You might have a title such as Service Transition Manager.  What role(s) would this individual fulfill? It all depends on WHO is best suited for the role or task that needs to be performed when it comes to assigning roles. The Service Transition Manager could be accountable or OWN the “Release and Deployment” process but might also be a practitioner and be responsible to perform task

Site Reliability Engineering

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.” Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ( (formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt. The discipline of SRE can begin to reduce this dilemma by

Why RCV?

I was recently asked the following: “I want to take the “Release, Control and Validation” (RCV) class.  As a Release Manager, I know it will help but I need to justify this for my manager.  What is the value of taking this class?” Every organization can be effective with release and deployments.  What is needed today is for us not only to get the job done but to do it efficiently.  Efficiency infers that we deliver value, but that we design and deliver services, BETTER, MORE, FASTER THAN EVER BEFORE and at the same time we are being COST effective. The role of Release Manager, although it is central to the release and deployment process, is much broader in scope than many organizations or managers realize.  This role in Best Practice is separate from Change Manager and from the actual Validation and Testing Manager or even the Change Evaluation role.   Frequently these roles will be assigned to one or more persons.  It does not mean that you have to open several new req's

What is RCV?

RCV stands for Release, Control and Validate.  These are critical activities that are required for every deployment.  Proper Release, Control and Validation (RCV) is achieved as a result of integrated process activities.  In today's dynamic business climate, service outages cause real bottom line impact to the business. Mature processes are critical in enabling IT organizations to smoothly transition new and changed services into production, helping to ensure stability for IT and the business. The ITIL Capability course, Release, Control and Validation (RCV), provides the best practice process knowledge required to build, test and deploy successful IT services.  RCV is also the name of an ITIL intermediate training and certification. This course provides in-depth knowledge of the ITSM RCV processes that include: Change Management Release and Deployment Management Service Validation and Testing Service Asset and Configuration Management Request Fulfillment Change Evalu

Change Evaluation

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 determining the performance of a

Continuous Delivery

Continuous Delivery is a software development practice where software is always in a releasable state.   Teams produce software in short cycles, ensuring that the software can be reliably released at any time.  By relying on automated testing and deployment, as well as ensuring collaboration and communication between development and operational teams (DevOps), the goal of building, testing, and releasing software faster and more frequently can be achieved. This approach can help to reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications and configuration items (CIs) into production.  A straightforward and repeatable deployment process is important for continuous delivery and will be critical for operational processes such as Change Management and Release and Deployment Management to be agile and robust in the DevOps environments where continuous delivery will be part of best practices.   Continuous Delivery is sometimes co

The Customer Experience

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 your customers. For me personally t

Change Proposals

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. This high le

Assessing and Evaluating the Change

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 the current change sc

Release, Control and Validation (RCV) – Service Management Secret Ingredients

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 organizations

Visible Ops & Agile Service Management

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 80% of outages are a direct results from poor

Visible Ops

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 then ……. I recommend that you read The Visible Ops Handbook by Gene Kim, Kevin Behr and Geor

The Difference Between Change and Release Management

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 management before being chart

The Value of Change Models

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

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

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

The Best of Service Transition, Part 4

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 implementation of the change?