On Change Management

Change management in a software rollout is the work you do around the code to get it adopted: readiness, training, a pilot, a phased go-live, and real support after launch. It's what turns working software into software people actually use.

Every technology team knows the feeling. The product is built. The demos went well. Someone sends the message everyone's been waiting for: "We're ready to go live." Two weeks later, the wheels wobble. Nobody staffed the support queue. Users are ignoring the features the team was proudest of. Some stakeholder you forgot to loop in is hearing about the change from a frustrated customer.

Projects with excellent change management are about six times more likely to meet their objectives than those without.

— Prosci Benchmarking Research

Industry research has long put the failure rate of large-scale organizational change efforts at roughly 70% (McKinsey). What gets missed is everything around the code: the communication, training, monitoring, phased rollout, readiness gates, and the long tail of post-launch work that determines whether the thing gets used.

The code is rarely the problem.

Most product and engineering teams are excellent at building. They're worse at launching. In the rush to ship, tasks get deferred, dumped on someone who is already overloaded, or quietly dropped. Here are the ones we see slip on almost every rollout:

• A support queue no one staffed for launch week
• "All" or "TBD" listed as the owner for critical tasks
• Training materials never validated with a real user
• No phased wave plan — everyone goes at once
• CAB routing, security sign-offs, or regulator comms started too late
• Success criteria for pilot that were never written down
• A retrospective that never gets scheduled, and so never happens

None of these are glamorous. None are the work engineers got into the job to do. But each one, when missed, creates the friction users remember long after a clean release has faded.

A launch isn't a day. It's five phases.

A launch is not a date on the calendar. It's a sequence of phases, and change management is what connects them. When we build rollout plans with clients, we anchor to five of them, and we insist every phase has its own gate, owner, and deliverables.

Go-live is the middle of the work, not the end. Readiness and enablement come before it. Pilot validates it. Post-launch determines whether it sticks. Teams that collapse all this into "build, then launch" always underestimate the effort on either side.

Ninety line items. Half of them aren't code.

Consider an anonymized rollout we supported for a healthcare technology platform — a next-generation portal rolled out to a network of non-emergency medical transportation (NEMT) providers inside a CMS-regulated program. On paper, it looked like a normal release. In practice, the plan had more than ninety discrete line items organized across readiness, pilot, go-live, and post-launch.

A small sample of what the team tracked:

• Standing up production environments and confirming AWS/GCP readiness, separate from the application itself
• Staging master data in both UAT and production, and validating that test transactional data had been cleared before real users touched the system
• Deploying infrastructure monitoring (CloudWatch/Datadog) and wiring it to an on-call paging rotation so alerts reached a human
• Routing Change Advisory Board approvals across multiple internal systems before any production deployment
• Completing both infrastructure and application security audits, with named owners and written sign-offs
• Drafting external messaging to a regulator for approval, not just to end users
• Creating training videos, release notes, and FAQs — and verifying the training team could actually use them
• Building a three-wave launch sequence (pilot, second cohort, full rollout), each with its own go/no-go notification
• Scheduling daily issue-review calls, a feedback survey, and a retrospective before the team disbanded

We've seen the same pattern on a second rollout in the same industry, with a different client — the plan again ran north of eighty tasks, nearly half unrelated to writing code. Complex software meets complex organizations. The surface area of a real rollout is always larger than the team expects.

Skip the prep. Pay it anyway.

Treat change management as optional and the cost doesn't disappear. It just moves. It shows up as a spike in support tickets nobody forecasted. As a pilot that drags on for weeks because nobody defined "success." As a stakeholder who hears about a change from a customer instead of from you, and spends the next quarter skeptical of everything you ship. Gartner calls this "change fatigue," and once it sets in, every subsequent launch is harder. None of it hits the budget. All of it is bigger than the prep would have cost.

There's a second cost that’s harder to see: morale. Engineers who spent months building something deserve to watch it land well. A rough rollout is demoralizing in a specific way - the kind of energy drain that bleeds into the next release. Good change management is a gift to the team that shipped the product, not just to the people who will use it.

What successful launch teams do differently.

Across dozens of rollouts, the teams that consistently launch software share a few habits that don’t have much to do with the technology.

• They write the rollout plan before they finish the product, not after. The plan shapes the product, not the other way around.
• They name an owner for every task. "All" or "TBD" is a red flag. Shared ownership is unowned ownership.
• They stage go-live in waves. Three providers before ten. Ten before forty. Every wave is a cheap insurance policy against an expensive surprise.
• They build explicit go/no-go gates, and they're willing to say no. A gate that cannot stop a launch is not a gate. It is a ceremony.
• They schedule the retrospective before the launch, not after. Putting it on the calendar early is how teams actually learn between releases.

The last ten percent.

Great software is necessary. It isn’t sufficient. The teams that turn working software into something the business relies on are the ones that take change management seriously — treating readiness, enablement, pilot, launch, and post-launch as five distinct jobs, each with its own real work. It's not glamorous work. It rarely shows up in a demo. And it’s usually the difference between success and failure.

This is the work we do: readiness plans, wave sequencing, go/no-go calls with teeth. The last ten percent — the part that matters most — done well.

Planning a software launch in the next two quarters? Talk to us about your rollout plan. We'd be glad to give you a second set of eyes.

Frequently asked questions

What is change management in a software rollout?

Change management in a software rollout is the structured work of preparing people, processes, and systems to adopt a new technology. It spans pre-launch readiness, user enablement and training, pilot validation, phased go-live, and post-launch support — and it is the discipline most responsible for whether a working product actually gets adopted.

What are the five phases of a software rollout?

Readiness, enablement, pilot, go-live, and post-launch. Readiness confirms that environments, monitoring, and security sign-offs are in place. Enablement delivers training and documentation. Pilot validates the product with a limited cohort. Go-live runs a phased wave plan with go/no-go gates. Post-launch measures adoption and captures learnings in a retrospective.

Why do software rollouts fail?

Usually not because of code defects. Because of weak change management: missing training, unclear ownership, no phased wave plan, stakeholders who learn about changes too late, no defined success criteria for pilot. Industry research consistently puts the failure rate of large organizational change efforts at roughly 70%, and the common denominator is adoption, not engineering.

Who should own change management during a software launch?

Change management is typically owned by a program or release manager who coordinates across product, engineering, customer success, training, and executive stakeholders. The most effective rollouts assign a single named owner for each phase — and treat shared ownership ("all" or "TBD") as a red flag.

When should the rollout plan be written?

Before the product is finished, not after. Teams that write the plan early use it to shape product decisions — especially scope, sequencing, and the first-wave cohort. Teams that wait until feature complete almost always underestimate the readiness and enablement work.

What is a go/no-go gate?

A pre-defined checkpoint at which a named owner can stop a launch. A gate without the authority to halt a release is not a gate — it is a ceremony. Effective rollouts write the gate criteria before the launch and rehearse the decision so that "no" is a real option.