Thai Vong is an enterprise CIO driving technology modernization, business transformation, and scalable execution in complex environments.
The system is live. The workflow works, the dashboard refreshes, training is complete and the team moves on. Then, the real test begins.
Do people use the new process? Do managers reinforce it? Are old reports shut down? Are side spreadsheets retired? Are approvals happening where they should? Are leaders asking for the new way of working or quietly accepting the old one? A technology project can hit every launch milestone and still miss the business outcome.
That’s why behavior change deserves more attention in transformation work. The investment doesn’t create value simply because the system is available. Value shows up when people make different decisions, follow different processes and stop relying on the habits the new technology was supposed to replace.
The real change starts before launch.
Many organizations treat change management as something that happens near the end of a project. Communication, training and support matter, but they aren’t enough. The harder work begins earlier.
Leaders need to define what changes after launch. Which manual steps should disappear? Which reports, approvals or exception paths should go away? Those are business design questions, and when they’re left unanswered, new technology gets layered onto old behavior. Employees learn the new process, while leaders still ask for old reports and teams keep familiar workarounds alive. That’s not transformation. That’s layering.
In the transformations I’ve led, go-live is rarely the best measure of whether the change is working. What matters more is whether people stop using the old process once the new one is available. I’ve seen this with reporting. The real change came when leaders used the dashboard in operating discussions and stopped asking teams to recreate the same information through older reports and spreadsheets.
That doesn’t mean every issue is resistance. Sometimes, the new process needs adjustment. I’ve learned that the harder judgment call is deciding whether the feedback is exposing something we need to fix or simply protecting a familiar way of working.
Ownership can’t end with the project.
A project team can deliver the system, but it can’t own the business outcome forever.
Once the technology is live, ownership has to move into the business. Someone needs to own adoption, process compliance, issue resolution and benefits realization. That distinction matters because a delivered capability isn’t the same as a realized benefit.
A better model defines accountability before launch. Who owns the process? Who approves changes and exceptions? Who retires the old path? Who measures whether the expected value is showing up?
I ran into this during an ERP modernization where we introduced redesigned screens, new layouts and changes to familiar workflows. The technology worked, but users still had to learn a different way of working. IT could configure and support the system, but we couldn’t own how people adapted to the new process. Before go-live, we worked with the business to clarify the responsibilities were clear. IT owned the technology and support, while the business process owner was responsible for adoption, training reinforcement and decisions around process changes or exceptions.
That became important soon after launch. Some users wanted to recreate familiar steps because the new screens and workflow felt different. We could determine whether there was a technical issue, but the business had to decide whether the process truly needed to change or users needed more time and training.
The harder part came when operational pressure made the old way feel easier. Bringing back a familiar workaround might solve an immediate problem, but it could also recreate the process we were trying to standardize. We had to work through whether we had a real design issue or were simply preserving an old habit.
That experience taught me that ownership has to hold after the project team steps away. If every process decision still comes back to IT after launch, the business never really owned the change.
This gets harder in larger organizations because technology leaders are often driving change across teams they don’t manage directly. IT can deliver the platform and help create structure, but business leaders still have to reinforce the change within their own teams.
In regulated environments, the stakes are higher. Whether the concern is SOX, GxP or other audit requirements, the business needs evidence that the process is being followed, exceptions are documented and ownership remains clear.
Culture is visible in the follow-through.
You can see what an organization really values during a transformation. Culture shows up when the old workaround is easier than the new process, when managers quietly accept exceptions or when leaders keep asking for the legacy report.
If the culture rewards speed at any cost, people will bypass controls. If the culture avoids difficult decisions, legacy processes will survive. If the culture treats adoption as optional, the technology won’t deliver its full value.
Not every issue is resistance. Sometimes, the system, process or training genuinely needs adjustment.
I’ve had situations where users went back to a manual step because the new process created a problem we hadn’t anticipated. In that case, the right answer was to fix it. I’ve also seen workarounds continue simply because people were more comfortable with them. Those are two different problems, even though they can look the same at first.
What I’ve seen work is staying engaged after launch: making ownership clear, removing competing processes, reinforcing the new behavior and measuring whether the expected outcome is showing up.
Behavior change takes patience. Adoption doesn’t happen because a system is available. It happens because leaders keep connecting the change to the business result and reinforcing the practices that support it.
That’s what many organizations underestimate. Technology can create the conditions for progress, but people determine whether the value is realized. Behavior change is where the transformation investment either becomes part of how the business operates or turns into another capability the organization paid for but never fully absorbed.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?