2 A practical multiphased approach

“It is not necessary to change; survival is not mandatory. W. Edwards Deming”

2.1 The change management challenge

Aside from incident management, change management is arguably the most well-known and widely implemented IT service management (ITSM) process.

Unfortunately, many IT professionals have negative feelings about change management.

Why? I believe it comes from:

• Heavy reliance on centralized control

• Rigid focus on process (for the sake of process) compliance

• It being viewed as a quality inspection point

• There being little or no emphasis on the realization of business value.

There are two common approaches to implementing change management:

• Implement a very basic change programme that reviews all changes before release.

• Implement a fully mature change process as shown in best-practice frameworks.

By far the most common form of change management is the former – that of reviewing changes before they are approved for release into the production environment. This approach is primarily focused on the technical details of changes and serves as a gatekeeping function to protect the production environment. In this view, change management is all about analysing and avoiding any adverse impact caused by proposed changes.

This model inserts a change management checkpoint between a design/build and release into production (see Figure 2.1). When the work is completed and ready for release and deployment, change management is engaged as a simple last check to avoid any unintended technical impact.

The good news is that this basic form of change management can and does do much to avoid some unintended consequences. However, it falls far short of the end-to-end control required to ensure the execution from approval to initial design through to final deployment produces the required outcomes.

By way of ironic contrast, W. Edwards Deming’s revolutionary view, more than 40 years ago, was that quality should be engineered into the system/process rather than being inspected after the product has been built.

2.2 Starting small

Many organizations start with a very basic change management process that involves a programme of checking just before implementation. One of the main reasons for this is that it will be relatively easy to implement. Some of the other strengths and the weaknesses of starting this way are shown in Table 2.1.

This idea is straightforward – get the right people together (i.e. the subject matter experts) and review all changes before proceeding into production, and by so doing, protect the production environment from unforeseen consequences. In this form, change management becomes a gateway through which all changes must pass. The goal is to reduce the likelihood of issues associated with the change under review.

Staff should understand that the point of the review is to avoid a repeat performance of a previous type of failure. The review also serves as a point of communication – where every team, including support teams, get the opportunity to examine and understand the change and ask questions.

Getting people together to review changes has value in that it should reduce the number of failed (or rolled back) changes by anticipating a number of unintended consequences. When the issues deal with minor details such as logistics – staffing, scheduling, business timing – the implementation plan can be adjusted to avoid them.

Unfortunately, without a broader picture of the purpose and value of change management, it can be viewed as an impediment to delivery that slows things down; at the same time it can demonstrate lack of trust in IT staff to do things right.

A last-minute, reactive-only change management can easily turn into a convenient defence if something happens to go wrong. ‘Did it go through change management?’ becomes the first question when a problem arises and the ability to answer, ‘Yes it did,’ becomes justification for poor planning and execution. This form of change management not only fails to ensure business outcomes, it is counterproductive and obstructionist. It also casts a negative image of change management in the minds of IT staff that is almost impossible to shake. Many organizations that have implemented this form change management continue to struggle with change-related issues.

It is at this point that organizations must make some tough decisions. It is important to recognize that adding more rigour to an unpopular change programme won’t necessarily make it better. Very often the opposite occurs: the addition of restrictions and requirements typically produces staff resentment and resistance. Alternatively, some organizations decide to either abandon formal change management or allow the change advisory board (CAB) to become little more than a rubber stamp committee. Either approach has the same impact as adding more rigour.

This is one of the reasons organizations are desperately looking for more streamlined and efficient methods of managing change (such as DevOps and other Agile methods), which is unfortunate, because change management was never intended to be an obstruction.

The complete best-practice change process is designed to work throughout the lifecycle of a change (from the approval to design and build to the approval to release and deploy – and everything in between).

As you can see, although starting with a last-check change process makes a lot of sense and is easy to implement, it has a number of built-in constraints, its value is limited and it is very difficult to mature.

2.3 Quality inspection versus quality engineering

You may well be familiar with the work of W. Edwards Deming, the quality and systems architect whose landmark work with Japanese auto manufacturers in the 1950s and 60s formed the basis for modern quality engineering.

In Out of the Crisis (2000), Deming suggests a broader problem with the last-check approach:

“Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”

Deming’s point, in brief, is that finding defects earlier in the process is vastly preferable to discovery at the end. He suggested the best way to accomplish this was to engineer quality into the process.

The IT development process is surprisingly similar to traditional manufacturing. At each step of the process, work is performed, features are added and the solution is readied for eventual release to the customer. The aggregate time and resources invested increases at each successive step.

In manufacturing, if significant defects are discovered at the end, the product may be unsuitable for the customer. In the case of IT, if defects are discovered at the end of the development process, you’re forced to:

• Accept it as is

• Attempt to minimize the impact and release it, or

• Send it back for rework.

None of these options are particularly good for the business; they increase costs, delay the realization of benefits or reduce anticipated features or capabilities (and the value they enable).

Reworking a change after it has been completed delays release and adds extral cost. If it can’t be reworked, the change will have to be discarded.

Processes that rely on an inspection step at the end have limited value. In a practical sense, if significant issues are discovered during the inspection process, there are few options and all entail a less-than-optimal compromise to meet customer expectations – with the corresponding increased negative view of IT.

Issues that are identified by a last-check change process come at a cost – both in terms of delays to the business and the associated cost of remediation. A high-quality process where defects are found earlier results in less financial loss – even if the change is reworked or scrapped.

2.4 Starting big

On the other hand, trying to implement the fully mature process directly, as described in the best-practice frameworks – using a framework as a ‘cookbook’ or recipe source – is not only challenging for most organizations, it’s also the wrong approach.

Many people attend training and certification courses in these frameworks, and the guidance given there is sound and encompasses best practices in use in organizations large and small all over the world. But if you’re starting with little or no formal change management capability, it’s a pretty big leap to go from an ad hoc process to one that is unified and mature. Table 2.2 shows some strengths and weaknesses of starting with a big change programme.

This approach initially makes a great deal of sense, and you can easily see how it addresses the very issues faced in your organization. But back in the real world, you’ll face challenges that the books and training typically aren’t intended to address. The course covers what to do, not how to do it at your organization.

The change management process described on these courses is complex and depends on other processes, such as release and deployment and configuration management. But many organizations start their ITSM programme with change management and without having these in place.

A large change management implementation takes resources away from traditional project work and usually won’t demonstrate value quickly. This is where many well-intended change programmes earn a bad reputation.

Business and IT staff perceive change management as bureaucratic and slowing progress, creating resistance and ultimately undermining the success of the programme.

All this works against the success of a change programme. You risk losing support of the IT staff and the business.

2.5 Find the right balance

I’ve described two very common approaches to change management. In practice, these are just two ends of the spectrum. Every organization is unique, and every change management initiative is different.

Where these are helpful is in recognizing the trade-offs associated with either approach, and how that will work within your organization. Understanding both the culture of your organization and the desired end state for change management will help you structure your phased approach to best suit your situation.

For instance, if your organizational culture is rigid and structured by the nature of the business – healthcare, defence contracting and the like – it will tend to be more readily accepting of a more structured approach. However, if your organization is unstructured, heavily siloed or decentralized, taking smaller steps may be necessary.

In Chapters 3 and 4 I describe a balanced approach, starting with a basic phase followed by a second phase that adds to the change capability. I include a third phase in Chapter 5, designed to optimize a maturing programme.

In practice, it’s the phased approach that’s key to success – not rigidly following the phases as I describe here. Elements from later phases can be included in earlier phases, as needed, to address the particular challenges you face in your organization.

Much of the challenge in finding the right balance is adapting the best practices as needed to best fit your organization (see Chapter 6 for more on adopting and adapting best practices).

2.6 Cultural concerns

Every organization has a culture. Each is unique and influenced by the nature and challenges of the business, the attitudes of the staff and the behaviours commonly accepted.

As you begin to understand how the organization handles (or doesn’t handle) changes, you’ll learn a lot about how information flows through the organization. Be on the lookout for who is communicating what information with whom. This will give you tremendous insight into how various types of change are dealt with.

Recognize that as you introduce change management, you may challenge some very basic cultural values, one of which may be that IT staff were empowered to manage their own changes in the past – self-contained within IT.

