Change Management

Peter Strempel

Change management used to be a big and scary process in which large, monolithic organisations had to prepare hundreds of employees to do a fixed set of tasks differently. Then it became a specialty in its own right, mostly to administer a deliberately mapped-out process for managing a transition between how things were done to some new, improved mode of operation.

The object is to ensure that changes align with business justifications, and minimise disruption to normal operations or new lines of business.

Today change is so much an expected part of work environments that its management is actually suffused throughout ordinary operations for most organisations. In essence, the most natural change management models closely mirror the business process and project management lifecycles, both of which are, in turn, based on the Deming continuous improvement cycle.

Organisational change should always have sound business reasons; change to adopt current management fads without a rational business case will yield disappointing and expensive results. Even a modest change project should come with a well formed plan, including a strategy to back out of it if everything goes wrong, clear communication to stakeholders, and a means of evaluating whether the change achieved its intended outcomes.

In larger organisations, and particularly when dealing with IT projects and systems, change plans can be very complex, depending on the circumstances and business environment of the organisation.

Figure 1 below illustrates a simple change management functional overview, or architecture, that could be collapsed or expanded to exclude or include layers of complexity at every step.

FIGURE 1: A simple architecture of a change management process in the Archimate visual notation, showing interactions and associated systems.
FIGURE 1: A simple architecture of a change management process in the Archimate visual notation, showing interactions and associated systems. Click the image for a larger view.
  • In this high level overview, the driver for a change request is shown as a business case, put forward by one of the stakeholders, who can include internal and external actors, including vendors, and in some cases, regulators and even clients or customers.
  • Even a simple group of stakeholders requires stakeholder management by the change manager, who consults with the group as required throughout the process.
  • The event that launches the process is a request for change, which triggers pre-vetting. This initial review by the change manager might include a check of incident and problem management records relating to affected systems or processes, project office schedules to look for conflicts in proposed implementation, duplication of proposed changes, and any other matters that might require a change request to be amended before it is passed on to the change advisory board (CAB).
  • The CAB can be a small group, or a very large one, composed as needed rather than permanently constituted. The more complex the change, the more likely it is that a wider group of stakeholders is represented for a particular change.
  • Usually the change manager chairs the CAB, and records its relevant proceedings. But the CAB is jointly responsible for the change review and approval (or rejection).
  • An approved change is likely to trigger authorisation of a work package by the service owner, responsible project manager, or other stakeholder. That work package can then be incorporated in the project management office (PMO) schedule of work; sometimes changes are not part of PMO operations.
  • A change approval may also trigger the preparation of a communications and training plan, often by the change manager, but sometimes by specialists in those areas. These plans ensure that changes do not come as a surprise to those affected, and that everyone who needs training to cope with new ways of doing things gets that training.
  • A final step in the process is the post-change review, which may be considered by the CAB, filed in the change management records system, and/or become part of incident and problem management.
  • The underlying software systems might include the configuration management database (CMDB), the change register, and the PMO register or schedule. These systems are likely to be interfaces to one or more relational database management systems (RDBMSs), and incorporate automatic routines to associate and update related records for transparent oversight of ITSM and other management functions.

Every component shown in the Archimate diagram in Figure 1 above can be decomposed or broken down into more detailed descriptions, often using Business Process Model and Notation (BPMN) or Unified Modeling Language (UML). The latter is particularly useful to map out data structures and relationships.

Figure 2 below illustrates decomposition by showing how just the pre-vetting step in Figure 1 might work in more detail than shown in the architectural overview. In this way a complex change management process can be mapped out quite precisely in succesively more granular or decomposed detail.

FIGURE 2: Hypothetical pre-vetting process in change management, rendered in Business Process Model and Notation to show interactions and process flows.
FIGURE 2: Hypothetical pre-vetting process in change management, rendered in Business Process Model and Notation to show interactions and process flows. Click the image for a larger view.
  • The diagram shows that a change initiator, who usually already knows the correct format and required details, completes a request for change (RFC) and enters it into the change register.
  • There might be an entire sub-process for an RFC, requiring specific naming conventions, and component details, such as a change plan with back-out and remediation options, and so on. In Figure 2 it is assumed that this sub-process is incorporated in the method for registering an RFC.
  • The change register in the diagram is shown as a data store. This could be a complex database or just a simple spreadsheet depending on the size and complexity of the organisation.
  • Once a change is registered, the change manager begins pre-vetting steps. in the diagram above it is assumed the change management system is sophisticated enough to forward a message to the change manager when new RFCs are registered, but this could be less complex: the change manager could simply check a spreadsheet or document repository on a regular basis.
  • The change manager’s pre-vetting steps might then include checking that affected systems and processes aren’t complicated by outstanding incidents or problems, that the proposed schedule does not clash with other changes or programs of work, and that all the requirements for an RFC have been met. However, pre-vetting and the evaluation that follows can be much more complicated, as shown in figure 3 below. Details of pre-vetting are then fed back into the change management system, along with a classification for the change. A classification might include codes for urgency, level of risk, identification of associated systems and end users, or any other characteristics considered important in assessing the change for approval.
  • The last step in pre-vetting is to schedule the RFC for consideration by the CAB. The symbol at the right in the diagram means that this process is not a self-contained and terminated kind, but one that forms part of a larger process association. In this case, the conclusion of pre-vetting leads to the CAB change review process.
