As Northridge has developed various SharePoint-based business solutions for clients, and assisted clients in a consulting capacity with SharePoint strategy and governance, we have developed a model that we call the SharePoint Site Governance Lifecycle. This model addresses one of the most important SharePoint governance concerns for perhaps the most important element of SharePoint-based solutions: the site. The model most frequently comes into play in an intranet or extranet context, but could conceivably apply to a public internet context as well--perhaps for organizations that frequently stand up new public-facing SharePoint sites.
The most obvious context for the Site Governance Lifecycle (SGL) model is for SharePoint in the intranet, where the organization is utilizing SharePoint sites for things such as departments, teams, projects, clients, and initiatives. Northridge uses the concept of
managed empowerment (see the
Northridge SharePoint white paper, "Ten Best Practices for SharePoint Collaboration") to express the idea that in a SharePoint-based intranet employees are empowered in a directed fashion to create value by harnessing SharePoint within the capabilities and boundaries defined by the governance model.
In other words, if we keep too tight a rein on things, then we're paying a high opportunity cost because people are not empowered to utilize this powerful platform to create value in a streamlined fashion. On the other hand, if we don't put some governance and process in place--if we don't put some forethought into what we're doing--then we're likely to end up with a jumble, a mess of sites in various states of completion or relevance, and less traction overall in leveraging business value from our SharePoint platform. This is where Northridge's SharePoint Site Governance Lifecycle model comes in.
The model has five stages:
- Stage 1: Request – How will end users and team leaders request a new site when the need arises? Is an approval of some kind required? Should the request go through some kind of ticketing system? Does this kind of site require special provisioning or configuration assistance from the IT team?
- Stage 2: Standup – What is the actual process for standing up a new site? What site templates or solutions are approved for use? Will we have automated code that stands up the site, or will the steps all be manual? Will someone from IT perform the actual standup, or, in some or all cases, would end users be empowered to create the actual site themselves?
- Stage 3: Adoption – From a business value perspective, it makes sense to dedicate at least some small part of the site governance process to encouraging adoption of the new site in which the organization has invested. Different kinds of sites might require different tactics for fostering adoption. (Once again, our "Ten Best Practices..." white paper discusses this topic further.)
- Stage 4: Auditing – Depending on the sensitivity, target audiences, business importance, or complexity/size of the new site, some degree of auditing for either content, adoption, security, or infrastructure might be called for. This would be an ongoing aspect of maintaining the site. Our conception of the “Auditing” stage includes the implied assumption that as audits turn up the need for action (for example, increasing a storage quota or adjusting content that is not ideal) that action would of course be taken.
- Stage 5: Archiving – When a site has reached the end of its useful life (for example, the completion of a project that was supported by a team collaboration site), it is often appropriate to undertake varying degrees of archiving of the site, which might start with simply putting the site in a read only state.