I hear there’s a problem these days of people saying…. I’ve got the governance doc, so I’m now good to deploy. I’m now going to have a successful deployment.
Have I created a monster? In my attempts at addressing the lack of planning and of awareness around designing a SharePoint service not just installing software, I find more and more are now realizing that “Governance” is something they were missing. More than that it really that they were missing a service definition, missing an exec sponsor, missing roles and responsibilities. Governance has become a buzzword, and the original definition is being lost despite my attempts at defining it as designing a service offering.
Governance uses people, process and technology to define a service [offering], mitigate conflict within an organization [and across multiple organizations]. – Craig Roth, Burton Group
(I just added the offering to add more context and the multiple organizations piece to include extranets. -Joel)
Paul Culmsee (my Governance arch nemesis and friend) uses the word “assurance,” but I find that it lacks legs. That word lives in the support world around optimization and SLAs, but lacks the comprehensiveness required in providing the describing the service and addressing the conflicting requirements that come from the business. I can’t do anything about the fact that Governance has become a buzzword. (By the way, you have to look at the IBIS issue based mapping on the site definition debate encapsulated into a series on one best practice to rule them all. Incredible work Paul!)
How do you address or prevent SharePoint Chaos? How do you address or prevent SharePoint Anarchy? You address it by creating not just a document, but start by ensuring you are creating the relevant roles responsibilities and service offering that will ultimately allow you to achieve the ultimate goal of economies of scale to govern your deployment. If you’re overwhelmed you MUST start with the checklist. It simplifies this whole governance thing, and takes the thousands of planning content pages into a 30 tiny page deployment essentials checklist. Use that as a tool when writing your plans.
So what documents do you need for a deployment? Does it stop at Governance plan? No. That’s where it all begins. You know you want to design something that you have a vision for, now you can start planning.
TechNet and MSDN are on a continuous publishing model, maybe you should be too! That’s one reason SharePoint documentation stinks! It never ends. You must continuously update and document your changes, let alone update your plans as the scope changes. The service offering will change, and you need to know where you’re going.
Plan, Deploy, Operate, Optimize
As an Ops guy I use to HATE writing documentation. No one read it, so why write it. Ultimately as I look through these guides, most of it is simply capturing decisions that are made, and capturing the processes, technologies, and resources outlined for the service backed by SLAs and Metrics. Are we succeeding? These docs would help guide us.
The operations and troubleshooting guides as well are living documents that more clearly identify the support tiers and levels. Do you need 1000 pages to execute? Maybe, but probably not. You simply need to capture the decisions being made and ensure the processes are optimized as the service matures from pilot to production and beyond.
Deployment is not over at launch! While these docs may be required in some organizations to be flushed out over the first 3 months of a pilot, these should become living documents reviewed by the respective teams that are governed by them. Don’t forget the requirements around optimization and verification post launch.
Some people may hate me for listing these not only because now they are really going to have to do more documentation, but others will praise there being a list. Many, many, many consultants consider this list and their own custom lists to be proprietary and part of their SharePoint Practice. If you sign up for SDPS, you’ll find it’s about identifying what information needs to be gathered to define the SharePoint service. That’s what these guides are really about. If seeing this list encourages you to hire smart/experienced consultants or those with experience to help you be successful, then I’ve done my job. Not all of these documents may need to be completely flushed out at launch, but you can see the value in having answers around these areas prior.