1 The case for change management

“Change is the only constant in life. Heraclitus”

Change management is arguably the most widely adopted IT service management (ITSM) practice. Whether it is formally recognized or not, every organization has some form of change management because it is simply impossible to maintain IT services without managing changes. Unfortunately, there are nearly as many definitions of change management as there are those who discuss it.

1.1 Change management goals

Let’s start with a very basic definition of change management. What is it tasked with accomplishing?

IT change management is an organizational capability that seeks to:

• Support timely and effective implementation of business-required changes

• Manage risk to the business appropriately

• Minimize negative impact of changes to/for the business

• Ensure changes achieve desired business outcomes

• Ensure governance and compliance expectations are met.

You’ll quickly notice that these goals do not sound very IT-like, at least in the traditional sense. They have little to do with technology and infrastructure and much to do with what the business requires.

Managing the technical details of IT changes is necessary and important to ensure successful business outcomes. Unfortunately, a change management programme that starts with an internal (IT) view has limited scope and is the root cause of many such programmes struggling or failing altogether.

Change management is often referred to as a process (and there are most certainly processes involved with managing changes), but to be successful it needs to be much more than that. Successful change management is an organizational capability that supports the changing business needs, and to that end, it must start and finish with a singular focus on achieving business outcomes.

Let’s take a closer look at the goals of change management.

1.1.1 Timely and effective implementation of beneficial changes

This is a pretty straightforward goal, but from it, two key principles emerge.

1.1.1.1 Timeliness

When it comes to timeliness, the IT organization’s objective is to support the business by harmonizing with (not outpacing) the rate of change needed by the business to support its goals.

In highly competitive markets, business is driven by a strong sense of urgency: the need to get products quickly to market to maximize profit, and to innovate faster than the competition to gain market share. These companies’ IT organizations must match the rate of change required to enable that competitive advantage.

But faster is not always what’s required. For instance, if your organization builds and maintains aircraft or bridges or develops products for healthcare or the military, timeliness takes on a different meaning. In these cases, change management must match the need for precision and flawless execution. Product development cycles in these industries and the nature of the businesses create different demands on IT’s change management.

It’s not a matter of right and wrong – it’s about understanding the business you serve, and building and adapting capabilities to the meet its needs.

1.1.1.2 Effectiveness

Effectiveness is a measure of how well the change management capability meets business needs. The end result of effective change management is changes that are consistently implemented when needed and that produce the expected business outcomes.

Effective change management must be mindful of ‘time to value’ – the time from identification of the need for a change to the time the business value from the change is realized. Notice that the end point is not when the change itself is implemented, but rather when the change produces the desired (or expected) business outcome. Some changes never achieve the desired result, which makes time to value infinite – the opposite of what’s desired.

This end-to-end view of change effectiveness is what differentiates a change management capability from a change management process. It is also a departure from the typical technology and IT-centric view taken by many change management programmes.

1.1.2 Manage risk

It probably goes without saying that IT change management comes with an implicit oath to ‘do no harm’ to the business (which includes the underpinning IT services). But it is also true that all changes come with some degree of risk. Successful change management must balance these two aspects such that the business enjoys the outcomes the change promises with no, or minimal, harm.

When things go wrong in IT, the most frequently asked question is, ‘What changed?’ The capability to understand and manage change-associated risk is a large part of effective change management. Change-related risks include unintended consequences, negative business impact, compromise of information security and data loss or corruption.

Change-related risks also include failure to realize expected business value as a result of IT delivery delays, or implemented changes that don’t produce the anticipated outcomes. A programme that focuses on the technical aspects of change at the expense of business risk considerations is not going to be successful; but it can be challenging for IT people to understand the relationship between the two.

Ironically, the goal is not zero risk but rather an acceptable balance of risk and desired business outcomes. Historically, change management sought to eliminate risk, often at the cost of delivery delays, but these days decisions to delay changes based on risk concerns must be carefully weighed by the business. In some cases, the business may choose to accept identified risks because of the significant window of opportunity afforded by timely delivery.

Management of risk is beyond the scope of this publication, but generally falls under the ISO 31000 standard. ISACA’s Risk IT (included in the broader COBIT^® framework) is an excellent reference for managing IT risk.

Information security management, which falls under the ISO 27001 standard and related frameworks (such as NIST cybersecurity framework), is also outside the scope of this publication.

No change management programme can guarantee zero risk; and this is not the goal of risk management. The appropriate management of risk strikes the optimal balance between risk elimination on the one hand and value realization on the other.

