SharePoint governance didn't become a topic of concern in the SharePoint community until the Microsoft product team published their initial governance documents in response to the confusion and questions that the 2007 platform created with its initial release.
The strongest aspect of SharePoint – its versatility, flexibility and adaptability also was its Achilles Heel: "what's the best way to do such and such" was a common question. To this end, Ben Curry and I authored the only Best Practices book published by Microsoft Press that was focused on the SharePoint platform. We attempted to offer much needed thinking around best practices for SharePoint implementations. It was well received, though – as with all books – it had its detractors as well.
Swift to discern that customers would pay handsomely for governance consulting, it was only a matter of months before nearly everyone who was anyone in the SharePoint community was talking about governance and its benefits to SharePoint deployments. Many confused management with governance, co-mingled technical and business concepts and usually started and ended with a set of rules for SharePoint implementations in which the entire governance experience was conducted within the SharePoint platform itself with little relation to other software platforms and most business processes.
Over the years, Microsoft has produced a series of materials related to governance and a SharePoint deployment (you can find examples here, here, here and here). Traditionally, Microsoft has been a software development company whose main income streams were selling software and client access licenses. As they are transitioning to becoming a cloud-based, business solutions company whose main income stream are subscriptions from millions of customers, they are learning more how to connect the code they write with the business processes and problems their customers encounter on a consistent basis.
Having said this, Microsoft has not matured much, in my opinion, in their governance conceptualization. For example, compare these two definitions of governance – the first from 2009 and the second from 2013:
Governance is the set of policies, roles, responsibilities, and processes that you establish in your enterprise to guide, direct, and control how it uses technologies to accomplish business goals.
Governance is the set of policies, roles, responsibilities, and processes that control how an organization's business divisions and IT teams work together to achieve its goals.
There is little difference between the two definitions of governance. Both focus on business and IT working together to achieve business goals. That's all well and good – as far as it goes. But it is incomplete.
Shifting to the SharePoint influencers in the SharePoint community, their definitions of governance can vary widely. This means that our collective customer base is receive mixed signals about what Governance is and how it effects their SharePoint deployment. Some in the community take a technical approach, for example, saying that if you set a maximum size on your databases, that this is governance at work. Others go so far as to use a Greek word to talk about governance being a strategy that steers users toward desired behaviors (or away from undesirable behaviors).
We've learned that "governance" means different things to different people. But in a business context, there is an accepted thrust of what governance means and it's not technology focused.
In a classical sense, governance is part of a three-legged stool that forms the common acrostic GRC: Governance, Risk and Compliance. Take a look at these definitions of governance and see if you can discern some common threads:
The system of rules, practices and processes by which a company is directed and controlled. Corporate governance essentially involves balancing the interests of the many stakeholders in a company - these include its shareholders, management, customers, suppliers, financiers, government and the community. Since corporate governance also provides the framework for attaining a company's objectives, it encompasses practically every sphere of management, from action plans and internal controls to performance measurement and corporate disclosure.
Corporate governance is most often viewed as both the structure and the relationships which determine corporate direction and performance. The board of directors is typically central to corporate governance. Its relationship to the other primary participants, typically shareholders and management, is critical. Additional participants include employees, customers, suppliers, and creditors. The corporate governance framework also depends on the legal, regulatory, institutional and ethical environment of the community. Whereas the 20th century might be viewed as the age of management, the early 21st century is predicted to be more focused on governance.
Delaware Supreme Court
The most fundamental principles of corporate governance are a function of the allocation of power within a corporation between its stockholders and its board of directors.
Corporate Governance: A Synthesis of Theory, Research and Practice (Baker and Anderson, 2010)
In broad terms, corporate governance refers to the way in which a corporations is directed, administered, and controlled. Corporate governance also concerns the relationships among the various internal and external stakeholders involved as well as the governance processes designed to help a corporation achieve its goals. Of prime importance are those mechanisms and controls that are designed to reduce or eliminate the principal-agent problem.
Sarah Teslik: former Executive Director of the Counsel of Institutional Investors
Corporate governance is what you do with something after you acquire it. It's really that simple. Most mammals do it [care for their property]. Unless they own stock….it is almost comical to suggest that corporate governance is a new or complex or scary idea. When people own property they care for it: corporate governance simply means caring for property in the corporate setting.
These definitions – and dozens of others – have several common themes among them:
- Balance of power
- Interpersonal relationships
- Mitigation of risk
Governance isn't thought to be simply a coalescing of policies, roles, responsibilities and processes, it becomes more about ensuring balance in power and relationships, accountability to ensure self-interested activities that are injurious to others are mitigated while maintaining appropriate, professional relationships between stakeholder groups, both inside and outside the organization.
Hence, Governance is really the enforcement mechanisms that ensure compliance actions (or inactions) that lower risk for the organization.
Governance in the Real World
I recently wrote a SharePoint governance document for a customer who needed to present how they would govern their new SharePoint 2013 implementation to their Senior Management team. They didn't know what to write, so they hired Summit 7 to write this document for them.
In their culture, governance is a big deal (they are in a heavily regulated industry) and so every new software platform, partnership, product release and so forth must have Senior Management approval. Part of the business case presented to Senior Management for each decision is a section on Governance.
While the writing of this governance document was a bit rushed and non-standard, this vignette shows that the principles presented here are adaptable to a wide range of customer scenarios. For example, our customer needed the governance document quickly – within 2.5 weeks – and they had no business or technical requirements upon which to rely for the writing of the governance content. So this was the approach I took in creating their document:
- Listened to their presenting complains about their current SharePoint implementation
- Listened to how they conduct their core processes. For example, they run all of their projects out of a document library, surmising that most projects consistent mainly of documents. (It's not necessarily my role to suggest process improvements for any customer unless they ask for it – most companies use the processes they use precisely because it works in their culture)
- Listened to how they planned to use SharePoint 2013 moving forward
- I then took their problems and spent some time reflecting on how those problems would surface themselves in SharePoint 2013. I then restated those problems in terms of risks.
- I wrote the governance content to mitigate the problems (think "risks) by suggesting ways to avoid (mitigate) actions (or inactions) that would create those problems again.
- Since enforcement is a core aspect of governance, I decided that end-user enforcement of certain rules would be needed. So I defined roles and responsibilities that matched their positions with SharePoint roles such that they could connect their current grassroots leaders to the management of sites and site collections in a way that furthered their business and use of SharePoint 2013 while limiting the possibility of past problems cropping up in the future.
- Lastly, I finished by listing the risks and dangers if certain issues were not addressed and suggested ideas, training and support paths that would help them avoid those risks.
After sending them the rough draft and gaining their insights on how to improve it, I was able to deliver a governance document that they described as "perfect". It was written on the principles I outline in this post while delivering the value they wanted, though the process of creating the document didn't at all follow the implied process in this post.
Extending Governance with Risk and Compliance
A major departure that I take from the conventional wisdom concerning SharePoint's governance is that it should be derived, not created. Stated another way, good governance is dependent on a good risk assessment coupled with appropriate compliance rules and activities that mitigate the risks both within the platform itself and in relation to the processes it supports.
Without a thorough understanding of both parts - the risks that an organization faces with a commensurate compliance structure that mitigates these risks - governance will be created in a vacuum and it will likely devolve into a set of rules that are just as easily ignored as they are followed. While there might be some rhyme and reason to the rules, they are still just rules that are likely to be disconnected from the ebb and flow of the business.
Assessing SharePoint Risk
Believe it or not, there are some real risks with the implementation of SharePoint. Just type in "I hate SharePoint" into your favorite search engine and then sit back and read about the frustration many organizations have experienced with their SharePoint deployment(s).
Many of these frustrations could have been avoided had the business stakeholders done their due diligence in defining A) the problem, B) what they need the solution to achieve and C) understanding how processes are changed through SharePoint's adoption. Boiled down to common English, these stakeholders didn't take the time to lay out good business and technical requirements, which inform the risk assessment process. In fact, I would submit that not writing good business and technical requirements is, in and of itself, a substantial risk to any SharePoint or Office 365 deployment.
Once the requirements are written, then risks can be assessed per the requirements. The risks should be assessed along two continuums: severity and probability: make one the X-axis and the other the Y-axis. Use either a scale of 1-5 or 1-10. Just be consistent and discuss the risk ratings with your team and stakeholders.
Free Offer: If you'd like to receive a free risk matrix rubric that you can use in your environment, then please email me at bill . english @ summit7systems.com.
For example, let's assume the following is true:
- Business Requirement: content owners need to manage the security on their own content
Technical Requirement: the system must enable content owners to manage security on their own content, allowing them to:
- Add, remove, update user access
- Work with individual and group accounts
- Track and audit past security assignments and changes with built-in reporting capabilities
Now, there could be a number of risks that arise from the business and technical requirements. We'll use one of several risks to flesh out this illustration:
- Risk: wrong user accounts are delegated administrative authority to the content.
Given this risk, we would then rate both the likelihood and the severity of the risk: In this case, we'll estimate the risk levels as follows:
Likelihood of Occurrence
|With Adequate Security Administration Training||
|Without Adequate Security Administration Training||
Now that the risk has been identified and assessed, what are the compliance issues that need to be implemented in order to lower or mitigate the risk? Well, there might be several compliance issues, and they can be listed as follows:
|Purchase third-party security software that enables comprehensive security management||Information technology department; SharePoint Farm Administrator|
|All site Administrators must attend internal prescribed SharePoint security training||Site Administrators, HR, Training Department|
|Spot check reports will be run on a monthly basis to ensure only those with adequate training are assigned the Site Administrator role||SharePoint Farm Administrator, Chief Security Officer or Chief Information Officer or one of their designees.|
Now that we have the Risk and Compliance parts finished, we can derive the Governance for this part of our deployment:
|Purchase third-party security software that enables comprehensive security management||Information technology department; SharePoint Farm Administrator||CIO will ensure the third-party software is purchased with adequate training; the farm administrator will certify the security software has been installed, properly configured and fully patched|
|All site Administrators must attend internal prescribed SharePoint security training||Site Administrators, HR, Training Department||HR representative will track who has attended the site administrator training and will inform the Active Directory and SharePoint administrators as to who should be given site administration permission|
|Spot check reports will be run on a monthly basis to ensure only those with adequate training are assigned the Site Administrator role||SharePoint Farm Administrator, Chief Security Officer or Chief Information Officer or one of their designees.||Summary information is published in a monthly report; aberrations will be reported to the CIO and the site collection administrator for remedial action|
As you can discern, governance becomes the enforcement of the compliance actions which mitigate the risks of the SharePoint deployment to the organization.
Tip: This work can be done either in Excel or SharePoint. In Excel, you'll need a series of tabs to give some focus to the various parts of SharePoint or the various processes for which you're planning to support with SharePoint. If this is done in SharePoint, you could create a filtered view and perform the entire process from one list, but it might be better from a user interface perspective to have a series of lists that are focused as the Excel tabs would be focused.
Is This Process Realistic?
For many organizations, the answer will be "no". They will answer this way – not because they don't agree in theory or in principle with this process (or one similar to it) – but because the reality of their work is that time, focus and reflection are not luxuries they can afford to give to a process like this. So, in many cases, they'll hire it out to a consulting company. As you might suspect, Summit 7 Systems is well able to run this process for companies of all sizes looking to gain the maximum ROI on their SharePoint deployments and develop a solid governance culture as it relates to SharePoint.
Risks and Dangers
When it comes to describing risks, the core question to ask is this: "What is the danger if such-and-such happens (or doesn't happen)? What is the real negative outcome that would create the risk?
For example, most risks boil down to one or more common, negative outcomes:
- Financial loss
- Loss of IP
- Reputational damage
- Productivity losses/increase in opportunity costs
Real World Risk Assessment
Consider this (rough draft) list of features and potential dangers Summit 7 conducted for one customer for an Office 365 deployment (the information has been scrubbed and some of it changed to protect their identity). Notice, as you read through the potential dangers, that nearly all of them fall into one or more of the four categories listed above:
|Group||Feature||Potential Danger(s) without Compliance and Governance|
|Set up Services||Services not setup correctly – results in work stoppage|
|Add domains to Office 365 deployment||Setup rogue domains for internet use; route personal or rogue work through Office 365 deployment|
|Change license count||Office 365 administrators can change licensing count and add unauthorized users to a deployment.|
|User Forgets Password||Work slowdown while user initiates and completes the password reset process|
|Wrong users delegated as Administrators||Users without training have access to Administrative tools; non-authorized users are able to make administrative changes to their own benefit|
|User Groups - Security||Groups are populated with incorrect user accounts|
|Groups are given wrong permissions|
|User Groups – Exchange||Groups are setup as DL's|
|DL's have wrong user account assignments resulting in information being emailed to the wrong users. This potentially exposes sensitive information to the wrong users.|
|Sites||Data loss/leakage due to sites being shared that should be private|
|Calendar||Shared calendar data exposes private or confidential information to those outside the organization.|
|Skype for Business||Users disseminate confidential information through Skype for Business|
|Updates - rollout updates as soon as they are ready||Create UI and process confusion when updates are rolled out unannounced - also, if the updates are clawed back without notice, this too can create confusion|
|Password expiration policy||Policy change allows unauthorized users who have access to resources to extend the length of their access.|
|Participation in the Office 365 Community||User might inadvertently disclose confidential information in a public forum|
|Purchase Services||Services are added which benefit the individual user and injure others on the team, create information kingdoms, increase billing costs and create agency costs|
|One-Drive for Business|
|Copy too many files in a single administrative action||Overconsumption of bandwidth leads to degraded services for others, regardless of how critical they need bandwidth|
|Synchronize files to multiple devices||Bandwidth consumed multiple times for synchronization of the same files|
|Files synchronized to portal devices means confidential information is taken off-site to unmanaged devices - the opportunities for data leaks and compromise of confidential information are numerous|
|Users place documents in the wrong file or folder|
|Lack of adequate training||Users are not informed about product features and ways the product can make their work habits better|
|Users are not informed about the governance on the product and unwittingly create exposure to risk for the organization|
|Users training does not align with their job responsibilities, habits and/or processes|
|Timing of training event is not aligned with new technology introductions|
|Ongoing training is either ignored or not considered important enough to leverage|
|Workflows||In-browser workflows inadequate to meet customer requirements|
|Reinvention||Users find new ways to leverage Office 365 to their needs and unwittingly create new considerations for risk, compliance and governance.|
|Reinvention leads to changing processes "on the fly" without regard to keeping processes lean or efficient.|
|Agency Variations||As agencies mature in their use of Office 365, utilization practices changes and becomes more divergent, leading to increasingly dissimilar ways information is managed. For cross-agency processes, this increasingly becomes a clash point between agencies.|
|Wrongly Applied Permissions||Information is wrongly secured, leading to data leaks/data breaches. If this is highly confidential or politically explosive information, the results could be catastrophic.|
After the risks are described, then the real work of compliance definitions comes into focus. This is probably the hardest part because implementing new compliance actions (or inactions) necessarily means changing processes and culture. We all know how readily people adapt to process change and/or culture change.
At this stage, I suggest you take on only those risks that are lethal or nearly lethal to the organization if the compliance efforts will involve substantial change. Recall that I suggested you assess each risk along two scales – likelihood of occurrence and severity (lethality). Only those risks that are "High" in severity and likelihood should be addressed initially. You can use a phased II or III to implement compliance efforts for the Medium levels of risks.
Finally, once the risks and compliance efforts are described, then it's time to figure out how you'll enforce (govern) them. From my experience, you shouldn't implement any compliance efforts that you or your organization is not willing to enforce.
If you end up with "High" risks that are ungoverned, then describe those risks to your managers and wait to see if they plan to assume or mitigate the risk. This is a core function of Senior Management – to decide how best to mitigate risk for the organization. Some of this will be out of your hands, so, in all honesty, don't sweat it. Understand your role in the organization and don't take on more than you should.
I talk about governance in this way because if you can describe risks as potential dangers that will cost the organization money, time, intellectual property or goodwill, you're likely to get the attention of decision makers. Restating risks in classical GRC terms will help you obtain buy-in for your deployment objectives and elevate SharePoint to a more strategic level.
Are We Any Better Off Today than We Were Eight Years Ago?
In some aspects, I think the answer must be "yes". Most organizations recognize that governance is important to nearly any SharePoint deployment. Yet, I can't help but wonder, after eight years, how we can be so diffused (and confused in some cases) about what Governance is and how it can help an organization. Hopefully, my post will bring some clarity to this discussion and offer some starting points for you to have discussions within your own organization.
If you ever want to discuss your governance or SharePoint deployment with myself or someone else here at Summit 7 Systems, be sure to contact me directly at bill . english @ summit7systems.com.
Summit 7 Systems