What is the change management process?

The change management process is the set of activities used to help an organization and its people move from a current way of working to a new one. That change may involve processes, tools, responsibilities, organizational structures, behaviors, or even company culture.

We often talk about change as if it were simply a matter of announcing a new rule. In practice, organizational change can modify what someone does every day, who they interact with, which decisions they are allowed to make, how their performance is evaluated, and which skills they need to do their job.

This is why even a relatively small process change can create much more resistance than expected.

Why is changing a process so difficult?

A process can perform poorly for many reasons. People may be tired, inexperienced, disengaged, or dealing with behavioral problems. But the problem may also exist in the design of the process itself.

I like an idea Don Norman discusses in The Design of Everyday Things: when many people repeatedly make the same mistake within a system, perhaps the problem is not only the people. Something in the design may be leading them toward the error.

Processes are also a form of design. If an activity is constantly forgotten, if an approval is always delayed, or if almost everyone struggles with the same step, before deciding that “people are doing it wrong,” it is worth asking whether the process was designed correctly in the first place.

Understand what is wrong before changing the process

One of the most common mistakes in process improvement is starting directly with the solution. Someone identifies a problem and immediately proposes something: automate it, replace the tool, add another approval, reorganize the team, or create a new rule.

But if we do not understand the cause of the problem, we may simply make a bad process even more complicated.

Before redesigning anything, I prefer to ask a very simple question: why is this problem happening?

If there is rework, we need to understand where it comes from. If one step takes too long, we need to identify the bottleneck. If people ignore a procedure, we need to discover whether it is unclear, bureaucratic, unknown, or simply incompatible with the reality of the work.

Tools such as the Fishbone Diagram and the 5 Whys can help significantly with this kind of investigation. I explain this process in: Fishbone Diagram: What It Is, How to Create One, and Find the Root Cause of a Problem .

Map the current process before redesigning it

Before proposing a new workflow, we need to understand how the current process actually works. And there is an important difference between the official process and the real process.

The documentation may say that a request goes through three steps. In practice, there may also be a WhatsApp conversation, a parallel spreadsheet, an informal approval, or someone who always needs to “take a quick look” before the work can move forward.

This is why process mapping should not be limited to asking how a process is supposed to work. We need to discover how it really works.

Talk to the people who execute the activities, observe the workflow, and identify exceptions, dependencies, approvals, rework, waiting time, and informal decisions. Very often, the biggest problems do not appear in the official diagram precisely because they emerged after that diagram was created.

Process improvement does not end with a new workflow

This is where we reach the real reason I started this article. Designing a new process can be relatively easy. Getting people to actually use it is a completely different problem.

We can bring the right people together, open Miro, remove unnecessary steps, create automations, define responsibilities, and leave the meeting convinced that the problem has been solved.

But the next morning, everyone returns to their normal routine.

And this is when we discover that process improvement is not only a process problem. It is also a behavior change problem.

Change management and human habits

Human beings operate largely through habits. After repeating an activity dozens or hundreds of times, we stop consciously thinking about every step. We simply know how to do it.

When someone joins a company, they usually go through a path similar to this:

• They learn about the company and its processes.
• They ask questions and receive help.
• They make some mistakes while learning.
• They begin to understand exceptions and particular situations.
• They gain confidence.
• They begin executing activities almost automatically.
• Eventually, they become a reference for that process.

Now imagine asking that same person to relearn an important part of their job. Suddenly, something they used to do automatically requires attention again. Questions appear. Mistakes may happen. They may need to ask for help with activities they completely understood until yesterday.

This is where an important part of the change management process really begins.

Why does resistance to change happen?

It is easy to interpret all resistance to change as unwillingness. In reality, there are many different reasons why someone may resist a change.

They may not understand why the change is happening. They may believe the new process will increase their workload. They may feel insecure about their ability to learn it. They may have lost autonomy, received insufficient training, or simply believe that what is being presented as an improvement does not actually improve anything for the people doing the work.

There is also a less visible form of resistance: someone says they have adopted the new process but continues using the old one whenever possible.

For me, this is one of the most difficult situations for a manager because, officially, the new process exists. In practice, however, two different organizations begin operating at the same time: the one described in the procedures and the one that actually does the work.

How to reduce resistance to change