At a minimum, change management must ensure all changes have been adequately evaluated for risk. Keep in mind that many risks are not technical in nature, including:

• Delay in delivery of changes

• Failure to realize anticipated business value from changes

• Failure to meet windows of business opportunity which are dependent on changes.

Change management is a critical component of an organization’s broader risk management programme, which must be able to demonstrate that changes are evaluated for risk, and that risks are documented, analysed and dealt with appropriately. Business management ultimately determines the organization’s appetite for risk and acceptable strategies to manage it.

1.1.3 Minimize negative impact

Frequently referred to as ‘avoiding unintended consequences’, minimizing negative impact is perhaps the best-known objective of effective change management.

Unintended consequences are not limited to technical and infrastructure issues, incompatibility of components and the like. They might also include:

• Usability issues

• Degradation of performance of existing parts of the service

• Unexpected results in other areas of the service – for instance, the incorrect calculation of payments in an area of the application that ‘wasn’t part of the change’

• Other services on the infrastructure that no longer work correctly

• Other applications impacted by changes to underlying data and data structure

• New usage patterns that cause capacity issues

• Accidental compromise of information security

• Inability to use the changed system correctly because either support staff or users have received insufficient training

• Failure to update configuration information for this change that complicates the capability to make future changes or support this one

• Failure to notify appropriate stakeholders in a timely manner.

The IT infrastructure is a complex interrelated mixture of legacy applications and platforms, modern multitier application servers, both internally and externally hosted. For all the investments in fault tolerance and high availability, it’s often the least obvious, simple things that cause the greatest disruption.

Even the smallest changes to a single component can have a surprising impact on seemingly unrelated systems and services.

Changes must be analysed to ensure there will be no unintended impact on the business. Configuration management is essential to understanding how components are interrelated and how changes to a component will impact on others.

Testing, especially system-wide regression testing and change modelling, can significantly reduce unintended consequences. Many organizations do only minimal change validation because of limited testing resources (and reliance on manual testing methods). Limited testing significantly reduces the ability of change management to effectively evaluate changes.

In order for change management to mature, you’ll eventually need to invest in test automation. I’ll talk further about testing and change validation later.

1.1.4 Business outcomes

‘Outcome’ is a word I’ve used a lot so far, and for good reason. Much of what has been done under the umbrella of traditional ‘change management’ has been process-focused (e.g. how IT can reduce the number of errors that get released into production). The outputs of the change process include the implementation of the required changes with some level of assurance that they won’t have any negative impact.

Business outcomes are tangibly different in that they are closely related to customer satisfaction and the success of the business itself. Shifting the focus of change management from simply making sure new changes don’t cause problems in the production environment to enabling desired business outcomes is critical to change management achieving its promised value.

To be successful, therefore, change management practitioners must first understand what outcomes the business is hoping to achieve. Changes must then be evaluated to determine whether they are likely to ensure that the desired outcomes are realized. Stakeholders must be engaged throughout the process, and results constantly evaluated against the required outcomes.

If your change programme has been primarily an internal IT effort focusing on the technological aspects of change, this is a significant shift that will require careful handling.

Changes are necessary to support the business, both to keep the IT infrastructure stable and add/change/update business-required services and functionality.

Changes that will not be beneficial to the business should not be approved. This requires the IT organization to work very closely with the business. It also requires IT staff to use their knowledge of technology and infrastructure to assess how requested changes will help or hinder the business goals.

Change management roles in IT are quite challenging on account of this extra requirement, in addition to managing the technical risks and details, of being able to anticipate how changes will impact on users. This may require the development of training (for support staff, users and IT operations) and transition plans for both users and IT operations.

1.1.5 Governance and compliance

Increasingly, organizations face governance and compliance expectations around managing changes. These requirements are at the organizational level, and IT must ensure that requirements are consistently met. Change management serves as a critical control point where compliance objectives are enforced.

1.2 Change management versus organizational change management

The scope of this publication is IT change management – managing changes in the IT environment. Another term that causes some confusion is management of change, or organizational change management.

Organizational change management, which deals with managing people through transitions, is a broad topic that is beyond the scope of this publication but warrants a brief discussion because it is interrelated.

When the Greek philosopher Heraclitus declared that ‘change is the only constant in life’ he had no concept of the complexities of the modern world, but it turns out that his words were prophetic.

The focus of organizational change management is on the people side of change. Changes such as introducing a new product, or entering or divesting from a market have an impact on the people of the organization. Likewise, corporate reorganization or downsizing are significant changes. Even something as simple as introducing a new desktop office suite has a people side to it. All of these require both technical changes that must be managed and people-related issues that need a different kind of careful management.

As a practitioner, you cannot afford to ignore the people side of change management. This publication includes a fair amount of guidance for you as a practitioner to address this aspect while you work to adapt change management for your organization. I’ve found that people, and with them the organizational culture, comprise the largest challenge faced in building a successful change management capability.

The multiphased approach described in this publication is based on my experience of successfully introducing the concepts of change management while minimizing cultural resistance (‘pushback’).

So, while IT change management and organizational change management are two distinct topics, you’d be ill-advised to try to build change management without managing organizational change.

1.3 A brief history of change management

Gone (but not forgotten) are the days when changes were implemented as needed by technical experts who essentially owned the applications and infrastructure. Developers had complete control of the entire (mainframe) environment; changes went through a fairly rigid test process that accurately modelled the production environment.

These experts were revered with near deity status. Customers had no idea how any of it happened, but they knew it was complex, and were just happy when everything worked. With complete understanding and control of the entire environment, there were seldom any significant problems. When there were issues, the experts were available to fix whatever broke. Only limited communication was needed with others before making changes.

This created a wall of sorts between the all-knowing developers and support teams – such as service desk and operations staff. Support and operations generally had no advance warning that changes were planned or completed. Often the first clue for the support staff was provided by users calling the desk to find out what happened.

This attitude remains part of the IT culture; the only difference being that modern technical experts manage smaller pieces of technology. But as the IT infrastructure evolved from the mainframe and centralized data centres to a more distributed model, complexity increased significantly. With the increase in complexity, the likelihood of interactions between components adversely impacting on other parts of the infrastructure also increased, along with the corresponding diagnostic difficulties.

The communication and coordination issues in IT culture are difficult to overcome. One of the earliest forms of change management was simple and logical: have a meeting once a week with all the key players – development, operations, support, security – and talk about upcoming changes. The modern-day CAB evolved from these simple meetings.

Meanwhile, those working in the field of engineering, by virtue of its critical nature – designing and building things such as bridges and medical technology – have a clearer understanding of the need for precision in managing changes. It is undeniable; when lives depend on engineered systems, you cannot ethically just make changes and hope for the best: there is the need for more rigour and diligence to ensure changes that don’t have unintended consequences.

Manufacturing engineering has rigid processes around the introduction of change orders for even the most minor changes. Great effort goes into keeping detailed records to track exactly when changes were made, and by whom. This enables quality engineering and field repair staff to know exactly how and when each product was manufactured and who to contact if warranted.

As IT change management evolved it adopted more from the world of engineering and the CAB became more structured and formal. Solid plans were required to help CAB members understand how the proposed change might impact on other areas. What parts are being changed, and in what ways? When and how will the changes be implemented?

It is important to understand something of the history of IT change management because, as the saying goes, ‘Those who fail to learn from the mistakes of their predecessors are destined to repeat them.’ (paraphrase, George Santayana)

1.4 Implementation challenges

Change management affects many people, both in IT and the business; there is no part of the organization that doesn’t have a stake in it.

It is no surprise that this diverse group of stakeholders is the source of most of the challenges associated with building an effective change programme – they each have a unique interest in the process.

1.4.1 Prior efforts

If an organization didn’t appropriately address the organizational change management issues associated with an earlier attempt to implement an IT change management capability, all future efforts are likely to suffer a negative impact. It doesn’t really matter why the earlier effort was unsuccessful; the current effort will be impacted.

This could, in fact, be the single largest hurdle you’ll face. Whether you’re implementing the basic change programme I describe in Chapter 3, or maturing an existing one, the organization will remember and carry the baggage from previous efforts.

If you’re new to the organization, the best course of action is to find out about any prior organizational efforts. Talk with staff about how they feel about IT change management; try to understand what worked and what didn’t in any earlier endeavours. You need to know what people thought about the previous attempt, because, like it or not, your current effort will be viewed as another chapter in the previous effort.

Given that it’s nearly impossible to distance your current effort from the organization’s history, you’ll want to look for ways to incorporate the learning from the earlier effort. If the previous effort was particularly painful, and people have strong feelings about it, consider a strategy to address the specific concerns raised. For example, if the previous effort had marathon CAB meetings, build the new change programme to keep CAB meetings short (I offer some strategies for optimization in Chapter 5). Make commitments to staff and follow through; give people every reason to believe that your current change programme will not have the same problems as the previous attempts.

1.4.2 Cultural concerns

