It is common for a company to spend months choosing the right system, testing vendors and comparing features, only to see the project stall not because of a technical failure but because the team simply does not use the tool as intended. The system works. The people just did not move over with it.
This is neither a rare nor an isolated problem. It is the pattern.
Why good systems "die" in the hands of teams
According to McKinsey, roughly 70% of business transformation efforts fail (source: McKinsey & Company Brazil, 2026). The central point of the firm's own analysis is not a lack of good planning or resources; it is a lack of engagement across the organization, whether from teams or from leadership. In other words: the company "chooses" the right system, but does not "buy into" the change it demands.
That explains why technically well-chosen systems end up forgotten, underused or worked around with parallel spreadsheets months after go-live.
The role of organizational culture in technology adoption
Prosci, a global reference in change management, identified five main reasons managers resist change: organizational culture issues, lack of awareness about the change, lack of buy-in, misalignment between project goals and personal incentives, and lack of confidence in their own ability to manage the change (source: Prosci, via prosci.com/pt). Of these five, organizational culture is the most frequently cited cause, especially in risk-averse cultures or those marked by distrust between departments and hierarchical levels.
In other words: before asking "which system should we implement," the more important question is usually "is this organization culturally ready to change the way it works?"
Communication and training: what to do before, during and after go-live
McKinsey's own recommendation is that the "how" of a transformation matters as much as the "what" (source: McKinsey & Company Brazil, 2026). In practice, that translates into three moments:
- Before go-live: communicate the reason for the change clearly, not just the timeline; people need to understand the problem being solved, not only the tool that is arriving.
- During go-live: hands-on training in each team's real working context, not just a generic manual.
- After go-live: active follow-up in the first weeks, to quickly spot where the team is drifting back to the old process.
Signs the implementation has turned into a "parallel spreadsheet," and how to reverse it
Some signs indicate that the new system has already lost the race to old habits: inconsistent data between the system and the team's informal controls, low use of the core features, or reliance on a single person to "translate" the system for the rest of the team.
Reversing this rarely requires switching systems. It requires going back to change management basics: reinforcing communication, resuming training and making sure that frontline leadership, not just executive leadership, is visibly engaged in using the new tool.
Sources: Gartner, WSO2, MuleSoft.
