Projects to Journeys: Rethinking Change Management

Most organizations still run change like a construction job. A start date. A finish date. A plan. A budget. A “go-live.” A celebration email. A lessons-learned deck. And then… silence.
 
That model made sense when change was occasional. Today, it’s dangerous. Because when you treat change as a one-time project, you don’t build adoption. You build compliance. You don’t build capability. You build dependency.

And you don’t build resilience. You build fragile results that crack the moment attention moves elsewhere.

This article is a provocation: Stop managing change as a project. Start enabling change as a journey. Because the future belongs to organizations that can change repeatedly, calmly, and reliably; without breaking people, process, or performance.

The Project Myth: “Deliver Once, Then Stabilize"

Project-based change has a comforting storyline:
 
1. Define scope
2. Design solution
3. Train users
4. Launch
5. Stabilize
6. Close

It’s neat. It’s measurable. It fits governance.

But it quietly assumes something that’s no longer true: That the organization will return to a stable “business as usual.”
 
Reality is the opposite. The organization is now a moving highway, not a parked car.
 
New tech. New compliance. New competitors. New customer behaviours. New internal priorities. Your “steady state” is not a destination. It’s a short pause between disruptions.

So, what happens when we run change like a project anyway? We get an output. Not an outcome.
 
We “deliver” the solution, while adoption remains shallow, behaviours remain old, and performance gains remain temporary.

Why One-Time Change Creates Fragile Results:

Fragile results look impressive in a steering committee and disappointing in the field.
 
Here’s why that fragility happens; structurally, not emotionally.

1) You optimize for delivery, not behaviour. Project governance rewards milestones:

a) Requirements signed off
b) UAT completed
c) Training delivered
d) Go-live achieved

But none of these guarantee:

a) Consistent usage
b) Correct usage
c) Sustained usage
d) Improved decision-making
e) Improved performance

So, teams learn a damaging lesson: “Finish the tasks. The behaviour will follow.” It rarely does.

2) Adoption is treated as a phase, not a system. In project thinking, adoption is something you “do” near the end:

a) Training
b) Communications
c) Quick guides
d) Hypercare

That’s not adoption. That’s onboarding.

Real adoption is reinforced by systems:

a) Role clarity
b) Incentives
c) Coaching routines
d) Performance metrics
e) Consequences for non-compliance
f) Peer norms

If those aren’t redesigned, the org snaps back to old ways, quietly and quickly.

3) Capability is outsourced to the change team. In many transformations, the implicit operating model is:

a) Business owns results.
b) PMO owns execution,
c) Change team owns people-side

Which means the organization doesn’t learn to change. It learns to wait for experts to come “do change” to it.

That’s dependency. Not maturity. And dependency collapses when:

a) The project closes
b) The change team rolls off
c) Leadership attention shifts
d) A new priority interrupts

4) The “project end” creates the most predictable failure

The moment the project closes:

a) Reinforcement drops
b) Governance dissolves
c) Measurement fades
d) Leaders move on
e) Managers revert to old targets

So, people conclude: “This was important until it wasn’t.” And next time you announce a change, they listen with polite scepticism.

Not because they “resist change.” Because they learned from you.

5) One-time change ignores the compounding effect. Change isn’t a single wave anymore. It’s overlapping waves. Project-based change handles one wave at a time. But employees' experience:

a) multiple new tools
b) multiple new policies
c) multiple reporting shifts
d) multiple “urgent” initiatives
 
When everything is a project, everything competes, and attention fragments.

The result is not a transformation. It’s organizational fatigue disguised as activity

The Journey Shift: Change as an Organizational Muscle.

A journey mindset starts with a blunt truth: Change is not an event. It’s a capability. And capabilities are built like muscles:

a) Repeated practice
b) Progressive load
c) Good form
d) Recovery
e) Coaching
f) Reinforcement

You don’t build a muscle with one intense workout. You build it through a system of routines.
 
That’s what continuous, capability-based change looks like:

a) The organization can absorb change without chaos.
b) Teams can adopt new ways of working without breakdowns.
c) Managers can coach change as part of daily leadership.
d) Leaders can sponsor change without theatrics.
e) Metrics reveal behaviour shifts early, not months later.
 
