Change Management – What is it, Why should we do it, and How?

In the current business environment, the term “change management” has come to have a spectrum of meanings.  One end of the spectrum, as illustrated by the books Leading Change by John P. Kotter and Making Sense of Change Management by Cameron & Green, refers primarily to a leadership activity in making strategic or cultural organizational changes.  Often this approach is associated with organizational restructuring, mergers and acquisitions, and major strategic changes.  Approaches at the other end of the spectrum, having more tactical application, focus on the changes intended to be created by individual initiatives or projects and providing tools to enable those changes.  This approach is illustrated by the books Change Management: The People Side of Change by Hiatt & Creasey and ADKAR: A Model for Change in Business, Government and our Community by Jeffrey Hiatt.

While the terms are sometimes used differently in different contexts, a distinction needs to be made between change management and change control.  In relation to projects, while change management refers to managing the impact of changes generally on an organization, change control refers to the recognition, quantification and decision processes for changes occurring within an existing project.  Thus, for projects, change control deals with changes to the three variables of scope, schedule and cost and how change in one impacts the others.  In the context of systems management (e.g., as in the ITIL standard), change management defines the methods by which changes may be made to systems and the tools for managing those changes.

This discussion applies to change management in the context of managing projects.

The purpose of executing projects is to create change.  Project management methodologies may support the expectation of change, possibly as part of a project charter; however, project management methodologies don’t address the dynamics of change in an organization nor provide tools and techniques for achieving change.  This absence can lead to projects that ultimately fail to deliver their intended benefits despite have been “successful” from the project management perspective with delivery being on time, on budget and with full functionality, but not creating the desired business impact.  The missing ingredient is a planned change management approach integrated with the project plan.

Typically, software development methodologies support change control, but don’t explicitly support change management as has been defined above.  In waterfall style methodologies, and with the PMI PMBoK, projects often contain a process of creating and managing change orders as a means of accommodating changes to scope, schedule or cost during the execution of a project.  In Agile approaches like Scrum, the use of a product backlog, sprints and sprint planning define a change control process without naming it that.  In both types of approaches (prior to PMBOK 7^th edition), the impact of the project is not explicitly managed (or even mentioned) and is left to the project team to define on their own.

Given the spectrum of definitions for change management we find that there are a range of methodologies that have been developed for achieving change management.  The following table illustrates a sampling of published change management methodologies and compares their key features.  Of the four approaches, the first two have been published as books, the third is offered as leadership training, and the fourth is one of many available online training and certification offerings.

The table is arranged so that like concepts in each of the models is aligned horizontally.  Thus, for example, the stakeholder Awareness phase of the ADKAR model is similar to the step in Kotter’s Leading Change for creating a Sense of Urgency with stakeholders and both are similar again to the behavior of demonstrating the Business Case in Blanchard’s Leading Change.  Note that in some cases models don’t have similar concepts and therefore have blanks cells and in other cases multiple concepts in one model are distilled to a single, potentially less detailed concept in another model.  For example, the envisioning phase identified in the other three models is not described in the ADKAR model.   Possibly the ADKAR model assumes that the envisioning phase is handled by the larger project (as virtually all project methodologies do) and therefore need not be a part of the change management approach.

Since the purpose of projects is to create change and since project management and software development methods don’t provide sufficient, if any, detail on managing that change, it is expected that project managers will identify, adopt, and implement a change management approach as part of planning and executing projects.  The choice of methods is an exercise left to the reader and is likely to depend on the individual project and its context.