SharePoint at 25 — Episode 2: That Governance Document on the Shelf Isn’t Governing Anything

For years, governance in SharePoint has been treated as a document.

We write policies, frameworks, and rules at the start of a project, get them approved, upload them to SharePoint… and then quietly hope they’ll influence how people work. In reality, those documents rarely shape day-to-day behaviour. They sit on shelves while environments drift into inconsistent structures, fragile permissions, duplicated content, and growing frustration.

In this episode of the SharePoint 25th Birthday Series, Liza unpacks why governance documents fail — not because governance doesn’t matter, but because documentation has never been an effective control mechanism.

This episode explores what governance documents are actually good at capturing, what they fundamentally cannot control, and why real governance has to be built into the design of the system itself. From site creation through to document lifecycle and archiving, Liza walks through how governance by design works in practice — and why this approach is no longer optional as organisations move toward AI-enabled work with tools like Microsoft Copilot.

This is also where Fix the Mess™ fits in. Instead of relying on shelfware policies and training-heavy governance, Fix the Mess™ focuses on designing SharePoint environments that guide behaviour by default. The Studio and courses provide practical, real-world starting points that replace guesswork and good intentions with structure, consistency, and clarity — while still allowing organisations to tailor and evolve their environments over time.

If your governance still lives in a PDF, it isn’t governing anything.
 Better SharePoint — and better AI outcomes — start with better system design.

Transcript

SPEAKER_00 0:07

