In a webinar entitled ‘Business Drivers and Checklists for Successful SharePoint Governance', Randy Williams, SharePoint MVP and AvePoint Enterprise Trainer & Evangelist, and I discussed the business drivers that come from individuals outside the IT department for SharePoint as a service within an organization. These drivers often result in policies being defined to set the expectation with the business and to focus alignment with the IT department.
Over a series of posts, I will focus on horror stories, from some of our 8,000+ customers we have here at AvePoint, which provided the genesis for these business drivers. The intention of this series is to proactively help your organization understand what "could happen" and what the business drivers are to help you structure your organization's governance system. I'm fortunate enough to get to meet a lot of our customers in person to discuss their SharePoint pain points, and enjoy referring them to resources all over the Internet to help them to cure these pains. I often feel like a SharePoint therapist of sorts, and selfishly enjoy hearing the pains as it triggers new ideas for products and articles we can share more broadly.
I'm a big fan of mind mapping, and over time, I've collected these pains and sorted them into some distinct business drivers, influenced by the other SharePoint governance experts in the field I discussed in one of my previous posts. Here are the main business drivers (for more explanation of each of these, check out Randy's recent post on the topic here):
To refer back to the policy areas defined in the governance system that the 21 Apps team came up with (IT Governance; Project Governance; Information Governance; Business & IT Alignment; and Continuous Improvement), there is overlap between the drivers and the policies - not a one to one mapping. This would make for a tidier diagram, but you can't have everything I guess!
To start this journey through the business drivers, I will start with one of the pain points that I have heard at every single customer, small or large, this past year - accountability.
The definition of accountability - "the state of being accountable, liable, or answerable" - really does sum it up well with respect to SharePoint content. When I state SharePoint content, I really mean being accountable at a document, library, sub site, site collection, web app or farm level. There are obviously other forms of SharePoint content outside this stack, such as in service applications including the managed metadata term store, user profiles, and business connectivity services external content types.
Typically, in an organization the IT department has the accountability of the farm level from an operational and maintenance level.
From a web application level, these are typically the workloads such as a collaboration system, document management system, intranet, internet, business intelligence system and so on. Within an organization, these cross-business workloads are often owned by either the IT department or a specific business unit such as human resources, communications, information management, or marketing. For business-specific workloads like internet sites and business intelligence systems, they are typically owned by the departments who requested them and are charged for them by the IT department.
Accountability starts to get a little hazy at the site collection level and below. The main reason for this is that content at this level, especially in cross business workloads such as collaboration systems and document management systems, typically start to separate at this level. For instance, in a document management system, each department may have its own site collection or, even further, a project management office may have a site collection per project. There are so many varieties of information architecture at the site collection and sub site level that accountability is not often the business owner of a department. This would also be the case for a project site collection where the accountable person would be the project owner.
The major pain point within organizations I talk to is how to track accountability at each of these levels. At a farm level, this can be done easily with the farm administrators group. At the web application level, this can be done with the web application policy settings. This can be accomplished on site collections with site collection administrator level. At the sub site level, this can be achieved via the owners group level. The biggest problem with assigning users to these settings is that it not only is an easy way to track accountability, but it also gives heightened permission levels to them. The main challenge here is that often these accountable people are not trained in SharePoint and don't require ‘god mode' of the container against which they have been tracked.
The other side of the accountability is not only tracking it on provisioning of these containers, but for the entire lifecycle of the containers. A common issue among customers is that the original people held accountable have transferred roles or left the organization entirely. Typically, containers require archiving for legal reasons and storage constraints. Or, IT just needs to reach out to the accountable person to notify them of a change request. Without having an up to the minute accountable person, these decisions are harder to make and can cause rifts between IT and the business.
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