Every organization has its own unique culture. Mature industries such as banking, gas and oil tend to have a slower pace and more rigid structures and policies (in some cases required by compliance oversight), whereas a Silicon Valley start-up will be much faster paced and more flexible. Government, military and healthcare are heavily regulated and policy-driven. Organizations that provide IT services to other companies will tend to have a more direct appreciation regarding why IT processes are important to their customers.

The list goes on, but you get the idea – each company culture is born out of the environment in which it operates, so it stands to reason that change management, or any new capability, must match the culture. This means you’ll either have to work to change the culture (which is very difficult, time consuming and beyond the scope of this publication) or adapt what you do to fit into the existing one – which is greatly preferred, and much more likely to have positive results. Without a working knowledge of the culture, you can easily make assumptions and risk a negative reaction in unexpected ways.

A company that prides itself in being egalitarian and collaborative may view a simple concept such as process ownership as dictatorial and not a ‘company value’. Likewise, trying to implement a best-practice process ‘by the book’ has its own challenges: highly innovative cultures may perceive ‘best practices’ as tantamount to mediocrity and a ‘dumbing down’ of their industry-leading ethos.

In practice, it’s not nearly so black and white, and it’s important to chart out a strategy that’s clear and intentional about any cultural elements that need to change. Equally important is a plan to construct and communicate change management in ways that meet the key organization objectives, are culturally palatable and, most importantly, clearly articulate ‘What’s in it for me?’ for each stakeholder impacted by the effort. This is the challenge for the ITSM practitioner.

1.5 Process versus outcomes

One of the reasons the approach in this publication is so successful is that it does not focus on the process. The thinking behind the process approach is sound – a consistent, efficient and effective process produces high-quality, reliable results. For many years, ‘process’ has been the antidote to inconsistent and/or poorly performing IT delivery.

There’s nothing inherently wrong with process improvement. But let’s be clear – if improving processes does not produce a commensurate increase in value realized by the business, not only does it lack positive value, but the perception of the effort will be negative. Period.

By contrast, the increase in value achieved through outcome-driven change management will be perceived as highly beneficial.

1.6 A clear business reason for IT change management

Any process improvement effort must begin with clear and communicated business outcomes. Let me be very blunt: implementing a change management process by itself is a weak rationale for investing in change management. While it may be exactly what’s needed, a change management process is not in itself a valid business outcome.

My position on this isn’t a simple matter of personal preference or opinion. While change management is one of the most frequently implemented service management processes, it is also the one with the strongest negative perception among IT staff.

The biggest challenges faced in building a successful change management capability are nearly all cultural – in other words, people-related: how people feel about change management, and whether they’re willing to get on board.

This means it is critical to establish a clear business case for change management. It is important to address how staff will benefit from the new change capability. With human nature being what it is, people are reluctant to endure the transition until the benefits of the change itself become more appealing than the discomfort the change presents. If you lack a compelling case that staff can understand and buy into, you’ll face everything from apathy to outright resistance.

Many organizations commission a change management programme on the heels of a high-impact change-related failure – often accompanied by significant negative financial or other business impact.

The good news is that this provides strong business case and senior IT management support for a change programme. They recognize a pain point and are convinced that improvements in change management are the answer. The case is clear: badly managed changes adversely impact on the business. The call often comes down from the chief information officer (CIO): ‘I want change management, and I want it now.’

Significant improvement efforts that succeed typically have one feature in common: a critical and committed high level of senior management support.

The bad news is that the organization may not fully understand the magnitude of process and organizational changes required to adopt an effective IT change management capability. This is the classic case of mismatched expectations: leadership expecting one thing (immediate reduction in change-related issues), and change management implementers another (processes, metrics). It also suggests that one of the keys to success is both understanding and managing expectations – not just for management but for all stakeholders.

These reactionary programmes generally go astray in one of two ways: they try to implement either a comprehensive (and complex) change programme, often ‘by the book’, or an overly simplistic programme that doesn’t produce the anticipated reduction in change-related failures.

In either case, senior management may lose interest long before the programme produces any tangible value for the business. In other words, without a strong and determined commitment to improving change management, the result is likely to be immediate fire-fighting. Patience has a tendency to run out, and with it go the resources and support needed to achieve meaningful results.

Every organization that is thinking about an IT change management programme (either a first-time implementation or maturing an existing one) must grapple with a few fundamental questions:

• Why do you want to invest in a change management programme?

• What results does the business expect?

• What level of capability maturity is required?

• What level of investment is necessary?

These questions warrant a fair amount of thought, as the answers will determine both your path and the difficulty in following it.

Some things to consider include:

• What problems do we experience?

• What do we need from change management that we currently don’t get?

• Will improvement in change management be more valuable than other things we could be doing with same the resources?

