Why digital transformation fails without an upskilled workforce

It wasn’t that long ago that digital transformation projects were considered somewhat optional and only pursued by the most forward-thinking organizations. But, as they say, that was then and this is now. In an environment where generative AI has taken the world by storm over the past few years, it’s fair to say that virtually all companies are finding themselves immersed in digital transformation efforts of various kinds.

Immersed and struggling.

Here’s a scenario that plays out regularly across organizations of all types and sizes. The company makes a significant investment in a new ERP system or digital platform. The technology is sound. The implementation team delivers on time and on budget. Leadership celebrates a successful go-live. But then, within just weeks, the successful implementation starts to fracture.

Why? It’s not the system that fails. It’s the people trying to use it.

In my work leading various workforce upskilling initiatives for large-scale ERP and digital transformations, I’ve learned that systems rarely fail because the technology doesn’t work. They fail because the organization hasn’t taken steps to change its infrastructure and processes to accommodate the new system.

This isn’t about motivation or effort. It’s about failing to create an infrastructure designed to support the new technology and all of the related process changes associated with that technology. The capability shifts required by new technology are often significantly underestimated. If addressed at all, it’s addressed too late in the transformation lifecycle.   

The result? Significant organizational costs that can include productivity drops of 30-40% in just the first quarter of implementation, tripling of support tickets, a proliferation of workarounds as employees attempt to adapt to the new impacts, all pushing back projected ROI timeframes and contributing to stress, burnout, and turnover. 

Go-live ready is not capability ready

While a new system can be configured, tested and deployed in 12-18 months, building genuine capability that supports people in making complex decisions, successfully and confidently handling exceptions, and maintaining controls under pressure, takes longer. Much longer.

As I’ve examined the success of training transfer in technology implementations, I’ve found that only 10-20% of the skills learned in formal training programs actually translate into sustained on-the-job performance. This isn’t because the training is poorly designed. It’s because training efforts often treat capability building as an isolated instructional event instead of a systemic performance requirement.

“Capability” isn’t simply knowing which buttons to click. It’s being able to troubleshoot when data doesn’t reconcile. It’s understanding how actions in the system cascade through downstream processes. It’s recognizing when something that’s technically possible in the system violates a business control. It’s making judgment calls when the system presents options that the training scenarios never covered.

These capabilities can’t be developed through a three-day training session two weeks before go-live. They’re built through repeated practice, pattern recognition, feedback loops and reinforcement over time. The system itself may be ready to execute transactions, but if your workforce can’t operate reliably at scale, you don’t have a working system—you have an expensive liability.

The operational risks CIOs inherit

When upskilling is delayed or treated superficially, specific operational risks emerge quickly. In fact, in the implementations I’ve supported, I’ve found that organizations routinely experience productivity declines of as much as 30-40% within the first 90 days of go-live if workforce capability hasn’t been adequately addressed.

Tasks that used to take minutes now take hours. Month-end close cycles that used to run smoothly now run in all-hands emergency mode. It’s not the system that can’t perform, it’s the humans trying to use the system at least not yet, and not without a massive support infrastructure.

Second, if users don’t understand the system well enough to self-correct or troubleshoot, every minor issue becomes a support ticket. Every exception becomes an escalation. The support team, already stretched thin, becomes a bottleneck. Response times extend. Frustration builds. In addition, keep in mind that help desk interactions don’t actually build capability, they just provide workarounds that perpetuate dependency.

Third, workaround behavior becomes the norm. Users revert to offline spreadsheets, manual reconciliations and shadow systems because those feel safer and more controllable than the new platform. Worse, these workarounds often violate the very controls and process standards the new system was designed to enforce, creating compliance gaps that audit teams discover months later.

Fourth, control environments deteriorate. When people don’t understand how the system enforces segregation of duties, approval hierarchies or audit trails, they inadvertently or sometimes deliberately circumvent controls. For instance, I’ve watched organizations that invested in SOX-compliant systems end up with material weaknesses because users didn’t understand the control logic well enough to operate within it consistently.

The financial impact of these risks is substantial. In one analysis of implementations across multiple clients, organizations spent an average of 40-60% more on post-go-live support than budgeted and experienced ROI delays of 6-12 months purely due to capability gaps—not technical defects.

Upskilling as transformation governance, not training administration

Leading organizations have figured out that workforce capability isn’t a training problem; it’s a governance problem that needs to be addressed from day one.

These organizations treat upskilling as an architectural and operational concern, on par with data migration and integration testing. They recognize that no technical component goes live until the people involved can demonstrate reliable performance at scale.

