A: This is partly because SharePoint is not a strictly defined product with a clearly defined beginning and endpoint in terms of user behavior, content, and IT deployment.
Note
SharePoint is like a "Swiss Army knife" of application platforms that has extreme versatility, so it does not fit neatly into one single software category in terms of its definition, functionality, or user approach. It also means that a company's investment in SharePoint can deliver more than just a "document management system" to the organization, and can also replace website technology, intranets, bespoke applications, and network drives. So SharePoint governance must be relevant to the user base and functionality, which will be different in different organizations because there could be a different deployment approach, other complementary technologies, and end users.
For example, a CRM system is pretty clearly defined. The user base is typically a sales force, the content is sales data, and the reports are dashboards.
Conversely, with a SharePoint implementation, the purposes could be any of the following:
- Business intelligence, for example, KPIs
- Social computing — wikis, blogs, and so on
- Communities — rating, comments, tagging, and so on
- Composites with business integration with Access, Visio, and Excel
- Advanced document management — "One version of the truth", with version control and alert notifications
- Easy-to-understand collaboration for non-technical people
- Workflows
- Information discovery and so on
Note
One simple analogy is that SharePoint is like a huge box of Lego from the local toy store. When you get those huge sets, there's no picture of what it's going to build, as that's totally up to you. If you're careful, creative, and plan well, you can build a castle, an airplane, or even a rocket ship. Or, if you're not as good, you (sadly) get a pretty big sized brick of little pieces that does nothing and represents even less.
A governance plan is required to build the rocket ship.
The user base could be internal/external users or even non-corporate employees, and this could change over time. The content can range from text and Office documents, to media videos.
Any SharePoint governance documents that expect to have any chance of being read and adhered to, at the very least, must cover the user base of the activity that is being addressed in the document, and the technically involved business groups, such as infrastructure and development.
What is key to a successful SharePoint deployment is user adoption. However, because a SharePoint application is sometimes not clearly defined in terms of what it can and cannot do, the user and businesses require clearly defined parameters in content, training, and service level agreements. The governance we are recommending strikes a balance in what businesses and the user community require and expect, as well as what IT can support. So it is vital that all parties that are reading and writing governance documents have some conversations prior to the governance policies being finalized.
Since SharePoint normally replaces or complements an existing process such as e-mail or another system, end-user awareness of dos and don'ts, as well as clarity of the SharePoint process, content, and procedures are all key for governance to succeed.