Context
A professional services firm had been using Microsoft 365 for years. Teams meetings, shared documents, email through Outlook: the tools were embedded in daily life.
What wasn't embedded was understanding.
A listening session with stakeholders surfaced a quiet but significant gap. People used Teams every day but couldn't readily explain the difference between the Teams app and a Team, or how SharePoint and OneDrive related to each other, or why files sometimes appeared in unexpected places.
The firm had plans to roll out Microsoft Copilot across the organization. Before that work could begin in earnest, something foundational needed to happen first.
The Tension
The desire to move toward AI-assisted work was genuine. So was the pressure to move quickly.
But deploying Copilot into an environment where the underlying architecture wasn't well understood would likely compound the confusion rather than reduce it. Good AI output depends on well-organized information. Well-organized information depends on people knowing where things live and why.
There was also a subtler risk. If people didn't understand the tools they already had, introducing a powerful new layer on top of them wouldn't feel like progress. It would feel like more to manage.
The work needed to slow down before it could accelerate.
The Misalignment
Early planning had focused on what would be built: the IA model, the folder structures, the governance decisions, the rollout sequence.
What had received less attention was what people already believed. About how M365 worked. About where their work lived. About what the difference between OneDrive and SharePoint actually meant in practice.
Those beliefs weren't wrong so much as incomplete. And incomplete understanding of the underlying platform meant that any IA decisions layered on top would have to work twice as hard to land.
Before the infrastructure could be improved, the mental model needed to be addressed.
How I Approached It
I shifted the starting point.
Rather than beginning with the IA design itself, the work opened with a plain-language M365 primer: a way to build shared vocabulary before shared infrastructure. The goal was not to turn every employee into a SharePoint administrator. It was to give everyone enough of a foundation to participate in decisions about how their work was organized.
The primer tied directly to what existed in the tenant. Not an idealized version of M365, but the specific configuration, structure, and habits this particular firm already had. That specificity mattered. Abstract explanations of Microsoft's product architecture are available everywhere. What people needed was context they could recognize.
Stakeholder engagement was framed to respect where people actually were, rather than where the technology assumed they'd be. Vocabulary was introduced through day-in-the-life examples before definitions were offered.
What Shifted
As the primer took shape, conversations changed.
Questions that had previously required lengthy explanation became shorter. Stakeholders who had deferred to others on technology decisions began participating more directly. The gap between people who use M365 and people who understand M365 started to close.
That shift created room for the IA work to proceed differently. Design decisions could be grounded in a shared frame of reference rather than built on assumptions that varied from person to person.
The technology hadn't changed. The readiness had.
Why It Mattered
This work reinforced something I've seen in organizations of every size: people don't resist change because they lack capability. They resist it when they lack context.
Investing in shared understanding before deploying new systems isn't a detour from the work. It's often the most important work. It reduces the burden on the rollout itself and increases the likelihood that what gets built actually gets used.
When people understand the foundation, they can participate in shaping what gets built on it.
That changes the quality of the decisions. And the durability of the outcomes.
