How to avoid SharePoint sprawl

When SharePoint launches in an enterprise, it typically heats up quickly, with enthusiastic users acting like kids with Lego. Here are some tips for keeping growth under control.

It must be awkward for Microsoft, having a product out there that people use too much and too often; more awkward still, that this overuse is so ubiquitous that the IT industry has given it a name.

Yet almost anyone who uses SharePoint will nod knowingly when they hear any mention of "SharePoint sprawl." If your organization uses SharePoint as its intranet and hasn't been afflicted with this problem, it may be occasion for a hint of pride; there's some admirable self-discipline going on. But far more often than not, a SharePoint deployment will take on a life of its own.

Why this should be so is not hard to puzzle out. In SharePoint, Microsoft has given us a machine not unlike those physics-defying contraptions in Dr. Seuss books, bristling with levers and gears, that glop out some odd, scary commodity at the touch of a button. That's SharePoint in a nutshell: push a button, make a website. Not a web page, a web site, with all the Dr. Seuss machinery.

Need a team site for your current project? Click. Want your own personal site on the intranet? Click. Want to dump all your files into the CMS in one scoop? Click. Whole lotta clicking going on, and it's easy to see how many organizations end up creating messes greater than the ones they intended to be cleaning up.

Why does this happen?

Ease of deployment. Creating Team Sites, or MySites, or new libraries or lists (a list is, under the hood, a SQL table of arbitrary complexity) really is push-button simple. There is little cost or consequence to creating new sites or associated objects, even on a whim. When SharePoint is made available, this sort of usage is generally encouraged, to get the workforce interested. That's a two-edged sword, of course, for obvious reasons. Experimenting in production. Since it's so easy to create things in SharePoint, a mindset quickly settles in: let's try out this new idea in SharePoint! Why not? It's quick and easy and cheap. The end result of this mindset is, of course, that you've created a sandbox the size of Texas - in production. The Windows Explorer View. This clever, convenient fake-out utility - a window you can invoke within a document library that allows you to copy files and folders to and from the NTFS - was intended as a transitional tool, to make file handling as familiar as possible while users settle into the SharePoint paradigm. Boy, did it backfire! Rather than weaning users off the file folder system, it gave them an excuse to cling to it.

And so we have sprawl, runaway sprawl. The CMS rapidly clutters up, increasing access latency; and where we once had network shares ridden with endless useless, unmanaged files, we now have an intranet ridden with endless useless, unmanaged sites. Security becomes a nightmare; compliance, if an issue, becomes far harder to achieve than it was before.

Ordering the chaos

The silver lining in being an industry cliché is that with so many organizations falling victim to sprawl, we have lots of survivor tales to inform our remediation efforts. Or, better yet, to guide us around sprawl altogether. Here are some tricks that have worked for others.

Ecumenical governance. The biggest reason business resources slip into an unmanaged state is that those using the resources lose focus on the objectives and priorities to which the resources are supposed to be dedicated. SharePoint needs governance, the highest-quality governance you can manage, to maintain that focus. But even more, that governance needs to include all voices; those dispensing the governance won't stay on track if they don't understand fully why the user community is pulling things off track. Fully understanding the needs of the community and the potential of the resource is a matter of listening to everyone, not just the high-level decision-makers. No Windows Explorer View. This may be the single toughest fix; once people learn how to drag-and-drop into SharePoint, they never want to stop - and they never learn the far more efficient and flexible style of file management that SharePoint is intended to cultivate. So don't show them in the first place. Keep the experiments in the lab. SharePoint really is the ultimate sandbox for users. The let's-try-it-out factor is irresistible for good reason: it works. We can't reasonably ask people not to do this, because the alternative is to take back that sandboxing function into IT, and that defeats the purpose of SharePoint (making users more self-reliant). Try this, instead: stand up SharePoint in UAT, not just for the application work, but for Team Sites and content reorganization. Give the user community access to the Team Sites / MySite corner of UAT and let them go nuts - then promote the good stuff to production. Archive the old. One great way to push back against the endless creation of SharePoint sites is to establish an archiving policy that limits lifespan. Got a team site? Great! You can have it for (90 days, six months, a year, whatever works in your world). Then it's getting archived. Implement quota management. At the site collection level, SharePoint offers a hedge against sprawl, and it's an effective one. Sprawl persists largely because few organizations bother to use it. It's called quota management, and it puts a limit on the number of sites that can be created within a collection, as well as a maximum size (storage-wise) for each individual site. Controlling growth in two dimensions from this single point is enormously effective - if you take the trouble to do it.

There may be a concern that taking these measures might spoil everybody's fun. But most organizations that have gone this direction have found that this extra layer of policy and process leaves plenty of room for running and jumping and climbing.