Change · 10 min read
Change Management: Why Good Projects Fail at the People Part
The system works, the plan was perfect, and nobody uses it. Change management closes the gap between delivered and adopted.
Dennis AlejoBusiness consultant · Project & operations manager · · 2,225 words
A company spends months building a new system. It is delivered on time and within budget, the technical team celebrates and the project is formally closed. Three months later, a quick look shows that half the staff still use their old spreadsheets, the new system is filled with incomplete data and the managers who were supposed to benefit are quietly annoyed. The project succeeded on paper and failed in reality. If you have been around organizations for any length of time, you have seen some version of this story, and probably more than once.
The cause is rarely the technology. It is that the project treated the change as a technical delivery when it was really a human one. Change management is the discipline of closing the gap between "delivered" and "adopted." It is sometimes dismissed as soft, but the numbers behind a project are only as good as the number of people who change what they do on Monday morning. This article explains the people side of projects in plain language: why people resist, two useful frameworks, a practical approach you can apply this month and how to measure whether the change really happened.
Delivered is not adopted
Project managers are trained to talk about outputs: the system, the building, the process document. But organizations pay for outcomes: faster approvals, fewer errors, happier customers, lower costs. Between an output and an outcome sits a bridge made of human behavior. A new tool produces no benefit until people use it correctly. A new process saves no time until people follow it.
This is why I like to define a project as complete only when the benefit shows up, a topic I explore in benefits realization. When I was building a platform to track sixteen projects across three owners, the technical part was the easier half. The harder half was getting everyone to enter and update information in one place instead of in their own notes, and that required explaining why, showing what was in it for them and making it easier than the old way. Technology made the change possible. People made it real.
Why people resist, and why it is usually reasonable
"Resistance to change" is often used as a polite way to say "people are difficult." In practice, resistance almost always has a reason, and the reason is often sensible from the person's point of view. Here are the most common ones.
Loss. People may lose status, control, a skill they were proud of or a comfortable routine. The expert in the old system becomes a beginner in the new one.
Uncertainty. Not knowing what will happen is more stressful than a known difficulty. Rumors fill the gap that information leaves.
Extra work. Change usually adds effort before it removes any. During the transition people carry two ways of working at once.
Past experience. If previous changes were announced with enthusiasm and quietly abandoned, people reasonably wait to see whether this one is real.
Not being asked. A change done to people produces less commitment than a change done with them. People who had no say often feel they have no stake.
Genuine objections. Sometimes people resist because they see a real flaw that the planners missed. Dismissing this as resistance wastes valuable information.
Seeing resistance as information changes your response. Instead of asking "how do I overcome this?" you ask "what is this telling me?" That shift alone often turns critics into collaborators. It connects closely with stakeholder mapping, where the first step is understanding what each person wants and fears.
Two frameworks in plain English
Many frameworks exist for managing change. Two are widely used and worth knowing, because they describe the same thing from different angles.
Kotter's eight steps come from the work of Harvard professor John Kotter. In plain terms they say: create a sense of urgency about why change is needed; build a guiding team of influential people; form a clear vision of the future; communicate that vision repeatedly; remove obstacles and empower people to act; generate short-term wins that prove progress; keep momentum and build on the gains; and finally anchor the new approach in the culture so it sticks. Its strength is the sequence: urgency and vision before announcements, wins before declaring victory.
ADKAR is a model developed by Prosci that looks at change from the individual's point of view. It stands for Awareness of why the change is needed, Desire to participate and support it, Knowledge of how to change, Ability to implement the new skills in practice and Reinforcement to sustain the change. (ADKAR is a registered mark of Prosci Inc.; this article is independent.) The model is useful as a diagnostic: when a change stalls, ask which of the five is missing for the people involved. A team that knows why and how but does not want to change needs a different response than a team that wants to change but has not practiced the new skill.
If you strip both down to what a team can use this week, you get four questions every affected person asks, even if they never say them aloud: Why are we doing this? What changes for me? Can I do it? Will it stick? The rest of this article follows those four questions.
Why: build the case for change
A good case for change is concrete, honest and about people, not only about the organization. "We are implementing a new system to improve operational efficiency" says nothing. "Right now, approving an internship takes weeks because the information is in four places. With the new system a request takes days, and you stop retyping the same data" says something that people can picture.
Avoid two traps. The first is manufacturing a crisis that does not exist, which people can smell. The second is selling only the benefits for the company while ignoring the cost for the individual. Tell the truth about the effort, the timeline and what will be hard. People trust a leader who acknowledges the difficulty more than one who promises it will be painless.
Give the case more than one voice. A message from the top matters, but the one that persuades is often from a peer: someone who tried the new way in a pilot and says, "It took me a while, but now I save an hour a day."
What changes for me: involve the people who live with it
The fastest way to build commitment is to involve the people affected in designing the change. This does not mean decision by committee. It means asking the people who do the work what would make the new way work, inviting a few of them into the project team, and showing visible changes made because of their input.
Two practices help. First, create a group of change champions: respected people from different teams who understand the change deeply, answer colleagues' questions and bring problems back to the project. Champions are more effective when they are chosen for credibility with their peers, not just for enthusiasm. Second, speak directly with the groups most affected, and ask the question from the stakeholder article: "What would make this a success for you, and what worries you?" Then act on at least one thing you hear and tell people you did.
Use the check below to see how ready your own team is for a change you are planning. Tick only what is already true.
Can I do it: train for ability, not awareness
A frequent mistake is to confuse announcing with training. A thirty-minute presentation creates awareness. It does not create ability. Ability comes from practice: doing the real task with the new tool, making mistakes in a safe place and getting help right when needed.
Good training for a change has several features. It is hands-on and based on the real tasks people do, not on a tour of features. It is timed close to when people will use it, because skills that are not used fade. It includes job aids, like one-page guides and short videos, that people can use at the moment of need. And it provides support after go-live, such as floor-walkers or a quick-response channel, because the first two weeks are when people decide whether the new way is worth it.
Give people time. If a new process takes longer at first, adjust the expectations and the targets for a few weeks. Penalizing people for being slow while they learn is the quickest way to make them go back to the old method.
Pilot first
Large launches are tempting, because they are efficient on paper. But a pilot with a small, willing group almost always pays for itself. You find the practical problems, such as an unclear step or a missing field, while the audience is small and forgiving. You build a group of experienced users who become champions. And you produce evidence, real stories from real colleagues, that the change works.
A good pilot has a defined scope, a start and an end date, clear success criteria and a plan for what happens afterward. Treat the end as a decision point: adopt, adjust or stop. I use the same logic in my 90-day sprint, where a short experiment with a scoreboard replaces long speculation. And it echoes the idea of continuous, small improvement that is central to the Japanese tradition of kaizen, a theme I am exploring in the book project Kaizen vs. Gantt.
Will it stick: make the new way the easy way
People follow the path of least resistance. If the old way is still available and easier, they will use it, however good the training was. To make a change stick, make the new way easier than the old and, where it makes sense, retire the old one. Close the old spreadsheet, redirect the old form, and make the new tool the only place where an approval counts.
Reinforce with visible attention. Leaders who ask for the numbers from the new system, and not from the old one, send a clear message. Recognize people who adopt early, celebrate small wins and share the results. And be ready to adjust: if many people struggle with the same step, the process is probably wrong, not the people.
Measure adoption, not go-live
Go-live is an event. Adoption is a result, and it needs its own measures. Choose a few that fit the change: the share of people actively using the new tool each week, the time it takes to complete the key task compared with before, the number of errors or rework items, the volume of support questions and a simple pulse check on confidence. Track them weekly during the first months and share them openly with the team.
If adoption is low, treat the number as a diagnosis. Use ADKAR as a checklist: do people not know why, not want it, not know how or not have the chance to practice? Each answer points to a different fix. This is the same spirit as the approach in data-driven project management: a small set of numbers that lead to decisions.
Different kinds of change
The approach flexes with the type of change. A software rollout, like moving learners and staff onto a new platform, depends heavily on training and on retiring the old tool, as I describe in education companies need better processes. A process automation change succeeds when the people whose tasks are automated see what they will do with the time, which is why I frame automation as freeing people for thinking and relationships in seven workflows to run on autopilot. A method change in a tech team, such as adopting Scrum, needs patience and visible leadership, as discussed in shipping SaaS without chaos. An opening or relocation requires staff to be trained and rehearsed before day one. And a cultural change, like a new approach to accountability, takes the longest, because it is made of many small behaviors repeated until they become normal.
A helpful quick test is to consider two things: how much the change alters daily work, and how many people it touches. A small change for a few people needs light communication. A deep change for many people needs the full approach above, with champions, pilots and careful measurement.
What leaders can do
Leaders set the tone for any change. They can explain why in plain words and repeat it more often than feels necessary. They can use the new way themselves, visibly. They can listen to criticism without defending, and respond to it. They can protect time for learning. And they can resist the temptation to declare victory at go-live. A sponsor who stays engaged through adoption makes the difference, which is why I wrote about keeping an executive sponsor engaged.
Remember that communication is the glue of the whole process, and it needs planning, not improvisation. The communication plan people actually read shows how to build one.
Change management is not about manipulating people into accepting something. It is about respecting them enough to explain, involve, train and listen. If you are planning a change and would like help designing it, that is part of my scaling strategy work and of Project Focus.
Which change at your workplace stuck, and what do you think made the difference? Tell me in the comments.
Frequently asked questions
What is change management in project management?
It is the discipline of helping people adopt what a project delivers, such as a new system, process or way of working. It covers explaining why, involving those affected, training for real ability, piloting and reinforcing the new behavior, then measuring whether it actually happened.
Why do people resist change?
Common reasons are fear of loss, uncertainty, extra work during the transition, past changes that were abandoned, not being asked and genuine objections that planners missed. Resistance usually carries useful information.
What is the difference between Kotter's steps and ADKAR?
Kotter's eight steps describe what an organization should do, from creating urgency to anchoring the change in the culture. ADKAR looks at what each individual needs: awareness, desire, knowledge, ability and reinforcement. They complement each other.
How do I measure whether a change was adopted?
Track weekly usage, how long the key task takes compared with before, errors or rework, support questions and a simple confidence check, and treat low numbers as a diagnosis of what is missing.
Join the conversation
Did this help? A quick reaction tells me what to write next.
Be the first to react.
Loading comments…