Category: Administration

Inside just about every organization that uses SharePoint, there’s a quietly seething war happening. No, it’s not between you and the person that keeps stealing your food from the fridge – but honestly, who does that?

It’s between the SharePoint IT crowd and the business end users.

Both sides think the other abuses SharePoint and makes it unusable, and both sides think that the other should just shove off and let the people who know what they’re doing handle the situation. This kind of conflict happens most often when strong governance isn’t in place before, during, and after SharePoint is deployed – since governance is almost always either totally undeveloped or underdeveloped, the battle between IT and users is a common one.

So What’s The Problem?

There are two fundamental approaches to SharePoint:

Scenario 1: SharePoint Owned by IT

IT is told to deploy SharePoint to allow people to collaborate, communicate, and various other ate’s. Usually this means a server admin installs SharePoint, gives the business user(s) limited access (usually Contribute), and considers the service request fulfilled. Business users are given the URL, told how to login and left to their own devices. IT favours this approach, as they tend to dislike relinquishing control of their infrastructure and resources to non-IT personnel. Business users tend to hate this approach, as they must now must submit tickets to IT for just about everything you can do in SharePoint: manage permissions, create lists and libraries, etc.

The conflict between IT and business here comes from business feeling like they’re constantly on a leash that IT holds. Business wants to do things right now and doesn’t have time to wait on IT to get what they need done, and they don’t want to be subjected to IT decisions such as server moves, downtimes, etc.

Scenario 2: SharePoint Owned by Business users

Usually this scenario happens when a business user catches wind of SharePoint at a conference, trade show, or meeting with a colleague, and and it’s love at first site (pun intended). Someone within business with some tech savvy and initiative fires up a server, installs SharePoint, and lets the business user community go at it. Business users really love this approach, as they now have a powerful technology stack under their complete control, which they can (in theory at least) make jump through the hoops they need jumping through. IT, on the other hand, is fuming mad, because they definitely do not like being kept in the dark when it comes to someone deploying servers in their environment, especially when something blows up a year later and are told that they have to fix it.

In this scenario, the friction comes from IT feeling left out of the decision making process and told they need to clean up when something business has chosen to do has blown up. Most often IT will propose bringing the server ‘into the fold’ to which business users will dismiss outright and fight tooth and nail to keep their toys in their backyard. IT becomes frustrated because they become a cleanup crew, but business enjoys it because they get all the benefit, and risk is absorbed by IT.

Power Up To 11

SharePoint doesn’t do 10.

At it’s core, this whole situation is a power struggle. In Scenario 1, IT feels empowered but business feels powerless. In scenario 2, it’s just the opposite. Neither approach truly works, because it creates a lopsided power dynamic that always leaves one side mad, frustrated, and wanting to hit the “ABORT” button on the whole thing.

The only solution is to establish a hybrid model – a power sharing approach that involves both groups to empower each other.

The Fix: IT Enables, Business Executes

Coffee Talk

The most first step is to have IT and business stakeholders sit at the same table, ideally as a part of a larger governance committee. The various stakeholders from both sides need to flesh out the divisions of responsibility and the expectations they have for each other.

In essence, both sides need to communicate with each other and on a regular and permanent basis. It doesn’t work to have one meeting before kickoff, and it doesn’t work to do it sporadically when people feel like it (and for God’s sake don’t do it on a Friday afternoon). Depending on your level of use of SharePoint, this could mean a bi-weekly or monthly meeting between IT and business to keep each other informed and head off issues and conflict before it even happens.

A great tool baked right into SharePoint to facilitate this kind of integration between IT and busines are Blogs. I’ve found creating a blog where technical and non-technical stakeholders can post updates, discuss issues and keep each other informed is invaluable.

Render Unto Caesar

After the initial discussions above, you should start to have a pretty clear understanding of where each of the responsibilities lay.

Let’s be honest here: business users do NOT want to have to deal with server health, backups, patches, combing through the ULS logs troubleshooting, etc. Nor should they! This is IT’s bread and butter. Business users should be focusing on business: how to improve, how to be more efficient, how to use the tools.

Similarly, IT should not have to be contacted every time permissions have to change or a list needs to be created – this is the day to day business side, and frankly IT has better things to do with their time. Therefore, business users must be trained and trusted to take on all of the day to day responsibilities. Training is critical for both sides, because the more training they each have, the more they can focus on getting work done and the less they have to ask the other side to solve their problems with SharePoint.

In my mind, the business owner of SharePoint should be able to perform all of the operations available to them up to the Site Collection Administrator level; everything from managing permissions to workflows and sandboxed solutions. IT, on the other hand, should have the knowledge and ability to proactively address issues before they become problems, and work with business to quickly address problems.

Magna Carta

What we’re talking about above, really, is governance. Stakeholders coming together to define and work together to determine the who, what, when, where and why of SharePoint as a tool. Write down the outcomes from these discussions. Share what you’ve written down with the group. This is how you can start to develop a framework for governance that can be built on over time. Governance doesn’t have to be a giant, monolithic project (but you do have to address it at some point), you can start small and iterate to a larger goal.

Wrap Up

SharePoint is a unique bird in that it will starve if one group keeps a strangle-hold, but it tends to thrive when multiple groups buy into the technology and work together to develop it into a success. IT and business aren’t mutually exclusive, they’re part of the same workplace ecosystem, and as such, what’s good for one side is good for the other. IT and business can work together, and indeed they must work together if SharePoint is to be a cause for celebration rather than a source of conflict.

When a SharePoint site is created, by default the creator’s email address is automatically populated into the “Manage Access Requests”. However, sometimes the creator isn’t the site owner, and doesn’t handle the day-to-day access requests for the site.

The script below will go through all sites and site collections within a designated web application and list the site title, url, and Access Request email.

If you’d like to spit out an inventory CSV file with the URL and number of characters, just use the Out-File Cmdlet: