A great deal of my experience with SharePoint has been as a consumer, so to speak: working as part of a project team to procure and deploy SharePoint for intranet or document management purposes. As such, I'm cognisant of the mindset that often goes with deploying SharePoint, or any other content management system for that matter. There's a huge focus on the project itself, the tasks that must be completed in order to deploy the system – planning, analysis, design, build and testing, and all of the tasks that make up these activities. There's also a great build-up of expectations from stakeholders around outcomes that will be achieved and a general expectation that their lives will be made easier in some way.
The analysis phase of the project identifies the business needs that the intranet or document management system (DMS) is going to address, and the SharePoint features that will support these. What many organizations lose sight of though, is that the operative word here is "support".
There is always an underlying excitement when an organization is undertaking a project that will result in a new system. I mean, who doesn't like getting new stuff? If SharePoint is the answer to a long-standing or onerous problem then it can almost feel as though your management team is giving you a present! Basically, by themselves, systems don't solve problems.
Systems are just a cog in a productivity mechanism that also involves people and processes. The only thing that varies is the ratio; some processes will tend towards a greater degree of automation; others require more manual intervention. There are few business processes that don't require a user to provide some form of input or consume an output. A good fit-for-purpose system will facilitate this as much as possible, but there is still an onus on the user to play their part, and governance is the tool that helps them do it.
So what exactly do I mean when I say governance? There are lots of interpretations of what this means in a SharePoint context, but personally I think of it as a guide to "how we do things around here". There's a tendency for people to think of governance in terms of just a hierarchy of site permissions, but there is much more to it than that. Governance, often communicated in the form of a set of policies and procedures, provides the user with the actions they need to carry out, a context for their actions, and a guide to how and when to complete tasks.
Governance planning should involve posing a number of questions to the business and using the answers to form the basis of the policies and procedures that control the solution. These can include, but are not limited to, publishing policies, maintenance procedures, help processes, workflows and approvals, document storage and retention policies and collaboration guidelines. In my next post I will discuss these areas in more depth.
The reason governance gets overlooked is that it isn't terribly "sexy", nor is it particularly easy to get right. It is often sacrificed to the project mindset that I mentioned above, where all the energy is focussed on getting a new solution up and running, and ongoing investment and incremental improvement are overlooked. This applies to governance also, as policies and procedures are not updated over time to account for changes in business processes, regulatory or statutory obligations or advances in technology.
In my next post:
Identifying existing pols/procs, identifying gaps, creating new products
The governance matrix