Change Management in Projects: Why It's Not Optional
The ERP system went live on schedule. The budget came in under target. The technical team delivered everything in scope. And six months later, half the staff were still using the old spreadsheets. Sound familiar? This is the pattern that haunts technology and process projects across every industry: delivery success paired with adoption failure. The culprit is almost always the same — the organisation invested in project management but neglected change management.
The Distinction That Matters
Project management and change management are distinct disciplines that work on the same initiative from different angles. Project management is concerned with delivering a solution: on time, on budget, within scope, and to specification. It manages tasks, schedules, risks, and resources. Change management is concerned with people: ensuring that the individuals who are affected by the change understand it, support it, develop the skills to use it, and ultimately sustain the new way of working after go-live.
Neither discipline is sufficient on its own. A project delivered without change management produces a solution that nobody uses. Change management without project management produces enthusiasm for a future state that never arrives. The two must be integrated — and that integration must start at the beginning of the project, not after the solution is built.
Why Projects Fail Even When Delivered on Time
Research consistently shows that the majority of technology and process transformation projects fail to achieve their intended business outcomes. The failure rarely happens at the technical layer. The system works. The process is sound. The failure happens at the human layer:
People do not understand why the change is happening and default to scepticism.
People understand the why but do not want to change — the new system threatens their expertise, status, or comfort.
People want to change but do not know how to use the new system effectively — training was insufficient or too early.
People were trained and initially used the new system but reverted to old habits when the go-live pressure faded and no reinforcement mechanism kept them on track.
Middle managers, who control day-to-day behaviour, were not engaged and did not model or reinforce the new way of working.
Each of these failure modes is addressable — but only if the project plan includes the activities to address them.
The ADKAR Model
ADKAR is a goal-oriented change management model developed by Prosci that describes the five building blocks an individual must achieve to successfully make a change. It is one of the most widely used models in practice because it is prescriptive: it does not just describe what change looks like, it tells you what to do when someone is stuck.
Awareness — the individual understands why the change is necessary. Building awareness means communicating the case for change clearly and repeatedly from credible sources, directly addressing "what's in it for me?"
Desire — the individual is motivated to support and participate. Desire is personal and is built through genuine engagement, involvement in design decisions, and honest responses to concerns.
Knowledge — the individual knows how to change: what behaviours and skills are required. Knowledge decays when training happens too far from go-live, and one-size-fits-all training rarely sticks.
Ability — the individual can demonstrate the new skills on the job. Knowledge in a training room and ability under live conditions are different things. Ability is built through practice, coaching, and point-of-need support.
Reinforcement — the change is sustained. Without reinforcement, behaviour reverts. Mechanisms include manager accountability, aligned performance metrics, recognition of early adopters, and a structured process for correcting regression.
Integrating Change Management Into Project Planning
Effective change management is not a communications plan bolted on in the final Sprint. It is a parallel workstream that begins at project initiation and runs through to post-implementation. Practically, this means:
Conduct a stakeholder impact assessment early — identify which groups are affected and what their likely starting position is.
Develop a sponsor roadmap — define what you need from executive sponsors and equip them to play that role visibly.
Build a change agent network — identify champions within affected business units as ground-level advocates and peer coaches.
Align training to the project timeline — schedule training close enough to go-live that knowledge is fresh, not months before.
Build reinforcement into the project schedule — plan a structured post-go-live hypercare period (typically 30–90 days) with a defined hand-off to business-as-usual.
Who Is Responsible for Change Management?
On large programmes, a dedicated OCM lead carries primary responsibility. On smaller projects, these responsibilities may sit with the project manager or sponsor — but they must be explicitly assigned. "Everyone is responsible for change management" is functionally equivalent to "no one is responsible." The project manager owns the technical deliverables; the change manager owns stakeholder engagement, communications, training, and reinforcement. The measure of a successful project is not on-time delivery — it is whether the organisation is actually working differently as a result.
XNM Consulting integrates change management into project and programme delivery. Visit our Program and Project Delivery page to learn how we build both the solution and the adoption.