The platform launched on schedule.

The implementation team completed its work. Employees attended training. Leadership received the final update, and the organization began paying for the system it had spent months selecting and configuring.

Then the old process returned.

Staff continued maintaining spreadsheets because the reports did not answer the questions they needed to answer. Approvals still moved through email because exceptions were easier to explain there. Information was entered into two systems because the integration handled only part of the workflow. Managers asked for manual summaries because they did not fully trust the dashboard.

The technology was implemented. The work never truly changed.

This is often described as an adoption problem. Sometimes it is. But “employees resisted the new system” can become a convenient explanation that prevents leadership from examining a harder possibility: the organization delivered software without redesigning the conditions required for the software to create value.

Go-live is a milestone, not the outcome

Technology projects need visible completion points. Contracts, budgets, implementation teams, and executive attention cannot remain open indefinitely. A go-live date provides necessary discipline.

The problem begins when technical availability becomes the definition of business success.

A system can be configured correctly, pass testing, migrate data, and become available to users without reducing cycle time, improving decisions, standardizing work, or producing the financial and operational benefit in its business case.

Those outcomes depend on what happens after launch. People must use the system for the intended work. Processes must operate differently. Managers must reinforce the new expectations. Data must remain usable. Exceptions must have somewhere to go. Benefits must remain owned after the implementation team disbands.

When the project plan ends at deployment, value realization is left to emerge on its own.

It rarely does.

The shadow process is evidence

Workarounds are easy to criticize because they appear to undermine the investment. They can also reveal what the formal design did not resolve.

A spreadsheet may exist because the official report combines data differently than the department needs. Duplicate entry may persist because two systems support different parts of the same process but do not exchange the required information. An email approval may carry context that the configured workflow has no place to capture. A private checklist may compensate for unclear status inside the platform.

Some workarounds are unnecessary habits. Others are how employees protect the customer, preserve accuracy, or keep work moving when the official process does not fit reality.

Leadership does not need to celebrate the shadow process. It does need to understand it before attempting to eliminate it.

Forcing employees to stop using the workaround without addressing the reason it exists can move the problem out of sight rather than solve it. Buying another application can add a third process to the two that already disagree.

The workaround is not always the failure. It may be the most visible evidence of the failure.

“Resistance to change” is an incomplete diagnosis

People can resist new technology for familiar reasons. The old process is comfortable. The new one requires learning. A change may alter status, autonomy, or workload. Employees may not understand the purpose or believe leadership will sustain the effort.

But behavior that looks like resistance can also be a rational response to poor design.

The system may require more steps than the process can support. Training may demonstrate features without explaining how an employee’s actual work should change. Managers may continue requesting the old report while telling staff to use the new platform. The organization may have standardized a process without resolving legitimate differences between departments.

The distinction matters because the remedies are different.

More training can address a knowledge gap. It cannot repair a missing integration, establish process ownership, resolve contradictory performance measures, or make an unsuitable tool fit the work. Stronger enforcement may increase usage while leaving the expected outcome untouched.

Adoption should not be reduced to whether people comply. It should reveal whether the organization and its technology can perform the intended work together.

Software cannot decide who owns the process

Technology can route a request, enforce a required field, calculate a value, and record an approval. It cannot decide which department owns the outcome or which leader has authority when priorities conflict.

Those decisions are often left ambiguous during implementation because resolving them is more difficult than configuring the platform.

The project team reproduces the existing workflow because it has a deadline. Departments defend their exceptions because each has a legitimate need. The vendor implements the requirements it receives. Leadership assumes the new system will create consistency.

Instead, the organization digitizes its disagreement.

The result may be a technically successful implementation with competing definitions, redundant controls, unclear accountability, and several versions of the process living inside and outside the platform.

This is why technology transformation cannot be delegated entirely to technology. The work crosses organizational boundaries, and the decisions required to change it are management decisions.

The old operating model reappears between systems

Few platforms operate alone. They exchange information with finance, customer management, identity, reporting, document, communication, and industry-specific systems. The organization’s work moves across all of them.

An implementation can optimize one platform while increasing friction across the full process.

Data may arrive too late for another department. An integration may transmit the record but not its supporting context. A process may be standardized in one system while a downstream team still requires a different definition. Employees then become the connective layer, moving, checking, translating, and reconciling information manually.

The same effect occurs when an organization preserves every former customization. The new technology carries forward exceptions that no one would intentionally design today because changing them was considered too disruptive during implementation.

The system is modern. The operating model surrounding it remains historical.

That distinction connects to the questions leadership should ask before approving a technology investment. A proposal can explain what the platform does without clearly defining which work will change, who owns that change, or how the benefit will be measured after launch.

The executive view and employee experience can diverge

A 2026 global study published by WalkMe found a substantial gap between how executives and employees described their technology environment. Eighty-eight percent of surveyed executives believed employees had adequate tools, while 21 percent of workers agreed. More than half of workers reported bypassing an AI tool to complete a task manually at least once during the preceding month.

WalkMe sells digital-adoption technology, and the study focused heavily on AI in large enterprises. Its exact figures should not be treated as a universal measure for every implementation. The disconnect it illustrates is still useful: leadership can see a portfolio of deployed tools while employees experience the friction between them.

Prosci’s 2025 ERP research provides another qualified signal. It estimated that roughly one in five implementations delivered less than 70 percent of expected business benefits and reported that human and organizational factors mattered far more than purely technical factors. Prosci provides change-management services, so its findings should also be understood in that context.

Neither source establishes a simple failure rate for all technology projects. Both point toward the same leadership concern: technical completion and operational value are different conditions.

Measure whether the work changed

Login counts, license utilization, completed training, closed tickets, and workflow volume can all provide useful evidence. None is sufficient on its own.

An employee can log in every day and still perform the consequential work elsewhere. A department can complete every required course and retain the same manual reconciliation. A workflow can process more transactions without reducing errors, shortening decisions, or improving the customer experience.

The relevant measures depend on the purpose of the investment.

If the system was intended to reduce duplicate work, leadership should understand whether duplicate work declined. If it was intended to improve visibility, leaders should know whether decisions became faster or more reliable. If it was intended to standardize a process, the organization should know whether exceptions decreased or merely moved into email and spreadsheets.

This does not require an enormous measurement program. It requires continuity between the promise that justified the investment and the evidence used to judge it after launch.

Someone must remain accountable for that continuity.

Diagnose the work before buying the next answer

When value remains unrealized, organizations commonly respond with another round of training, additional configuration, stronger mandates, or another product intended to close the visible gap.

Any of those actions may be appropriate. None should be automatic.

The organization may need to examine the full path of the work: where it starts, how decisions are made, where data changes meaning, which exceptions matter, what employees are compensating for, and who owns the result across departmental boundaries.

That examination is especially important when an AI pilot appears successful but cannot become routine enterprise work. The model may function correctly while the surrounding process, data, ownership, and behavior remain unprepared to carry it.

A platform can enable a better way of working. It cannot create one without leadership decisions around it.

The next question after go-live should therefore be more demanding than whether the system works.

Did the organization’s work change in the way the investment promised—and if not, what has the old process been trying to tell leadership?

Sources