• Does the business share the view that change management needs to improve? What problems do they see?

• Are the current problems exclusively change related or are there other contributing factors (e.g. IT strategy, design and architecture, development and testing)?

• Are there policy or regulatory requirements for change management that are not currently being met?

• Is the organization prepared to commit the required level of resources for the required length of time to ensure success?

• What is the downside of not investing in change management immediately?

• What is the organization’s current state of change and/or transformation?

• Is now the right time to invest in change management?

Without a clear and compelling case to invest in change management, you’re faced with a challenge. Any attempt to move forward with insufficient support for change management is to risk falling short of expectations or outright failure. I don’t want to be dramatic about it, but there are lots of factors to consider and most of them have little to do with IT processes.

Let me also address a related issue. Where a change management improvement effort starts at the grassroots level in IT as a means of internal improvement, it may be seen by them as a self-evident need. It’s true that incremental improvements can be made with limited involvement with the rest of the business, but, as I describe in Chapter 2, such an internally focused effort can unknowingly impede improvement in other areas.

1.7 Business value

The role of the board of directors, company president and the CEO is to ensure the resources of the organization are achieving maximum value for the stakeholders. At a very fundamental level, every asset of an organization exists for one purpose: to achieve the goals of the organization most effectively.

IT resources are no different. Companies invest in IT, staff and infrastructure to maximize the likelihood of most effectively satisfying the interests of their stakeholders. Organizational capabilities such as change management are assets as well. The investments made in staff, training, process improvement efforts and tools should result in building organizational capabilities – enhancing business performance and eliminating barriers to success.

Building an IT change management capability requires the investment of organizational time and resource. Organizational capabilities do not come free; there is always an opportunity cost – the organization could be doing something else with those resources.

Each organization must decide what level of investment in process maturity it believes will achieve optimal business results.

It is important because CIOs must justify why they are investing precious IT resources in building a change management capability rather than in other business projects and schemes that could be viewed as being of more direct value to the business.

If the investment in change management doesn’t show tangible results (i.e. ones that can be quantified in business value terms) then it will be an uphill battle to persuade management to continue to make the investment.

It is therefore critically important that as you structure your change management plans, you show tangible results in the short term to maintain management support for continuing the effort. In Leading Change (1996), John P Kotter emphasizes the important of generating these ‘quick wins’ in order to both build and maintain support for the initiative. For the business, investing in change management is just like any other venture: it is evaluated by assessing the return on investment.

Businesses must optimize the whole, as a system, not just individual or specific parts. In the same way as marketing and manufacturing, IT is part of the business and should be funded at the level senior leadership believes will optimize the enterprise’s overall results and deliver maximum value for the stakeholders.

This stands in contrast to IT organizations’ self-balancing investments in internal efficiencies, business-focused projects and infrastructure readiness. The taking of resources away from business-focused projects must be kept to a minimum; IT capability investments must be weighed against all other organizational investments.

Keep in mind that the business is interested in improvements in change management (results) – not the implementation of a fantastically engineered best-practice change management process. Unfortunately, this is where too many well-intended change management efforts get shipwrecked. Given that the overarching goal of the change management effort is the value it’s producing to the business, a basic process that demonstrates improved change management is better than an impressive process where there is no improvement in tangible results.

It is helpful at the outset to do a gap analysis of current change management versus desired end state. Identify the specific areas where the current change capability is working well and where improvements are required. With that in hand, determine the optimal target end goal and assess where the two differ. This will help establish specific areas where improvement is required as well as creating a clear end goal, which is critical in managing expectations.

Suffice it to say that investing in change management is much more than a simple operational decision. It is important to understand organizational challenges and constraints at the senior level. Appreciating the constraints will help you establish realistic and attainable maturity goals for your change effort as well as secure the required senior management support.

It is important to note too that ‘business value’ must be quantifiable and measurable and expressed in business terms. This is the guiding principle of all successful change management efforts.

1.8 Chapter 1: key concepts

The key concepts in Chapter 1 can be summarized as follows:

• Change management is a capability to:

• Support timely and effective implementation of business-required changes

• Manage risk appropriately

• Minimize negative business impact

• Ensure changes deliver desired business outcomes

• Ensure governance and compliance expectations are met

• Focus on business outcomes, not process outputs

• Recognize that IT change management is not the same as organizational change management

• Start with a clear business reason for implementing (or maturing) change management

• Appreciate that the implementation of change management is greatly affected by the culture of the organization

• Remember that all IT-improvement investments, including change management, must be quantified in business terms to demonstrate business value.