SharePoint Online for managers: how to lead the journey from chaos to order (Part 3)
The closing part of the manager mini-series. How to actually lead a SharePoint transformation: three phases, who belongs at the table, the decisions IT cannot make for you, five common mistakes and a 90-day checkpoint.
In part one we explained why SharePoint is not just a “better drive” and why chaos grows wherever rules are missing. Part two showed what a well-run SharePoint delivers and how to measure the value. What remains is the hardest — and most underestimated — bit: how to actually see the change through.
This part is about leadership. Not about technology, but about the decisions, roles and phases that the journey from chaos to order goes through. Because it is leadership — not technology — where most “let’s tidy up SharePoint” attempts fail.
One more thing before we start: 2026 is picking up the pace. Microsoft is finishing the new generation of SharePoint this year and AI is becoming a standard part of the platform. Every month of delay means tomorrow’s capabilities — including the AI ones — will be built on today’s mess.
Why this is not an IT project
The most common way a SharePoint transformation fails sounds innocent: “Let’s delegate it to IT.”
IT can configure permissions, create sites and switch on policies. But it cannot decide on behalf of the business:
- which information is sensitive and who may see it,
- how the company organises itself (teams, projects, departments),
- which processes take priority,
- and what happens when someone breaks the rules.
Those are management decisions. If management doesn’t make them, everyday practice will — and we are back to the chaos from part one.
A SharePoint transformation is not a technology project with an IT sponsor. It is an organisational change with a business sponsor and technical support.
The practical consequence: if the project is run solely by IT, it will be technically correct — and organisationally dead. Rules without a business owner never get enforced.
What a realistic plan looks like: three phases
In practice the journey has three phases. They cannot be skipped — each builds on the previous one.
Phase 1: Mapping and clean-up (weeks)
First you need to know what you have. How many sites exist, which are used, where sensitive data lives, who has what access, what is duplicated and what is dead.
- An audit of the environment (technical and content),
- quick wins: archiving dead sites, trimming obviously wrong permissions,
- naming the biggest risks.
The output is not a pretty report for the drawer, but a list of decisions that need to be made — sorted by impact.
Phase 2: Rules and structure (months)
Only over a mapped environment does it make sense to build rules:
- information architecture — how the company maps into SharePoint,
- governance — who may do what, who owns what, how a new site is born,
- content lifecycle — what happens to a site when its project ends,
- templates and standards, so new things start out right.
This is where the biggest jump in quality happens — and also the biggest share of management work. Rules that management doesn’t approve and back remain a document.
Phase 3: Operations and growth (ongoing)
Order is not a project with an end date; it is an operational state:
- new sites are created in a governed way, old ones get archived,
- permissions are reviewed regularly,
- users know where to turn for help,
- the environment evolves — applications, automation, a gradual adoption of AI.
Without this phase, the investment from phases 1 and 2 dissolves in about a year. Entropy is reliable.
Who belongs at the table
A small team with clear roles beats a large committee. What works in practice:
- An executive sponsor — owns the “why”, unblocks decisions, protects the priority. Without one, the project freezes at the first conflict of priorities.
- An environment owner — one person for whom SharePoint is a product, not a server. Owns the roadmap, the rules and their enforcement.
- Content owners per department — people who understand their data and processes. They decide the structure of their areas.
- IT — technical delivery, integration, security configuration.
- Ambassadors — a few enthusiasts across the company who help others and carry feedback back.
Notice what is not on the list: “everyone”. Broad participation is achieved through communication and ambassadors, not twenty-person meetings.
The decisions IT cannot make for you
This is the core of the manager’s role in the whole transformation. At minimum, these five decisions must be made outside IT:
- Information classification. What is public, internal, sensitive. Without it, neither sharing nor data protection can be set up meaningfully.
- External sharing policy. Who the company works with and how. A blanket ban is as wrong as a blanket allow — reality routes around both.
- Who may create sites and teams. Freedom = speed + chaos. Control = order + friction. Where you want to sit on that axis is a business decision.
- Retention and archiving. How long things live, what gets archived and what gets deleted. A legal as well as operational question.
- Licensing and platform scope. Which user groups get which licences and which platform capabilities the company actually switches on. (The idea that “SharePoint is included” has its limits — for now it’s enough to say: this is a budget decision, not a technical detail.)
The good news: none of these decisions require technical knowledge. They require knowledge of the company — and the courage to decide.
The five mistakes we see most often
- Big bang. Six months of planning a grand migration while the chaos keeps growing and people lose patience. Waves with quick wins from month one work better.
- Rules without enforcement. The governance document exists, yet anyone still creates sites at will. An unenforced rule is worse than none — it teaches people that rules don’t apply.
- Zero communication. Users learn about the change only when something stops working. Adoption is not a campaign at the end of the project; it is continuous work from day one.
- “Done, we’re finished.” The project ends, the team dissolves — and a year later the environment is back where it started. Phase 3 is not optional.
- AI before the clean-up. Switching AI on over an untidy environment means faster access to the chaos — including data people were never meant to see. AI is a reason to do the clean-up, not a way to skip it.
Checkpoint: how to tell at 30/60/90 days that it’s alive
The metrics from part two measure long-term value. Here is a simpler question: is the project even alive?
- At 30 days: the mapping is done, risks are named and the list of decisions exists. The sponsor knows about them.
- At 60 days: the first quick wins are visible (dead sites archived, risky sharing trimmed) and the key decisions from the chapter above are made — not “in review”.
- At 90 days: new sites are created according to the rules, users know what is happening and why, and there is an owner behind everything SharePoint.
If none of these hold at 90 days, the project is not alive — regardless of what the meeting minutes say.
What to take away from the whole series
- SharePoint is a platform for managing company content — and without rules it turns into chaos (part 1).
- Run well, it delivers measurable value: faster processes, lower risk, AI readiness (part 2).
- And the way there is an organisational change: three phases, clear roles, management decisions and persistence (this part).
A manager doesn’t need to be a technician. They need to own the decisions — and refuse to believe that “IT will sort it out”.
The whole series in one place, plus follow-up topics: SharePoint for managers – the complete guide.
Want to know where your company stands on this journey? Start free with the SharePoint vitality test — a few minutes will show you where it hurts. And if you’d like to walk through the results together, get in touch — we’ll recommend the first steps that make sense for you.