FIGURE 3: A hypothetical change planning matrix listing some of the issues that might be considered in pre-vetting and change evaluation.
FIGURE 3: A hypothetical change planning matrix listing some of the issues that might be considered in pre-vetting and change evaluation. Click on the image for a larger view.

The people dimension

The above examples should illustrate how any change process can be visualised and mapped out for analysis and refinement before any costly systems and processes are put in place. There is, however, something this kind of mapping cannot do. I have learnt an important lesson over time: enthusiasm for processes and procedures should not blind practitioners to the need for maintaining situational awareness. If the change management process becomes a bureaucratic paper shuffling exercise, preoccupied with documentation rather than due diligence, its overhead cost will exceed its benefits.

This is particularly the case with managing the people side of change. Merely updating intranets or document repositories is no substitute for carefully considered and personalised communication and training plans.

Making sure that frontline staff know what the change is all about, and exactly how it will affect them can be entirely lost in processes that reflect a solely administrative perspective of the initiatives. The risk here is that management will impress on end users and others only that there’s too much distance between the change project and employees for there to be successful outcomes at the front line.

That way of managing change keeps staff in the dark, fosters rumours, and creates the perfect environment for resistance by people who don’t understand why and how the change is going to happen, and how it will affect them. The easiest conclusion to reach in that circumstance is that the change leaders don’t know what they’re doing, the change will be a disaster, and it will make things worse for staff.

For these reasons I believe the most important aspect of change management is managing people’s expectations and fears.

If planned changes will make a big difference to the way employees will go about their work, you can expect anxiety-based withdrawal from participation. Even if the change is considered trivial, if its effects are not communicated well, people will respond with surly resentment when they encounter something unexpected that makes them feel dumb or incompetent.

It is this fear and resentment that needs to be managed in parallel to the more structured change artefacts and processes. The first step in that direction is to recognise it, and to get employees to recognise it. My approach is a direct briefing, explaining the human dimension of change as similar to the Kübler-Ross dimensions of grief: denial; anger; bargaining; depression; and acceptance.

I see these dimensions best discussed when represented as a curve (see Figure 3 below), and asking people to think about where they are on that curve, how they can help each other survive the ‘valley of despair’, and how to focus on mastering the change.

Applying the Kübler-Ross curve to change management.
FIGURE 4: Applying the Kübler-Ross curve to change management.

The underlying principle in getting employees to think about this individually and in teams is to recognise that for every person who struggles or resists change, at least one other is distracted to help out or encourage the first. That represents two valuable resources not working to make the change a success. It would be better for all concerned to confront such problems early and collectively than to let change resistance linger.

Change briefings should also emphasise the continuous nature of change in contemporary business environments, and then provide the details or reminders of the most imminent changes, with specifics on why it will happen, what it will mean to the employees in their daily routines, and how they can engage with change constructively.

Such presentations might have to be repeated and updated regularly to create a permanent front-of-mind presence. In smaller organisations a change presentation might be usefully supplemented or even replaced entirely with direct, personal explanations. In larger organisations the presentations should be made available electronically, perhaps with detailed notes, so team leaders can reinforce team-specific messages in their separate team meetings.

Following on from communication must be leadership by example: spending time at the bleeding edge of any change to observe how people cope with it, to offer guidance on how to deal with new processes, including hands-on demonstrations, and to pick ‘change leaders’ on the ground to help their colleagues. That kind of engagement also makes the measurement of change objectives more rational: it’s not just abstract numbers collected by people too remote from the processes themselves to understand whether quantitative abstractions reflect a human reality.

The measuring component is not a one-off exercise. It ought to be as incremental and iterative as any improvement process to ensure that the intended outcomes were actually achieved and can be maintained longitudinally.

No two changes are ever the same, even if they are intended to mirror the same outcome. They all need to be considered individually within their specific contexts, including especially their human dimensions. Whatever the dynamic, don’t let change management become a process stepped through for its own sake, but misunderstood by everyone outside the change management team. There should be nothing mysterious about change, nothing to be frightened of, and no reason to resist or retreat from change.

Let me help you make sure that your change initiatives run smoothly to time and budget by creating the necessary awareness and ownership among your staff. Contact me to discuss your needs.

Let me help you make sure that your change initiatives run smoothly to time and budget by creating the necessary awareness and ownership among your staff. Contact me to discuss your needs.

RELATED: a primer I wrote to support a presentation on change management I delivered to three small teams in a non-profit organisation project setting.