Project thinking asks: “How do we deliver this change?

” Journey thinking asks: “How do we build the ability to change repeatedly and sustainably?”

The Four Traps That Keep Organizations Stuck in “Project Change”

Even smart companies stay trapped because the project model is rewarded.
 
Trap 1: “We need certainty before we start”.Journeys don’t wait for perfect information.

They design for learning:

a) Pilot
b) Measure
c) Adapt
d) Scale

Project change tries to design the final state upfront. Journey change builds the state through iteration.

Trap 2: “We communicated it, so we’re done”. Communication creates awareness.

It does not create new habits. Habits are created by:

a) Repetition
b) Accountability
c) Reinforcement
d) Social proof
e) Aligned incentives

Trap 3: “Managers are too busy”.

Managers are always busy.

If they don’t own change reinforcement, nobody does. And when nobody owns reinforcement, adoption becomes a myth.

Trap 4: “We’ll measure benefits later”. Later becomes never. Journey-based change measures early and often:

a) Leading indicators (usage, compliance, quality)
b) Lagging indicators (cost, cycle time, customer outcomes)

If you can’t see behaviour shifting, you can’t steer.

A Practical Framework:

Moving from Projects to Journeys. Here’s a simple way to rethink your approach.

1) Redefine success: “capability + outcome” Don’t just ask:

a) Did we implement?
 
Ask:
a) Did we build the ability to sustain and evolve?
b) Can we repeat this change pattern elsewhere with less pain?

A good test: If the change team leaves tomorrow, will the change survive?

2) Build a “change operating system”. You don’t need more change activity. You need an operating system that includes:

•governance that stays beyond go-live
•role-based adoption metrics
•reinforcement routines for managers
•continuous learning assets (not one-time training)
•a feedback loop that updates process / tools based on reality

3) Shift from training events to learning journeys. Replace “one-and-done training” with:

•Short modules
•In-the-flow job aids
•Scenario practice
•Role-based simulations
•Refreshers at 30 / 60 / 90 days
•Manager-led coaching moments

People don’t forget because they’re careless. They forget because your system assumes memory equals mastery.

4) Make reinforcement visible and routine. Define reinforcement as a checklist, not an intention:

•weekly manager check-ins (10 minutes)
•adoption dashboard review (per team)
•quality spot checks
recognition for correct behaviours
•escalation path for non-adoption

Reinforcement isn’t a soft concept. It’s operational discipline.

5) Institutionalize “change fitness”. Create capability markers like:

•how fast teams can adopt a new SOP
•how quickly errors stabilize after a tool change
•how reliably managers run reinforcement loops
•how many internal champions can lead adoption
•how quickly feedback is converted into improved design

This is what organizational muscle looks like.

What Leaders Must Stop Saying; If you want journeys, not projects, leaders must retire these phrases:

•“We’re done now.”
•“This is the last change for a while.”
•“Just push it out; adoption will happen.”
•“Training is completed, so users are ready.”
•“We’ve communicated it enough.”

 These statements train the organization to treat change as temporary noise.

Instead, leaders need to normalize the truth:We are building how we work; not implementing something new.

The Real Promise of Journey-Based Change. This isn’t about being modern.

It’s about being survivable. Organizations that treat change as a journey get:

•less fatigue (because change becomes predictable)
•faster adoption (because capability compounds)
•fewer failures (because reinforcement is built-in)
•better ROI (because behaviours stick)
•stronger culture (because learning becomes normal)

Most importantly: They stop gambling on heroic transformations. They start building steady, repeatable progress.

Closing Insight: Your Change Results Are Only as Strong as Your Reinforcement System

Treat change like a project and you’ll get project outcomes:

•Implementation success
•Adoption uncertainty
•Benefits drift
•Fragile gains

Treat change like a journey and you’ll get capability outcomes:

a) Repeatability
b) Resilience
c) Compounding performance
•Real behavioural shift. Change is not something you finish.

Change is something you become good at. And in the next decade, that will be the only competitive advantage that doesn’t expire.