Formal change control can feel like the loss of autonomy. Staff may feel they are no longer trusted to do what they’ve been doing for years. This may be especially true if your change management programme is viewed as a purely reactive response to some high-visibility incidents or failures. This makes it important to engage with all those affected to ensure they understand the intent and the justification – hopefully in the context of their own self-interest.

Organizations just getting started with formal change management will undoubtedly face resistance, because there will be significant changes for nearly all IT staff, and for many in other parts of the business as well. How it is handled will have a significant impact on the programme’s likelihood of success.

In their seminal work, ABC of ICT: An Introduction (Wilkinson and Schilt, 2008), Paul Wilkinson and Jan Schilt put it this way:

“The next conference you attend, look at the program and the titles of the sessions. 95% will focus on some framework or method or approach or specific process, very few will focus on addressing attitude, behavior and culture, telling you how to embed the solution in the organization, what sort of resistance you will encounter and how to overcome this. This leaves many organizations, new to adopting frameworks, with the naïve belief that they can simply be ‘implemented’.”

The ABCs they describe are attitudes, behaviours, and culture. Collectively, these represent the ‘people side’ of process adoption. By comparison, the processes themselves are actually straightforward.

One of the unfortunate downsides of traditional best-practice training is that the well-designed processes seem ready for immediate implementation. Many well-intended practitioners come back from training ready to implement a process, with no concern for cultural implications at all, which is unfortunate, because processes require people to be successful. Any effort to change or implement new processes invariably puts you face to face with organizational change.

Attitudes surrounding change management can touch on deeply held beliefs and cultural values such as:

• We hire top talent who know what they’re doing.

• We expect our staff to do the right thing.

• We empower staff to make necessary changes.

• We trust each other to work independently, to do what’s best for the customer.

You would be wise to take the time to understand how the new change management programme will fit within the organizational culture. Be very intentional about managing the cultural change that goes along with the new process.

Cultural objections commonly raised while implementing change management include:

• You say we’re doing everything wrong.

• Why do other technical areas have to review/approve my changes?

• What we’ve been doing is working fine; why change?

• It won’t work here.

• Best practices can only make you average.

Humans are complex creatures whose behaviours are driven by some deeply rooted needs and motives. Something as simple as implementing a basic change process can trigger some surprising Maslovian-like responses that can be very difficult to overcome.

When ‘process-only’ efforts struggle or fail, as they do, all too frequently, the first response is often to blame the framework. I’ve heard many IT professionals declare that ‘we tried such-and-such a framework, and it doesn’t work’, when, in fact, the framework itself is fine; the problem is the unwise emphasis on the process to the exclusion of adaptation to the culture.

Faced with a struggling process-focused programme, the organizations sometimes resort to forced adoption of heavy-handed process compliance. All this does is create even more ill will, resentment and resistance. In other words, the net impact becomes worse than the original failed attempt. Sadly, companies that have gone down this path will forever have a bad taste of ‘change management’, making it all that much harder to ever build a successful change management capability.

The approach adopted for this publication places a premium on achieving a value-producing change management capability, and includes addressing the organizational change management required for success.

2.7 Keep it simple

Simplicity is one of the guiding principles of successful change management, especially in the early steps. Include only those elements that are absolutely necessary, and whose value can be immediately understood.

This is where the multiphased approach comes in. The approach seeks to maximize the immediate value of a very basic change programme, while setting the stage for successfully maturing the process as specific milestones are achieved.

2.8 A word about tools

There are several commercial ITSM tools that include support for change management. The selection of a tool is beyond the scope of this publication for a specific reason – it is impossible to choose or configure the right tool unless you understand change management and the unique needs and challenges of your organization.

I don’t know who first said it, but the phrase, ‘a fool with a tool is still a fool’ pretty much summarizes my view on the subject.

I’m not suggesting that people or organizations with ITSM tools are in any way foolish. On the contrary – it is very difficult to have a mature change management capability without good tools (and there are a lot of good ones available), but change management, like other capability development efforts, depends on a balanced combination of people, process, partners and products (tools). As I’ve said, change management is not primarily a process effort – it involves the other elements in the right balance, as shown in Figure 2.2.

