The Reframe That Changed the Room

Governance  |  Organizational Change  |  Portfolio Management

The Reframe That Changed the Room.

THE SITUATION

A decision had been made at the CIO level: the organization's project management platform was changing — globally — and a major functional group needed to adopt it, whether they were ready or not.

The resistance was immediate and open. The group being asked to change had built something that worked. Their reporting provided leadership visibility that had taken years to develop. The transition to the new platform meant losing that visibility, at least initially, and generating manual workaround costs in the interim. They said so directly, and they were not wrong. The cost was real. The disruption was real. Nobody had asked them before the decision was made.

My role was to lead the adoption. What I inherited was a room full of people who believed — correctly — that they were being asked to take a step backward for reasons that did not benefit them directly.

WHAT I SAW

The instinct in situations like this is to treat resistance as a compliance problem. People are not adopting the new process, so the response is to enforce it more clearly, communicate it more broadly, or escalate to someone with sufficient authority to end the argument.

That approach almost always makes the problem worse. It confirms the resistant group's framing — that this is something being done to them — and it eliminates the organizational trust that adoption actually requires.

What I saw was a framing problem, not a compliance problem. The group was evaluating the change as a competition between their department's needs and a corporate mandate. As long as that was the frame, every conversation about the change was a negotiation over loss. The question I needed to answer was not how to make them comply. It was how to change the unit of competition entirely.

The reframe was simple, but it required changing what the group was competing against. Not each other. Not corporate. The organization's competitors.

WHAT I DID

The reframe was this: the organization needed a single, consistent view across all functions to tell investors a complete story — not one department's story, but the full organizational picture. To produce that view, everyone had to operate from the same platform. That meant this group had to take two steps backward so the broader organization could take one step forward. The competition was not internal. The stakes were external.

That distinction changed the conversation. It did not make the group enthusiastic. It made them willing to come to the table — which was the necessary first step.

The second move was investing in support rather than mandate. Adoption decisions get made in the first weeks of use. A team that encounters a wall in week two and finds no one available to help will route around the new system — not out of defiance, but out of necessity. The workaround becomes the process, and the new platform becomes what nobody uses correctly.

I treated post-launch support not as a training event but as an adoption strategy: dedicated people, available to solve actual problems, for as long as the problems existed. Change management and application support were not handoffs. They were sustained investments in the outcome actually happening.

Third, I co-designed the transition requirements with the group rather than presenting them with a finished implementation plan. Their input identified visibility gaps that the new platform had not been configured to address. Some of those gaps were closed before go-live. The ones that weren't became the most important lesson of the engagement.

WHAT CHANGED

The adoption succeeded. For the first time, the organization had a single, consistent view across all functions. The holistic portfolio picture that leadership needed to make confident decisions at scale now existed. The group that had resisted most loudly ended up contributing the foundation that made the consolidated view possible — because they had the data infrastructure that the other groups lacked.

The harder lesson was what didn't survive the transition fully. The granular functional visibility the group had built within their own operations — the tracking that had never been designed into the new platform — was not fully recovered after go-live. The moment to establish it as a design requirement had passed. Once the pressure of launch was behind us, it felt optional. Nothing in the structure made it mandatory.

A transition can achieve its primary purpose while incurring a secondary cost that only becomes visible later. I have carried that lesson into every subsequent implementation: the design decisions — what gets tracked, why it matters, and what becomes invisible if it is not captured from day one — must be made before any of the adoption work begins. Early and active governance in the design phase is not overhead. It is the difference between a successful adoption and a successful adoption with a gap no one notices until it matters.

WHAT THIS ILLUSTRATES

Executive Decision™ Framework: Strategic Clarity + Organizational Visibility + Disciplined Execution

This story moves through three pillars of the Executive Decision™ Framework in sequence. Strategic Clarity — aligning the group around the organizational imperative rather than the departmental trade-off — was what made the adoption possible. Organizational Visibility — building the enterprise-wide portfolio view that leadership needed — was the outcome the adoption was designed to deliver. Disciplined Execution — the sustained support investment, the co-designed transition requirements, the attention to what the system was built to track — was what determined whether the outcome was durable or fragile.

The gap that remained after go-live is its own lesson: execution without early governance is always incomplete. The design decisions made before the work begins determine what the organization can see after it ends.