Blogger: Craig Roth
2009 was the year that governance really took off in the SharePoint community as evidenced by SharePoint conference presentations, user's group presentations, and bloggers. It's been a major part of my conversations with clients and presentations to audiences using SharePoint since 2003, but I've never seen the energy around this topic that I have in the past year. That's wonderful since I've observed that SharePoint installations that address governance upfront tend to have a much higher success rate.
Most governance conversations and presentations start from the definition to anchor the subject and then use it as a structure to drill into its portions. The community has mostly settled on some combination of the 3 goals and 3 tools in my definition, as outlined in our SharePoint Planning and Governance workshop:
Website governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization.
Over the years I've been happy to see my approach picked up by the SharePoint community via Microsoft and Joel Oleson. It can now be found in places as diverse as Tech Ed Africa, SharePoint Magazine on Facebook, IronWorks , Robert Bogue, Michael Sampson's blog, and Sean Stecker of Ensynch.
And other guidance from our workshop (like how "SharePoint often overlaps with other installed applications in particular capabilities", how use policy is about "what constitutes abuse or misuse of SharePoint" and provides "clear instructions on how and when users should work with SharePoint", my definitions of the centralized/decentralized/federated models) has now crept into the standard decks Microsoft provides to the SharePoint community (usually without acknowledgement, but I'm sure there's silent appreciation there!).
The definition has even taken on a life of its own by evolving in a few directions, and - aside from the shameless chest thumping above - that's what I'd like to provide my thoughts on today.
One evolution I've seen is to add "to define a service" to the definition. I really like the application of service methodologies to SharePoint and have been doing quite a bit of research in this area. My 2007 workshop applied ITIL v3 to SharePoint and my paper on using ITIL to define "SharePoint as a Service" comes out in January. Still, I've decided to focus on service definition as a management issue rather than a governance one (more on that here).
Another evolution I see as more dangerous. A fourth tool snuck in at some point: technology. There are plenty of other SharePoint documents that will focus on technology, such as maintenance manuals, administrator's guides, tuning guides, etc. Technology is a third rail of SharePoint governance. I tried injecting it for a short time and quickly backed off after seeing the energy it sucked out of the other 3 tools. It provides a slippery slope that enables those uncomfortable with the political and diplomatic challenges of defining people, policy, and process to focus on technology instead. Also, you have different audiences and authors for technical docs versus the statement of governance so it's best to leave that separate.
Comments