I’ve seen far too many change management efforts that are little more than total reliance on a software tool without ever addressing the more significant challenges of adapting the principles of change management to meet the needs of the organization.

It’s very tempting for an organization that’s just getting started to look for tools to help implement a standard change management process. This thinking typically results in an attempt to use best-practice guidance as a template to be religiously followed without the needed starting point: people. It places tool and process before people, and the end result is failure. Rather than accept responsibility for the faulty approach, the blame is assigned to the framework: ‘We did exactly what it said, and it doesn’t work.’

The other typical thought pattern suggests that if the tool embodies the best practices, then implementing the tool ‘out of the box’ provides a standard process. Sadly, the idea of a standard or ‘one-size-fits-all’ implementation of change management doesn’t exist, regardless of whether it is sourced from official publications or by installation of a tool.

There is no shortcut for the adaptation work you must do to make the process fit into your organization, and no justification for building your programme around a tool.

If your company already has an ITSM tool in place, I strongly encourage keeping your process development work separate from any tools implementation. Before you invest effort into the ITSM tool for change management, work through the people and process aspects. Use only basic tools, such as a simple spreadsheet. This will make it easier to keep your efforts focused on achieving the results the business requires instead of getting distracted with the specifics of how the tool should be configured. This approach will also keep you from including limitations of the tool in your process design. Remember, the goal is a change management process that delivers the expected outcomes and business value, not conformance to a tool.

You will learn a lot about how change management needs to work in your organization, especially in the first phase. You want the flexibility to be able to rapidly adapt your approach, so avoiding the unnecessary complexity of even a comprehensive tool is important for success.

Once you have a solid understanding of how your change programme needs to work, selecting and/or configuring a tool becomes a relatively simple task to meet the needs of your organization.

2.9 Clarity in roles and responsibilities

The introduction of formal change management will invariably necessitate establishing new roles as well as changing some existing ones. Having developed a solid understanding of how changes are currently managed, you should have a fairly clear picture of existing roles relating to managing changes.

Where roles need to be adjusted, there’s an elevated need for clear communication to both the people affected and those who understand their previous role. This is where the RACI (responsible, accountable, consulted, informed) chart can be helpful.

Roles are not cast in stone. With the agreement of the stakeholders, they can be adjusted as needed. RACI charts are a perfect reference point when disagreements arise and they help facilitate healthy dialogue. In this first stage the RACI chart can be very useful in identifying disparate understandings of roles and responsibilities. The chart itself is less important than the clarity it helps bring.

It is not uncommon for a basic RACI chart to be included in the change policy, but generally only at a very high level. For instance, it might say that the service desk manager is responsible for ensuring all approved changes are communicated with stakeholders. It is best to not use proper names (just roles) in a policy document.

2.10 The multiphased approach

With the perils of an overly simplistic approach (see section 2.2) on the one hand, and the challenges of the overly complex (see section 2.4) on the other, I advocate what I call a practical ‘multiphased’ approach in the following chapters.

Like many things in life, success in the earlier steps generates support for successive ones. Trying to adopt a fully mature change programme is somewhat like trying to run a marathon without having put in the time to build the physical conditioning and endurance. While it may be possible for some to just go out one day and run 26.2 miles, no one would recommend it as a good approach, and certainly not as ‘best practice’.

The successful change management programme must demonstrate measurable results at each step along the way. With this approach, senior management, business leaders and stakeholders will see immediate improvement in change-related issues, downtime and delays.

Like the would-be marathon runner, we must take one step at a time. Once we’re succeeding in the first, we take a second, and so on towards a change management capability that meets the current and future needs of the organization.

In the next chapter, we’ll take a look at that first step (phase 1).

2.11 Chapter 2: key concepts

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

• Starting change management either too big or too small has challenges.

• The change advisory board as a quality control inspection has limited value.

• Quality must be engineered into the development process (not inspected in after development).

• Success depends on mindful attention being paid to the attitudes, behaviours and culture of the people within the organization.

• Start small, and keep it simple.

• Don’t be a ‘fool with a tool’ – understand your organization and the underlying change management needs first.

• Create clarity in roles and responsibilities (use a RACI chart).

• Use multiple phases for a successful change programme.