다음을 통해 공유

SharePoint Governance Part 1

  • 아티클

Well, SharePoint governance has literally driven me crazy for quite a long time. And before I came up with this article, I had to do it the hard way.
Do a project, understand what went wrong and then go backwards to plot the governance bits.
Anyways, for anyone out there who need to make a SharePoint Governance proposal, have to come up with a strategy or a mere SharePoint show off, this is the article to read :)

As always, I have come with few points which forms SharePoint Governance:

  1. People
  2. Process
  3. Mapping

People
Let's start with people. We the people who run a typical organisation are bunch of smart people. We take ourselves too seriously and we plot a typical strategic board which governs and decides the empowered vision of the organisation. On the same lines, when it comes to Microsoft SharePoint, we need to devise a Governance board responsible for TO DO's and NOT SO TO DO's for SharePoint platform. Remember the old saying, SharePoint is not only a platform but an application which can be tailored as per your specific organisational needs. So, in short we can come up with the following:


The above figure entails the following:

a) Strategy Board - This can be typically your IT Director, Stakeholders, Head of Communications. They meet, collaborate and plot a roadmap. This roadmap further contains short term and long term solutions which can be implemented in SharePoint. If you are familiar with agile, this board typically decides the product backlog, user stories. And above all the upcoming technologies which can be integrated with SharePoint

b) Design Board - If you are a developer, you might not take this board seriously. However, the way we brand ourselves in the contemporary world is one of the key things to be visible, to sell and finally to be known. So, this department understands the organisation's brand values, use their sharp design skills and come up the design, colors, cascading style sheets which can help to brand your SharePoint site according to your organisational values

c) Implementation and Support - If you are a fan of Dilbert Priniciple, then consider these as the people who do the actual work. You can further classify them as:
    A SharePoint end user - A site owner managing team site. This user can further decide who will be content editors, authors and approvers
    SharePoint Infrastucture Team - Managing the complete SharePoint farm - Services, Servers
    SharePoint Application Team - Developing Out of the Box and custom application on SharePoint
    Helpdesk - Typical L1 team logging user calls in SharePoint
    Layman User - Do not bother what is SharePoint. Just save the URL and favourites and open it when he/she needs to upload or open a document

d) Legal - Legal is important for big organisations which want what needs to be governed, accessed and published. They can also audit the complete SharePoint content. Alternatively, they have a set of guidelines which you need to follow while building your typical Intranet or Extranet

Process
Now, everyone is aware of the word Process. Some consider it as a hurdle to speed up things and some use to speed up things :) Anyways, when it come to SharePoint, it is important to understand your organisational process.

  1. Content Management Process
  2. Information Management Process
  3. Storage, Versioning & Archiving Process
  4. Document Management Process
  5. Organisation General Process around Change and Release

I won't go into the details of any generic processes. However, let's see what you can do once you know the above processes in your organisation. You start mapping these people to the process. Sounds simple eh?

Mapping
This would mean mapping people across the SharePoint Information Architecture in the real world. The below image depicts how to start this:


Once you have a clear idea of what role would be performed by whom and how will that conform to your organisational needs, you can start doing the real stuff. The real stuff of designing your Information Architecture. A typical consists of following layers:

  1. Publishing Site
  2. Collaboration Team Site
  3. Project Sites
  4. My Sites
  5. Bespoke Apps

Time to sign off, the next article would cover how to design these sites, a debate between webapplication versus site collection.