Having spent considerable time on business transformation projects I can say with a high degree of confidence that the discipline of change management is becoming so watered down it is at risk of becoming more of a catch phrase than a serious discipline. The term is bandied about freely whenever a project is discussed without any real thought of what it will mean for the project. When project concerns are raised, the response is frequently along the lines of – that’s a change management issue or ‘we will ask the change manager to deal with that’.

The upshot is; for any given project, change management is treated as a ‘catch-all bucket’. Having said that, in many respects, this position is acceptable as the primary deliverable from almost every project is a change in behaviour at the individual and collective level.

The problem therefore becomes – for each project, how do you create a common understanding of what change management means for that specific project.

Recently I was asked to prepare a project initiation document (PID) for a client, working off their template. The template included all the standard headers such as objectives, scope, risk management, change management, budget and timeline.

This got me turning over an old chestnut of mine; what’s the difference between risk and change management.

My view is that the major reason to employ a change manager on any project is to mitigate risk and the biggest risks on any project are those represented by stakeholder behaviour. This includes scenarios where stakeholders:

1. Do not embrace the need for the project
2. Do not accept the deliverables of the project
3. Cannot / will not work with the deliverables of the project.

Consider the last PID or Statement of Work (SOW) you prepared or read. It probably had a risk section with a structure and text similar to this one. The table (sanitised) is a mix of actual examples from various clients.

Column one describes the risk and column four details what can be done to avoid it becoming an issue. Columns 2 and 3 are used to rate the severity of the risk threat.

To mitigate these risks, change managers are engaged. Therefore by extension, change managers are risk managers.

Now compare the table to the following typical position description for a change manager:

This position reports to the xx manager or executive and will be instrumental in providing change management expertise in support of organisation-wide business transformation, process reengineering and resulting system developments. The primary focus will be creating and implementing change management plans to maximise employee engagement and proactively manage employee and client resistance. The change management specialist will act as a coach for senior leaders and executives in helping them fulfil the role of change sponsor and will support project teams in integrating change management activities into their project plans. The role will involve liaising at all levels across business units to analyse and effectively develop, deliver and embed change management solutions in line with commercial objectives.

Quite clearly, there are overlaps between the risk mitigation actions and the change management position description. This raises the following fundamental question:

Why do change managers not formally link their change management plans to the risk register.

By way of example here is a change management plan I chose at random from a Google search.

http://tiny.cc/n4nj1w

 

 

This is a typical example of a change management plan. At a concept level I immediately question why a change management plan needs to exist as a separate document from the PID. However, if it is to be a stand-alone document, then there is no heading I would delete.

At no stage in completing the template is the author expected to link the change management plan to project risks. In fact, the word ‘risk’ appears only once in the template where the author is expected to describe risks to the change management process.

Based on this template, how can the project sponsor build confidence that project risks are being mitigated or that the change management activities will have any relevance to the risks at all.

My observation is that a risk register is typically prepared at the start of a project and then is really only given lip service through the course of the project. If the project manager does happen to review the register, then it’s likely that the participants in the review meeting will readily explain how the risks are being managed and all is good. No panic required.

Equally and by contrast, my view is that change managers frequently start a project with a comparatively light definition of their project activities. Often with no more detail than the position description referred to above, supplemented with some reference to change activities such as weekly communications broadcasts, training plans, status reports, town hall meetings etc. Most likely they will have ‘copy & pasted’ the relevant parts of the PID into the change management plan, if one exists at all. Then when the projects gets going they generally make it up as they go, using best and last experience as a guide.

My recommendation is that change management plans are retired as a separate document, replaced by the PID or SOW and that the role of the risk register is redefined so that it becomes a change management plan.

This will ensure that:

1. Risk mitigation strategies are better thought through
2. Change management is better aligned to the project
3. Change managers understand their responsibilities more clearly
4. Risks are continuously and actively managed, and
5. Project managers will have a structured means of evaluating the effectiveness of the change management aspect of the project.

Let me have your thoughts.