Let me paint a picture. Somewhere in your SharePoint environment, probably in a folder called Project Closeout or Governance, there's a document. It's well written. It was reviewed. It was approved. It might even have a version number and a review date. And it's doing absolutely nothing. This episode is part of my SharePoint 25th birthday series, and today we're talking about governance. Specifically, why governance documents so often fail, what they catch a well, and what they completely miss. And how to stop writing documents that sit on shelves and start building systems that actually govern. Because if governance still lives in a document, it isn't governing anything. I'll be up front, I've never enjoyed writing governance documents. Not because governance isn't important, but because after more than two decades, working with SharePoint from early on-prem environments through the subsite era and into modern Microsoft 365, I've seen the same pattern repeat. We write governance at the start of a project, we workshop it, we review it, we sign it off, and then we upload it to SharePoint and move on. The document becomes something people can point to, not something that actually shapes behavior. To be fair though, governance documents aren't useless. They're very good at capturing intent, principles, ownership models, retention requirements, and risk considerations. They answer questions like who owns what? What should happen in theory? What are we trying to protect? But none of that tells someone what to do in the moment when they're actually creating a site, uploading a document, or sharing content at speed. Governance documents describe what should happen. They rarely control what actually happens. Governance documents don't capture behavior. They don't stop people creating inconsistent structures. They don't prevent fragile permissions. They don't enforce metadata. They don't guide people toward the right decisions when they're under pressure. Instead, they rely on people stopping mid-task and thinking. What does the policy say about this? That moment almost never happens. And that's not a people problem, it's a design problem. Governance is not a documentation problem, it's a design problem. Governance is a series of decisions about how the system behaves, what users are allowed to create, what defaults are applied, what choices are removed, what structure exists from day one. Every design decision either reinforces good practice or quietly allows chaos to creep in. In a well-designed SharePoint environment, governance doesn't live in a folder of policies. It lives in site templates, library defaults, content types, metadata requirements, permission models, life cycle and retention rules. You don't tell people how to structure a project site, you give them a template. You don't remind people about retention, you automate it. You don't rely on training to compensate for poor structure. Governance becomes part of how the system works. Now let me make this really practical. Instead of a 40-page governance document, let's walk through what governance by design actually looks like, end-to-end, using a marketing site as an example. From the moment a site is created all the way through to document archiving. Governance doesn't start after a site exists, it starts at creation. In this model, users don't create a blank site. They create and request a site through a simple form or provisioning flow. Then behind the scenes, the site type is predefined as marketing. The template is locked to that purpose. Ownership is assigned automatically. Naming conventions are enforced by the system. No one is deciding structure, no one is guessing, and the system already has made the decisions. That alone replaces several pages of a governance document. When the marketing site is created, it already contains standard document libraries, predefined folder structures where they make sense, default views tailored to how marketing actually works. For example, campaigns, brand assets, content production, suppliers and agencies, reporting and performance. Users aren't designing architecture on the fly. They're stepping into a structure that reflects how the function works. This is governance in action without a single rule being read. So each library also comes with existing minimal meaningful metadata within it, such as the document type, a spot for campaign name, the status, draft in review, approved, etc. Sensitivity labels, usage rights, all in the library already, ready to go. Additional critical fields, make them mandatory, make them optional, pre-fill them where possible. This way users aren't deciding whether metadata applies, they're simply completing what the system requires. This replaces pages of users must apply metadata policy text. Permissions are also not left to chance. At the site level, the marketing owners are defined. Members have edit access. Visitors have read-only access. At the library level, we have sensitive libraries where they inherit restricted access. There's external sharing and it's been enabled only where appropriate. Asset libraries may allow broader read access by design. No one needs to remember permission rules. No one needs to interpret policy language. The system enforces it consistently. So now what happens is when a marketer uploads or creates a document, it lands in the right library. It inherits the correct permissions. Metadata is prompted automatically. Views surface content by campaign, status, or type. Users don't have to think about governance. They just work. And because the structure is predictable, search works, copilot has context, duplication drops, cleanup becomes easier, and this is invisible governance doing its job. Also, as documents move through their life cycle, the status metadata changes, views update automatically, approval workflows can trigger where needed, and ownership remains clear. Nothing relies on someone remembering a process described in a document. The system reflects the life cycle visually and structurally. And finally, document life cycle. Retention rules are applied at the library or content type level. When content reaches the end of its active life, it's automatically retained, archived, or disposed of. There's no manual reminders, no spreadsheet tracking, no panic during audits. This is governance that works quietly in the background, long after the project team has moved on. So at this point, you might be thinking, this all sounds great, but how do I actually do this? And this is the key thing to understand. You don't need to buy a huge governance platform to get started, and you don't need to lock yourself into something rigid either. SharePoint already gives you the building blocks, templates, libraries, metadata, defaults, and provisioning patterns. What most organizations are missing isn't tooling, it's a starting design. So that's exactly what the Fix the Mess Studio is built for. It gives you predefined real-world templates for common functions like marketing, HR, projects and teams as practical starting points. You still build them in SharePoint, you can tailor them, you can extend them, but you're no longer starting from a blank page or a governance document. The goal isn't to freeze your environment, it's to give you a governed foundation you can evolve. The best governance is almost invisible. When it's working, users are guided toward the right behavior automatically. Mistakes are harder to make. Consistency scales. Support and cleanup become easier. If governance only shows up when something goes wrong, it's reactive. If it quietly prevents problems before they happen, it's doing exactly what it should. This matters even more as organizations move toward AI-enabled work. Microsoft Copilot doesn't read governance documents. It doesn't infer intent. It works with structure, metadata, permissions, and ownership. If governance isn't built into SharePoint itself, AI doesn't fix that. It amplifies it. There is no AI without structure. And there is no structure without governance by design. As SharePoint turns 25, this is the shift we need to make. Governance is not a deliverable, it's not a document you write and file away. It's an ongoing set of design decisions that shape how work actually happens. If you want better SharePoint and better AI outcomes, the answer isn't more governance paperwork. It's better system design. In the next episode of the SharePoint 25th Birthday series, I'll be tackling one of the most debated topics of all: folders and metadata. Where they actually fit, how they work together, and why my approach is probably not what you think. And if this episode resonates, this is exactly what the new Fix the Mess series is built around: replacing policy-driven governance with practical design-led systems that work in the real world. You'll find links to the Fix The Mess courses and the related blog posts in the show notes. Thanks for listening, and I'll see you in the next episode.