If someone is not following the new process, before concluding that they simply “do not want to change,” I would try to answer a few questions.

Did they receive proper training? Is the process sufficiently clear? Do the necessary tools work? Do incentives still reward the old behavior? Are managers themselves following the new process? Is there enough time to learn? Does the new process actually work better?

Sometimes resistance is useful information. It may be pointing to a problem that was not identified during the redesign.

In other cases, however, everything has already been explained, trained, adjusted, and validated, and someone still deliberately ignores the new model or actively works against the change. At that point, the situation is no longer only about adaptation. It becomes an issue of professional alignment and management.

The distinction matters: we should not automatically turn a process problem into a people problem, but we should not turn every behavioral problem into a process problem either.

How to communicate organizational change

Good change communication should clearly answer a few questions: what is changing, why it is changing, when it will happen, who will be affected, and what we expect to improve.

Simply announcing that “starting Monday, we will have a new process” is rarely enough.

People need to understand the problem we are trying to solve. If we are trying to reduce rework, show where that rework occurs. If the goal is to reduce costs, explain where those costs are coming from. If there is a risk, make that risk visible.

The more the change feels like an arbitrary decision made by someone far removed from the real work, the greater the resistance is likely to be.

This is why organizational communication and internal communication should not happen only when the change is announced. Communication needs to continue throughout implementation, especially when questions, mistakes, and unexpected exceptions begin to appear.

Stakeholders: who should be involved in the change?

When we redesign a process, almost everyone may have an opinion. The problem is that trying to negotiate every detail with every person can turn a relatively simple improvement into an endless initiative.

We need to understand who truly influences the decision, who executes the process, who will be affected, who holds critical knowledge, and who simply needs to be informed.

This does not mean ignoring people. It means recognizing that different stakeholders have different levels of influence, interest, and responsibility during organizational change.

I explain this process in more detail in: Stakeholder Mapping: How to Identify, Analyze, and Manage Project Stakeholders .

Why leadership support is critical

Significant changes almost always create conflicts of priority. One team wants to move forward while another believes it is not the right time. One manager supports the change while another prefers to keep the existing process. Some people want to expand the scope while others want to reduce it.

If the change is genuinely important to the organization, someone needs to have enough authority to remove roadblocks and sustain the decisions that have been made.

This does not mean forcing everything through. Negotiation is still essential. But there is a major difference between listening to stakeholders and allowing anyone to reopen the entire discussion indefinitely.

Without real leadership support, many organizational change initiatives gradually lose momentum until everyone quietly returns to the old way of working.

How to measure change adoption

A change does not end when the new procedure is published. We need to verify whether what we planned is actually happening.

A few questions can help:

• Are people actually using the new workflow?
• Has execution time really decreased?
• Has rework been reduced?
• Are there fewer errors?
• Have waiting times decreased?
• Have costs gone down?
• Have new bottlenecks appeared?
• Have people created parallel paths to avoid the official process?

This is where change adoption becomes much more useful than simply measuring whether people attended a training session or received a new document.

A new process should not be considered successful because it was launched. It should be considered successful because people adopted it and it produced better results.

How to use data to evaluate process improvement

In technology projects, a large part of the work already leaves data behind in tools such as Jira, Azure DevOps, Asana, Monday.com, and ClickUp. This information can help us understand whether a process change actually produced an improvement.

We can compare, for example, execution time before and after the change, volume of completed activities, rework, bugs, estimates, hours consumed, costs, sprint performance, and concentration of work across specific people or teams.

This is where Saint Jude Project Intelligence can support the analysis. Instead of relying only on the perception that “the process seems better,” teams can use execution data to understand whether productivity, costs, schedules, quality, and risks actually changed.

This can also expose a very common situation: a process that became much more organized in the presentation but did not improve the actual outcome.

The change management process is also process management

In the end, I believe there is a huge difference between designing a better process and making an organization work in a better way.

The first can sometimes be completed in a few meetings. The second involves people, habits, tools, incentives, communication, leadership, data, and time.

That is why, whenever someone tells me they will “simply redesign the process,” I already know that the drawing will probably be the easiest part.

The real work starts afterward.

Because processes do not change when the boxes and arrows change.

Processes change when the way people work changes too.

See you soon!

Erik Scaranello