This shift requires rethinking both the timing and the ownership of capability building. Rather than delegating upskilling to L&D as a pre-launch training sprint, organizations that are successful in their digital transformation efforts embed workforce capability as a core workstream throughout the transformation, governed at the steering committee level with the same rigor as technical delivery.

What does this look like operationally?

First, capability requirements are defined in behavioral terms and tied directly to business processes. These aren’t generic competency statements. Instead of “users will understand the procure-to-pay process,” the requirement becomes “users will independently resolve invoice-receipt mismatches within system tolerances without escalation in 95% of cases within 60 days post-go-live.” These behavioral standards become acceptance criteria that must be demonstrated before processes go live.

Second, building capability starts early, often in parallel with configuration. As soon as process designs stabilize, users begin practicing in sandbox environments—not to “learn the system” but to validate whether the process design is actually executable by people with realistic skill levels. This early involvement surfaces design issues that are expensive to fix post-go-live but relatively cheap to address during build.

Third, performance data, not completion metrics, drive readiness decisions. Rather than tracking how many people completed training, these organizations measure how consistently people can execute critical transactions under realistic conditions. They use pilot groups to test whether the combination of training, job aids, system design and support infrastructure actually produces reliable performance. If performance doesn’t meet standards, go-live doesn’t happen.

Fourth, reinforcement systems are engineered before go-live, not bolted on afterward. Dashboards that make performance visible, feedback mechanisms that correct errors quickly and incentive structures that reward accuracy over speed are designed into daily operations. My research in human performance technology has consistently shown that behavior is sustained by its consequences.

If old behaviors continue to be rewarded—like speed over accuracy—even perfectly designed and delivered training initiatives will fail to produce lasting change.

What CIOs can do in the first 90 days

Start by asking your transformation team this question: “Show me the behavioral performance standards that define readiness for the roles, and show me the evidence that we’re meeting them.” If the answer is training completion dashboards, course evaluation scores or “we have a really good training vendor,” you have a problem.

Next, spend time with actual end users not power users, not super users, but the people who will do this work day in and day out. Give them realistic scenarios that include the exceptions and edge cases that always come up in real operations. Watch how they problem-solve. Listen to what they’re confused about. Pay attention to when they revert to talking about “the old way.” These conversations will tell you more about true readiness than any training report.

Then examine the reinforcement available within the current organizational environment. Look at what’s actually being measured and rewarded in daily operations. If your performance dashboards emphasize transaction volume but your system requires careful data validation, the system itself is a programming failure. If manager incentives reward getting through month-end close quickly but the new system requires front-end accuracy to avoid downstream corrections, you’re engineering workarounds before go-live even happens.

One specific intervention I recommend within the first 90 days is to establish a “performance council” distinct from the training team. This group is composed of process owners, frontline managers or team leads and a few high-performing end users. They should meet weekly to review not whether people completed training, but whether they’re performing reliably in live operations. They look at error rates, support tickets, workaround patterns and time-to-competency for new users. They have the authority to pause rollouts, redesign job aids, adjust process steps and modify the reinforcement systems when performance data indicates that capability isn’t sticking.

This is governance, not training administration. And it positions workforce capability as what it actually is: a core dependency of system performance and a primary determinant of whether your transformation delivers value or becomes an expensive cautionary tale.

The path forward

The uncomfortable truth about digital transformation is that the technology is often the easy part. Modern platforms are remarkably capable. What’s hard is transforming the humans who must operate those platforms under the messy, ambiguous, high-stakes conditions of real business operations.

Upskilling isn’t “soft” work that can be delegated to HR and checked off a project plan. It’s systems engineering. It requires the same analytical rigor, the same stakeholder accountability and the same investment of leadership attention as any other critical path dependency in your transformation.

Organizations that treat workforce capability as an architectural concern—designing performance systems, measuring behavioral outcomes and engineering reinforcement into daily operations—consistently achieve faster stabilization, lower support costs and earlier ROI realization than those that treat it as a training problem to solve right before launch.

For CIOs, the implication is clear: you cannot outsource accountability for workforce capability any more than you can outsource accountability for system performance. Both are mission-critical. Both require governance. Both determine whether your transformation succeeds or becomes another statistic in the long list of implementations that were “technically successful” but operationally disastrous.

The next time someone tells you the system is ready to go live, ask one more question: “Are the people ready to operate it reliably, at scale, under real business pressure?” If the answer isn’t backed by behavioral performance data, you’re not ready. And delaying go-live by 30 days to build genuine capability will cost far less than the 12-month stabilization nightmare that follows when you don’t.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?