share

In large-scale transformations—digital, operational, or organizational—failure is often attributed to tools.

The system is too rigid.
The platform doesn’t support our way of working.
The technology isn’t flexible enough.

In reality, change rarely breaks because a system cannot do something. It breaks because people assume it already does.
What looks like a configuration issue is often something deeper: misaligned assumptions about how work is supposed to happen.

Most modern tools are designed with a clear internal logic. They embed guardrails, sequencing, ownership, and control mechanisms that reflect a particular view of how work should flow. For teams familiar with structured environments, these rules feel intuitive.
But intuition is shaped by history.

Why Systems Fail When Ways of Working Are Not Defined

Teams coming from informal or manual ways of working—spreadsheets, emails, calls, shared files—are used to resolving ambiguity through human coordination. Processes evolve organically. Exceptions are managed socially. Ownership is flexible.

When such teams move into structured systems, they often expect the same flexibility—only automated.
This is where change efforts quietly derail. The system assumes one way of working. The business expects another.

Both perspectives are reasonable. But when expectations remain implicit, friction becomes inevitable.
The turning point in many troubled transformations comes when the conversation shifts away from “How do we make the tool do this?” to a more fundamental question:

“What is the intended process—and why?”

• Not all work should be blended in real time.
• Not all decisions should remain reversible.
• Not all flexibility is beneficial.

Some boundaries exist to reduce risk, ensure predictability, and preserve accountability. Others can—and should—be redesigned once outcomes are stabilized. These are not technology decisions. They are process decisions.

When Data Issues Are Really Process Issues

Data issues often surface alongside this confusion. Constant rework, growing complexity, and downstream failures are rarely signs of weak systems. More often, they reflect unclear ownership, delayed decision-making, or unresolved process debates being pushed into execution layers.

And systems do one thing exceptionally well: They expose ambiguity that humans have been managing informally. The lesson is simple but uncomfortable.

Change management is not about helping people “adopt a tool.”
It is about making assumptions explicit, defining operating models, and aligning on how work should happen—before technology enforces it.

A Practical Example

In a recent transformation, a simple system rule designed to keep parallel teams from interfering with each other’s work became a point of conflict.
Teams expected to collaborate fluidly, while the system enforced separation to protect outcomes.

Nothing was “wrong” with the tool.

The real issue was that the organization had never explicitly decided when teams should work independently—and when their work was meant to converge. Once that process intent was clarified, the friction disappeared—and the system stopped being the problem.

Closing Thought

When processes are clear, tools feel empowering.
When processes are unclear, tools feel restrictive.

Successful transformation happens when technology is treated not as the starting point, but as the final expression of a well-thought-out process.