Most organisations know they need change management. The problem isn't the decision — it's the timing. By the time the change manager is hired, onboarded, and up to speed, the project is already in trouble.
Here's the pattern I see repeatedly. A CIO kicks off a significant technology transformation. The project team is assembled: programme manager, business analysts, developers, a solutions architect. Change is on the list — someone will sort it. Six weeks in, the team is deep in design. Decisions are being made that will directly affect how people work. Nobody with a change lens is in the room.
Three months later, the organisation finally starts a recruitment process for a change lead. It takes another two to three months to find the right person. They start four months after go-live decisions were already made. They spend their first weeks catching up on what happened in design and trying to unpick commitments that should never have been made without a people lens on them.
This is not a hypothetical. This is Tuesday.
When change risk actually peaks
Change risk doesn't peak at go-live. That's a common misconception — the assumption that change is a pre-launch activity, something you ramp up in the final weeks before the system goes live.
The reality is the opposite. Change risk peaks in design and build. That's when the decisions are made that determine how different people's jobs will be, which processes are being eliminated, which teams are most exposed, and what the resistance landscape looks like. Get those decisions wrong — or make them without considering the human impact — and no amount of training or communications in the weeks before go-live will fix it.
The window that matters most — kick-off through build — is exactly the window that a 3–6 month hiring process guarantees you'll miss.
What gets missed in that window
It's worth being specific about what happens when change expertise is absent during design and build. This is the period when:
Why the traditional hiring model doesn't fit
The standard response to a change capability gap is to hire someone. And for a large, long-running programme where the organisation needs to build internal capability, that might be right. But the hiring process is fundamentally mismatched with the project lifecycle.
Change risk doesn't wait for HR to finish a search. It starts the day the project does.
A 3–6 month search, followed by 1–2 months of notice period, followed by a month of onboarding means you're at month 7 or 8 before that person is genuinely effective. On a 12-month project, you've missed more than half of it.
Day-rate contractors solve the speed problem but create a different one: they're optimised for output, not for the embedded, relationship-driven work that actually moves organisations. And when the contract ends, the knowledge walks out the door.
What the fractional model solves
A fractional change manager combines the speed of a contractor with the embedded nature of a permanent hire. They can start in days. They operate with a senior lens, having seen this pattern across multiple industries and programme types. And because they're engaged on a structured, ongoing basis rather than a day rate, they're invested in outcomes — not hours.
For a CIO, this means change expertise is present from the first design workshop. It means you have someone with authority and experience in the room when decisions are made that will determine whether people adopt the system. It means resistance is identified early, when it can still be shaped — not late, when it's entrenched.
Speed to deployment matters as much as expertise. Both need to be true at the same time. The fractional model is the only arrangement that delivers both.
The question worth asking now
If you have a technology project in flight — or one about to kick off — the question isn't whether you need change management. You know you do. The question is whether the model you're planning to use will get you the right expertise at the right time.
If the answer involves a hiring process, you already know what happens next.
