If there is one thing every project has in common, it is change… that is either a result of the project itself or the requirements to build the result!
Projects exist because something needs to be different than it is today. This is because a process is being improved or an active system requires replacement. Regardless of the specific objective for a project, the entire purpose of a project is to move people, processes, and technology from a current state (point A) to a future state (point Z).
Yet despite this reality, change management is often treated as a secondary activity rather than a core project leadership responsibility. I have even noticed and experienced fears and trepidation around managing change… because change is difficult by nature.
- Schedules get detailed attention
- Budgets are reviewed endlessly
- Risks are documented and tracked
- Resources are negotiated and assigned
That all said, the people expected to adopt the change are sometimes informed only after decisions have already been made. That approach rarely ends well as stakeholders should be engaged from day one (point A).
In this installment of Project Leadership Unlocked series of blogs, I want to explore why change management matters, why resistance is often misunderstood, and what project leaders can do to create commitment instead of compliance.
Change is not the Project, Adoption is
One of the most common fallacies that I have noticed in project leadership is believing that project completion equals project success. It simply does not mean only that… A project can be delivered on time, on budget, and within scope while still failing to achieve its intended outcome.
Why is this? Because successful implementation is not the same thing as successful adoption.
- A new application that nobody uses creates no value for the organization or customer.
- A redesigned process that employees purposely work around creates no value as well.
- A reporting solution that leadership ignores creates no value.
The real measure of project success is whether the intended change gets adopted fully and becomes part of daily operations. This concept builds directly upon ideas discussed in my blog Operationalizing the Future, where I explored the importance of ensuring that project outcomes become sustainable operational realities rather than simply completed deliverables.
Projects create change. Organizations realize value through adoption. The bridge between those two realities is change management
Resistance Is Usually a Signal, Not an Obstacle
One of the greatest shifts in my own thinking over the years has been how I view resistance. Many project teams see resistance as something negative. I increasingly see it as valuable information. When stakeholders push back, ask questions, hesitate, or challenge assumptions, they are often revealing valuable insights that would otherwise remain hidden.
- Sometimes they are identifying risks.
- Sometimes they are identifying missing requirements.
- Sometimes they are highlighting operational realities the project team does not fully understand.
This aligns closely with a point I made in Stakeholders Want to Be Heard, Include Them in Discovery. People generally do not resist because they enjoy creating problems. More often, they resist because they feel unheard, uninformed, or excluded from decisions that directly affect them.
When project leaders stop viewing resistance as opposition and start viewing it as feedback, conversations become significantly more productive. The goal is not to eliminate resistance, it is to understand it.
Communication Alone Is Not Change Management
Many organizations attempt to manage change by sending communications, basically providing a bunch of information. While communication is essential, communication by itself does not create alignment.
Informing people that a change is coming is not the same as helping them understand why it matters or how to work within it. Successful project leaders must communicate beyond timelines, milestones, and go-live dates.
They must answer questions such as:
- Why are we making this change?
- What problem are we solving?
- How will this improve the current situation?
- What will be different for me?
- What support will be available?
- What happens if we do nothing?
As I discussed in What Do Project Leaders Do? We Communicate and Translate, project leadership often requires translating between audiences. Executive sponsors, functional managers, technical teams, and end users each view projects through different lenses.
An effective change leader understands those perspectives and adapts messaging accordingly.
Communication is not simply sending information.
It is creating understanding between the generator and receiver of the messaging.
Start Change Management Earlier Than You Think
One of the biggest mistakes that I have experienced is when teams wait until testing, deployment, or go-live to begin change management activities. By then, opinions have already formed and concerns have already spread like oil on water.
Change Management Begins During Discovery
- It begins when stakeholders are invited to participate.
- It begins when leaders seek input before making decisions.
- It begins when future users see themselves reflected in the solution being designed.
This is one of the reasons stakeholder engagement is so critical. It is because, when people contribute to a solution, they become invested in its success. Then when they feel excluded, they often become skeptical of the outcome and detach themselves from the result. The earlier people are involved, the greater the likelihood they will support what is ultimately delivered.
Practical Steps for Project Leaders
While every organization approaches change differently, I have found the following practices consistently improve outcomes.
Identify Impacted Groups Early by mapping out who will be affected by the project. Do not stop at executive sponsors while considering operational users, support teams, reporting teams, downstream departments, and external partners. Understanding who is impacted is the foundation for every change management activity that follows.
Build a Change Network
Identify influential individuals within affected groups. These individuals often become trusted voices who help reinforce messages, answer questions, and provide feedback from their areas. I suggest that you include trusted peers more than project just the project teams.
Create Feedback Loops
Change management should never be one-directional. Create opportunities for questions, workshops, demonstrations, surveys, and open discussions witch propagates the feedback loop. As you have most likely heard, listening is often more important than presenting which applies well here.
Adoption and Training Matters
Training should focus on practical application and replicate actual scenarios as best as possible. Show people how their jobs will advance and benefit from the change.
- Demonstrate new workflows: Provide examples that reflect real daily activities rather than hypothetical scenarios.
- Celebrate adoption: Many teams celebrate project completion, while few celebrate successful adoption of the change.
- Recognize adopters: Distinguish individuals and teams from the rest of the crowd that embrace the change and help others to succeed within it.
- Positive reinforcement: Constructive language and motivation can accelerate acceptance far more effectively than mandates and requirements do.
The Leadership Challenge
At its core, change management is not a process challenge, it is a project leadership challenge. Schedules, budgets, and deliverables are important, but they only tell part of the story. The more difficult task is helping people navigate uncertainty and resistance.
Project leaders must balance competing priorities, communicate a compelling vision, listen to concerns, address fears, and maintain momentum even when enthusiasm varies across stakeholder groups.
- That work is often invisible: It is also where some of the most important leadership occurs.
Maintain a Change Management Log
One practice that has consistently helped me on projects is maintaining a dedicated Change Management Log. While risks, issues, and decisions often receive formal tracking, stakeholder concerns and adoption challenges can easily become scattered across meeting notes, emails, and hallway conversations.
A Change Management Log creates a centralized place to capture any of the following that arise.
- Stakeholder concerns and objections
- Frequently asked questions and their answers
- Adoption risks and barriers
- Training needs
- Communication requirements
- Feedback received during demos, workshops, or testing
The value of the log is not simply documenting resistance; it is documenting how the project team responds to it. Each entry should include an owner, planned action, target date, and current status built in a table format. I typically do this within a SharePoint List in Microsoft Teams, though an Excel file works nearly as good.
What is a SharePoint List: https://support.microsoft.com/en-us/teams/platform/get-started-with-lists-in-teams
Log Management and Review
Most importantly, the log should be reviewed throughout the entire project lifecycle, not just before at kick-off and go-live. A concern raised during discovery may reappear during testing, training, or go-live if it has not been fully addressed then that lack of attention is a clear miss the project leader.
By treating change-related feedback with the same discipline applied to risks and issues, project leaders can identify trends early, adjust engagement strategies, and prevent small concerns from becoming major adoption obstacles. In many ways, a well-maintained Change Management Log becomes the project’s pulse check on organizational readiness.
A Brief Geeky Aside: Resistance Is Futile… Or Is It?
As a fan of science fiction, I cannot help but smile whenever I hear the phrase “Resistance is futile.” Most people immediately think of the Borg from Star Trek. In Star Wars, the original trilogy is literally built around a group called the Rebel Alliance whose primary purpose is resisting change imposed by the Empire. The Empire believed compliance could be mandated. The Rebels demonstrated that people support change far more readily when they believe in the cause.
Project leaders occasionally fall into this same trap of resistance to change. We roll out a new process, send an email, schedule training, and secretly hope everyone will simply assimilate into the new reality by Monday morning. Unfortunately, stakeholders are not drones, and organizations are not hive minds.
The Lesson is Simple Though
When stakeholders resist, they are usually telling us something important. Unlike the Borg, project leaders rarely succeed through forced assimilation. Success comes from listening, understanding concerns, building trust, and helping people see themselves in the future state. Besides, if “resistance is futile” were actually true, there would have been no Rebel Alliance, no destruction of the Death Star, and a lot fewer project status meetings.
Final Thoughts
Every project changes something and the question is whether the organization is prepared to embrace that change, or not. I also believe that most successful project leaders understand that delivering the solution is only part of the journey. The greater responsibility is helping people move with confidence from the current state to the future state.
Technology can be deployed in a day, and processes can be documented in a week. That said, adoption, trust, and confidence take longer than that. That is why change management is not an optional project activity. It is one of the most critical leadership responsibilities we have because in the end, projects do not succeed when systems go live. They succeed when people move forward and adopt the change.