Integrating Change and Project Management

Every change practitioner I know struggles with integrating their work into a project at some point. And I know a lot of project managers have been challenged with how to integrate the two disciplines as well. A prevailing theme is that integrating change management and project management is the most effective path forward. That makes sense, but how do you realistically and practically do that?

I have been working in change and project management for decades. Here is my personal evolution and how I currently manage the integration of change management and project management. My hope is that others can take what I have experienced and shape it into something meaningful for their own change and project management practices.

The Battle of Process

One obstacle at the very heart of this matter is that the processes involved create a conflict. Project management has processes designed to effectively deliver a project. Likewise, Change management has processes to help users effectively adopt what the project is delivering, e.g. a new software tool, a new process, etc. While similar, these processes are different. How do you bring these together? Does one process “outweigh” the other, or provide the umbrella for the other? Or are they equal?

I don’t think this has been solved; it remains more of a dilemma to be managed rather than a problem with a single, discreet solution.

Personal Evolution

Back in the 1990’s, I took project management courses and learned and followed the process for a typical waterfall project. I applied the methodology to technical projects such as SAP implementation, building and campus re-configurations, building maintenance shutdowns and mechanical and control system installations. I loved MS Project and it showed!

In the early 2000’s I became interested in culture change, business process management, and organizational changes. I grew a keen interest in the human side of change. As I learned more about change management (during and after my OD studies), I felt change management processes were underutilized and did not receive the visibility they deserved.

In order to equalize the playing field between both processes, I would actually perform a comparison of sorts, placing the project management process alongside the change management process I was using. Then I would match up phases and activities and try to set timing of tasks and actions into one combined “plan”. Usually, the project manager owned the plan and had little patience for any kind of project modification. Inserting activities into the project plan was fine but aligning phases and changing naming conventions was met with some patience and “nice idea, but no”.

I later became involved in groups with similar “Change Management first” mindsets and worked on projects that operated under the umbrella of and fit into the change management process used at the company. I found the projects more difficult to manage and we had low success rates. Most leaders and sponsors understood project management tactics, scorecards and terminology, but got a bit lost when that was couched under change management terminology and process. And, quite frankly, I found the process and tools of project management better for capturing and planning the change management activities and their phases.

One of my most successful projects did not employ a change management-first approach. In this project, change activities fell under the umbrella of the project management process. We anchored on the PM process and embedded any change management related work into the overarching project methodology. This approach worked well. And not just in the US. The same approach was used in sites across Europe and Asia. Sponsors, leaders and their staff understood what we were attempting to do rather quickly.

As time went on, I became involved in more projects and more organizational changes. I was frequently called into projects that were well underway. This usually created challenges, such as how to accomplish early phase change management activities when the project was in the late stages of implementation! Holding a workshop on sponsorship mapping or project vision is really misplaced a month before go-live. I found I was doing rigorous triage to apply only the most necessary change management solutions.

The big learning for me was that integrating change management activities into an on-going project was difficult, but not impossible. I quickly learned that it was bad practice to suggest delaying project progress so I could perform the various change activities that typically occur early in the change process (sponsor maps, communication landscapes, visioning work, stakeholder analysis). But I was of the mindset that all of this needed to happen! The project would fail without it!

In reality, it didn’t. In most cases, the sponsor was on board, they knew their job and what they needed to do. Filling out paperwork to prove it was not required and would be a waste of time. And most teams knew their stakeholders and how to reach them, so a full-blown stakeholder workshop was equally not required.

These experiences left me with a wider view of managing change and project management processes side by side. And I began to question what I was taking for granted. It came down to sequence — why was I trying to initiate change activities based on a sequence? If I could help users successfully adopt a new tool even when change management joined a project mid-stream, was the sequence of change management activities all that important?

Fundamentals

The next step, and the place I am currently at is not focused on change process, but on those fundamental elements that help users adopt something new. (I’m going process-less, if that’s a word). There are fundamentals that work to create adoption of a new tool, process, or organizational change. These fundamentals are true at every stage of an initiative that introduces a change. They are part of the planning and implementation and realization.

Here is an example; sponsorship is one fundamental. If you don’t have it, adoption of a change is unlikely to happen. No matter what project phase you are in, you should always be able to answer questions such as “Who is the sponsor? Does the sponsor actively communicate the initiative? Is the sponsor driving consequences?” If the answers to these questions are “yes”, then there is a good indication of solid sponsorship. And that’s good, no further work is required other than to monitor and ask these questions in the future. If the answers to these questions are “no”, then that’s when road maps and training and coaching need to come into play. And is often the case, fundamentals such as sponsorship can start out strong early in a project but fade during later stages of implementation. When they begin to fail, project success rests on addressing that fundamental gap.

This approach is based on the user experience. Do users experience these critical fundamentals, such as sponsorship, when asked to take on something new? If not, change managers need to work with the project team or leadership, regardless of implementation phase, to shore up the weak fundamentals. This can be done using change tools where appropriate, or other tools that are fitting for that group and their ways of working.

These fundamentals for user adoption can be integrated into waterfall and AGILE projects, without the messiness of combining process steps, setting sequence for change activities, etc. Also, they can integrate very easily into those initiatives where there is no formal project management plan at all.

Over time, my thinking on project and change management has evolved quite a bit. I’ve moved from focusing only on technical changes to learning and loving the people side of change and focusing on those change management methods. Then combining and working through both processes in parallel to finally landing on running a project with a solid project management method and focusing the people aspect of change not on process but on those critical fundamentals that work for users. There is still a lot to explore and learn in this “fundamentals” phase. I really like this approach; it keeps the focus for the people side of change on the user and not on the change management process itself.